数据库

• Agent 需要什么样的数据库？
• MySQL与白酒：互联网行业的服从测试
• Victoria：吊打业界的可观测性全家桶来了
• MinIO已死，谁能接盘？
• MinIO已死
• 当答案唾手可得，问题成为新货币
• 聊聊开源软件供应链信任问题
• 原地报废：不要在生产环境用Docker跑PostgreSQL！
• DDIA第二版中文翻译
• 懂车帝暴打智驾，懂库帝在哪里
• Google AI工具箱：生产级数据库MCP来了？
• AI时代的数据库与DBA将何去何从
• 别争了，AI时代数据库已经尘埃落定
• 开放数据标准：Postgres，OTel，与Iceberg
• 小数据的失落十年：分布式分析的错付
• OpenAI：将PostgreSQL伸缩至新阶段
• Etcd坑了多少公司？
• AI时代，软件从数据库开始
• MySQL vs PostgreSQL @ 2025
• 数据库火星撞地球：当PG爱上DuckDB
• 对比Oracle与PostgreSQL事务系统
• 数据库即业务架构
• 七周七数据库（2025年）
• 自建 Supabase：创业出海的首选数据库
• 面向未来数据库的现代硬件
• MySQL还有机会赶上PostgreSQL吗？
• 开源“暴君”Linus清洗整风
• 先优化碳基BIO核，再优化硅基CPU核
• MongoDB没有未来：好营销救不了烂芒果
• MongoDB：现在由PostgreSQL强力驱动？
• 瑞士强制政府软件开源
• MySQL安魂九霄，PostgreSQL驶向云外
• CVE-2024-6387 SSH漏洞修复
• Oracle还能挽救MySQL吗？
• Oracle最终还是杀死了MySQL
• MySQL性能越来越差，Sakila将何去何从？
• 20刀好兄弟PolarDB：论数据库该卖什么价？
• 国产数据库到底能不能打？
• Redis不开源是“开源”之耻，更是公有云之耻
• MySQL正确性竟如此垃圾？
• 数据库应该放入K8S里吗？
• 专用向量数据库凉了吗？
• 数据库真被卡脖子了吗？
• EL系操作系统发行版哪家强？
• 基础软件需要什么样的自主可控？
• 正本清源：技术反思录
• 数据库需求层次金字塔
• 分布式数据库是不是伪需求？
• 微服务是不是个蠢主意？
• 是时候和GPL说再见了
• 容器化数据库是个好主意吗？
• 理解时间：闰年闰秒，时间与时区
• 理解字符编码原理
• 并发异常那些事
• 区块链与分布式数据库
• 一致性：过载的术语
• 为什么要学习数据库原理

Agent 需要什么样的数据库？

AI Agent 的瓶颈不在数据库内核，而在上层整合。肌肉记忆（库内计算）、联想记忆（向量+图谱融合）、试错魄力（Git for Data）将成为关键，不过这些能力不需要新引擎。 阅读全文

MySQL与白酒：互联网行业的服从测试

互联网的MySQL就像中国的白酒：明明很难喝，却在文化规训下成了琼浆玉液，本质都是一种服从测试。 阅读全文

Victoria：吊打业界的可观测性全家桶来了

Victoria是朴实无华的强悍— — 用几分之一的资源，实现Prometheus + Loki几倍的效果。Pigsty v4.0将全面采用Victoria全家桶。 阅读全文

MinIO已死，谁能接盘？

MinIO进入维护模式，有什么替代品？Ceph、RustFS、SeaweedFS、Garage各有各的问题。老冯把这些方案都打好了包挨个试了一遍，总结一句话：没有完美替代。 阅读全文

MinIO已死

MinIO官方宣布开源项目进入"维护模式"，基本上宣告了MinIO作为一个开源项目的死亡。屠龙勇者成为新的恶龙——MinIO是如何从S3开源替代变成一家普通的商业软件公司的。 阅读全文

当答案唾手可得，问题成为新货币

答案正在贬值，提问的能力决定了你在AI时代的位置。凯文·凯利预言成真：当答案成为商品时，好的问题就是新的财富。毕加索早在1968年就说过：计算机毫无用处，它们只能给你答案。 阅读全文

聊聊开源软件供应链信任问题

在严肃的生产环境里，你不能依赖一个明确说"我不提供任何保证"的上游。当别人告诉你"别指望我"，最好的回应是"那我自己来"。从TUNA镜像站的争议谈开源软件供应链信任问题。 阅读全文

原地报废：不要在生产环境用Docker跑PostgreSQL！

大量用官方Docker Postgres镜像的用户在最近小版本升级中翻车踩雷。早在2019年老冯就警告过不要在生产环境用容器运行PostgreSQL，因为你极大概率会遇上一堆物理机/虚拟机上根本不存在的麻烦。 阅读全文

DDIA第二版中文翻译

曾经的互联网名著DDIA——设计数据密集型应用第二版已经发布到第十章了。老冯用Claude Code翻译成中文，并用Hugo/Hextra重构成易读的网页版。第二版新增了向量数据库HNSW索引等内容，温故知新。 阅读全文

懂车帝暴打智驾，懂库帝在哪里

懂车帝搞的智驾评测视频让一众国产自动驾驶现了原形，封闭高速真实测试结果全军覆没，只有特斯拉能打。什么时候国产数据库和云计算也能有个"封闭高速"给大家上来溜一溜，拆穿这股满嘴跑火车的行业歪风？ 阅读全文

Google AI工具箱：生产级数据库MCP来了？

Google推出了一个针对数据库的MCP工具箱GenAI Toolbox，通过封装参数模板SQL的方式，显著提高了数据库MCP的实用性与安全性。不同于以前那种直接把整个数据库对Agent开放的粗暴做法，这可能是第一个生产可用的方案。 阅读全文

AI时代的数据库与DBA将何去何从

OLTP与OLAP谁先被AI革命？一体化还是专业化，如何选型？AI时代的DBA该何去何从？来自 HOW 2025 大会圆桌讨论的观点整理：OLAP岗位正被NL2SQL替代，而DBA因语料稀缺暂时安全。 阅读全文

别争了，AI时代数据库已经尘埃落定

AI时代的数据库格局已经尘埃落定。Databricks收购Neon，Snowflake收购CrunchyData，OpenAI传闻收购Supabase——资本市场对PostgreSQL标的密集出手，PG已成为AI时代的默认数据库。 阅读全文

开放数据标准：Postgres，OTel，与Iceberg

数据世界正在浮出水面的三大新标准：Postgres、Open Telemetry，以及Iceberg。Postgres已是事实标准，OTel和Iceberg尚在成长，但它们具备当年让Postgres走红的同样配方——关键在于开源的姿势本身。 阅读全文

小数据的失落十年：分布式分析的错付

如果2012年DuckDB问世，也许那场数据分析向分布式架构的大迁移根本就不会发生。在2012年的MacBook上运行TPC-H评测显示，数据分析确实在分布式架构上走了十年弯路。数据其实没那么大。 阅读全文

OpenAI：将PostgreSQL伸缩至新阶段

原文链接：https://www.pgevents.ca/events/pgconfdev2025/schedule/session/433-scaling-postgres-to-the-next-level-at-openai/

在PGConf.Dev 2025大会上，来自OpenAI的Bohan Zhang分享了OpenAI在PostgreSQL上的最佳实践。在OpenAI，他们使用一写多读的未分片架构，证明了PostgreSQL在海量读负载下也可以伸缩自如。 阅读全文

Etcd坑了多少公司？

因为Etcd而翻车的公司并非少数。Etcd有一个坑爹的默认设计：写满2GB数据就挂了。如果你在自己折腾Kubernetes或使用Patroni做PostgreSQL高可用，大概率会在这上面翻车。 阅读全文

AI时代，软件从数据库开始

未来的软件形态是 Agent + 数据库，没有前后端中间商，Agent直接CRUD。微软CEO纳德拉预言SaaS已死，软件从数据库开始。数据库技能相当保值，PostgreSQL将成为AI Agent时代的核心数据库。 阅读全文

MySQL vs PostgreSQL @ 2025

在2025年的当下，MySQL无论是在功能特性集、质量正确性、性能表现还是生态与社区上都被PostgreSQL拉开了差距，而且这个差距还在进一步扩大中。本文从功能、性能、质量、生态来全方位对比两者。 阅读全文

数据库火星撞地球：当PG爱上DuckDB

老冯很看好"DuckDB + PostgreSQL深度融合"这条路径，它可能会引爆数据库世界下一场"火星撞地球"式的变革。相比折腾分布式DuckDB，这才是更有前景的方向。 阅读全文

对比Oracle与PostgreSQL事务系统

PG社区开始骑在Oracle头上输出了。Cybertec专家对比Oracle和PostgreSQL事务系统的特性，帮助用户理解两者差异，为从Oracle迁移到PostgreSQL提供关键参考，避免性能和数据完整性问题。 阅读全文

数据库即业务架构

数据库是业务架构的核心，这是不言自明的共识。但如果更进一步，将数据库作为业务架构本身，将业务逻辑、Web Server甚至整个前后端都放入数据库中，又会擦出怎样的火花？ 阅读全文

七周七数据库（2025年）

原文链接：https://matt.blwt.io/post/7-databases-in-7-weeks-for-2025/

PostgreSQL是无聊数据库之王？2025年值得深入学习的七个数据库：PostgreSQL、SQLite、DuckDB、ClickHouse、FoundationDB、TigerBeetle、CockroachDB，每个都值得花一周时间研究。 阅读全文

自建 Supabase：创业出海的首选数据库

Supabase 很好，拥有属于你自己的 supabase 则好上加好。 Pigsty 可以帮助您在自己的服务器上（物理机/虚拟机/云服务器），一键自建企业级 supabase —— 更多扩展，更好性能，更深入的控制，更合算的成本。

Pigsty 是 Supabase 官网文档上列举的三种自建部署之一：Self-hosting: Third-Party Guides

简短版本

准备 Linux，执行 Pigsty 标准安装 流程，选择 supabase 配置模板，依次执行：

curl -fsSL https://repo.pigsty.io/get | bash; cd ~/pigsty
./configure -c supabase    # 使用 supabase 配置（请在 pigsty.yml 中更改凭据）
vi pigsty.yml              # 编辑域名、密码、密钥...
./install.yml              # 安装 pigsty
./docker.yml               # 安装 docker compose 组件
./app.yml                  # 使用 docker 启动 supabase 无状态部分（可能较慢）

安装完毕后，使用浏览器访问 8000 端口造访 Supa Studio，用户名 supabase，密码 pigsty。

目录

• Supabase是什么？
• 为什么要自建它？
• 单机自建快速上手
• 进阶主题：安全加固
• 进阶主题：域名接入
• 进阶主题：外部对象存储
• 进阶主题：使用SMTP
• 进阶主题：真·高可用

Supabase是什么？

Supabase 是一个 BaaS （Backend as Service），开源的 Firebase，是 AI Agent 时代最火爆的数据库 + 后端解决方案。 Supabase 对 PostgreSQL 进行了封装，并提供了身份认证，消息传递，边缘函数，对象存储，并基于 PG 数据库模式自动生成 REST API 与 GraphQL API。

Supabase 旨在为开发者提供一条龙式的后端解决方案，减少开发和维护后端基础设施的复杂性。 它能让开发者告别绝大部分后端开发的工作，只需要懂数据库设计与前端即可快速出活！ 开发者只要用 Vibe Coding 糊个前端与数据库模式设计，就可以快速完成一个完整的应用。

目前，Supabase 是 PostgreSQL 开源生态 中人气最高的开源项目，在 GitHub 上已有 八万 Star。 Supabase 还为小微创业者提供了“慷慨”的免费云服务额度 —— 免费的 500 MB 空间，对于存个用户表，浏览数之类的东西绰绰有余。

为什么要自建？

既然 Supabase 云服务这么香，为什么要自建呢？

最直观的原因是是我们在《云数据库是智商税吗？》中提到过的：当你的数据/计算规模超出云计算适用光谱（Supabase：4C/8G/500MB免费存储），成本很容易出现爆炸式增长。 而且在当下，足够可靠的 本地企业级 NVMe SSD 在性价比上与 云端存储 有着三到四个数量级的优势，而自建能更好地利用这一点。

另一个重要的原因是 功能， Supabase 云服务的功能受限 —— 很多强力PG扩展因为多租户安全挑战与许可证的原因无法以云服务的形式。 故而尽管 扩展是 PostgreSQL 的核心特色，在 Supabase 云服务上也依然只有 64 个扩展可用。 而通过 Pigsty 自建的 Supabase 则提供了多达 440 个开箱即用的 PG 扩展。

此外，自主可控与规避供应商锁定也是自建的重要原因 —— 尽管 Supabase 虽然旨在提供一个无供应商锁定的 Google Firebase 开源替代，但实际上自建高标准企业级的 Supabase 门槛并不低。 Supabase 内置了一系列由他们自己开发维护的 PG 扩展插件，并计划将原生的 PostgreSQL 内核替换为收购的 OrioleDB，而这些内核与扩展在 PGDG 官方仓库中并没有提供。

这实际上是某种隐性的供应商锁定，阻止了用户使用除了 supabase/postgres Docker 镜像之外的方式自建，Pigsty 则提供开源，透明，通用的方案解决这个问题。 我们将所有 Supabase 自研与用到的 10 个缺失的扩展打成开箱即用的 RPM/DEB 包，确保它们在所有 主流Linux操作系统发行版 上都可用：

同时，我们在 Supabase 自建部署中默认 安装绝大多数扩展，您可以参考可用扩展列表按需 启用。

同时，Pigsty 还会负责好底层 高可用 PostgreSQL 数据库集群，高可用 MinIO 对象存储集群的自动搭建，甚至是 Docker 容器底座的部署与 Nginx 反向代理，域名配置 与 HTTPS证书签发。 您可以使用 Docker Compose 拉起任意数量的无状态 Supabase 容器集群，并将状态存储在外部 Pigsty 自托管数据库服务中。

在这一自建部署架构中，您获得了使用不同内核的自由（PG 15-17，OrioleDB），加装 440 个扩展的自由，扩容与伸缩 Supabase / Postgres / MinIO 的自由， 免于数据库运维杂务的自由，以及免于供应商锁定，本地运行到地老天荒的自由。 而相比于使用云服务需要付出的代价，不过是准备服务器和多敲几行命令而已。

单节点自建快速上手

让我们先从单节点 Supabase 部署开始，我们会在后面进一步介绍多节点高可用部署的方法。

准备 一台全新 Linux 服务器，使用 Pigsty 提供的 supabase 配置模板执行 标准安装， 然后额外运行 docker.yml 与 app.yml 拉起无状态部分的 Supabase 容器即可（默认端口 8000/8433）。

curl -fsSL https://repo.pigsty.io/get | bash; cd ~/pigsty
./configure -c supabase    # 使用 supabase 配置（请在 pigsty.yml 中更改凭据）
vi pigsty.yml              # 编辑域名、密码、密钥...
./install.yml              # 安装 pigsty
./docker.yml               # 安装 docker compose 组件
./app.yml                  # 使用 docker 启动 supabase 无状态部分

在部署 Supabase 前请根据实际情况修改自动生成的 pigsty.yml 配置文件中的参数（域名与密码） 如果只是本地开发测试，可以先跳过，我们将在后面介绍如何通过修改配置文件来进一步定制。

如果配置无误，大约十分钟后，就可以在本地网络通过 http://<your_ip_address>:8000 访问到 Supabase Studio 图形管理界面了。 默认的用户名与密码分别是： supabase 与 pigsty。

在中国大陆地区，Pigsty 默认使用 1Panel 与 1ms 提供的 DockerHub 镜像站点下载 Supabase 相关镜像，可能会较慢。
你也可以自行配置 [代理](https://doc.pgsty.com/zh/docker/config#proxy) 与 [镜像站](https://doc.pgsty.com/zh/docker/config#registry) ，`cd /opt/supabase; docker compose pull` 手动拉取镜像。
我们亦提供包含完整离线安装方案的 [Supabase 自建专家咨询服务](https://doc.pgsty.com/zh/service)。

如果你需要使用的对象存储功能，那么需要通过域名与 HTTPS 访问 Supabase，否则会出现报错。

对于严肃的生产部署，请 **务必** 修改所有默认密码！

自建关键技术决策

以下是一些自建 Supabase 会涉及到的关键技术决策，供您参考：

使用默认的单节点部署 Supabase 无法享受到 PostgreSQL / MinIO 的高可用能力。 尽管如此，单节点部署相比官方纯 Docker Compose 方案依然要有显著优势： 例如开箱即用的监控系统，自由安装扩展的能力，各个组件的扩缩容能力，以及提供兜底数据库时间点恢复能力等。

如果您只有一台服务器，或者选择在云服务器上自建，Pigsty 建议您使用外部的 S3 替代本地的 MinIO 作为对象存储，存放 PostgreSQL 的备份，并承载 Supabase Storage 服务。 这样的部署在故障时可以在单机部署条件下，提供一个兜底级别的 RTO （小时级恢复时长）/ RPO （MB级数据损失）容灾水平。

在严肃的生产部署中，Pigsty 建议使用至少3～4个节点的部署策略，确保 MinIO 与 PostgreSQL 都使用满足企业级高可用要求的多节点部署。 在这种情况下，您需要相应准备更多节点与磁盘，并相应调整 pigsty.yml 配置清单中的集群配置，以及 supabase 集群配置中的接入信息，使用高可用接入点访问服务。

Supabase 的部分功能需要发送邮件，所以要用到 SMTP 服务。除非单纯用于内网，否则对于严肃的生产部署，建议使用 SMTP 云服务。自建的邮件服务器发送的邮件容易被标记为垃圾邮件导致拒收。

如果您的服务直接向公网暴露，我们强烈建议您使用真正的域名与 HTTPS 证书，并通过 Nginx 门户 访问。

接下来，我们会依次讨论一些进阶主题。如何在单节点部署的基础上，进一步提升 Supabase 的安全性、可用性与性能。

进阶主题：安全加固

Pigsty基础组件

对于严肃的生产部署，我们强烈建议您修改 Pigsty 基础组件的密码。因为这些默认值是公开且众所周知的，不改密码上生产无异于裸奔：

• grafana_admin_password: pigsty，Grafana管理员密码
• pg_admin_password: DBUser.DBA，PG超级用户密码
• pg_monitor_password: DBUser.Monitor，PG监控用户密码
• pg_replication_password: DBUser.Replicator，PG复制用户密码
• patroni_password: Patroni.API，Patroni 高可用组件密码
• haproxy_admin_password: pigsty，负载均衡器管控密码
• minio_secret_key: minioadmin，MinIO 根用户密钥
• 此外，强烈建议您修改 Supabase 使用的 PostgreSQL 业务用户 密码，默认为 DBUser.Supa

以上密码为 Pigsty 组件模块的密码，强烈建议在安装部署前就设置完毕。

Supabase密钥

除了 Pigsty 组件的密码，你还需要 修改 Supabase 的密钥，包括

• JWT_SECRET
• ANON_KEY
• SERVICE_ROLE_KEY
• DASHBOARD_USERNAME Supabase Studio Web 界面的默认用户名，默认为 supabase
• DASHBOARD_PASSWORD Supabase Studio Web 界面的默认密码，默认为 pigsty

这里请您务必参照 Supabase教程：保护你的服务 里的说明：

• 生成一个长度超过 40 个字符的 JWT_SECRET，并使用教程中的工具签发 ANON_KEY 与 SERVICE_ROLE_KEY 两个 JWT。
• 使用教程中提供的工具，根据 JWT_SECRET 以及过期时间等属性，生成一个 ANON_KEY JWT，这是匿名用户的身份凭据。
• 使用教程中提供的工具，根据 JWT_SECRET 以及过期时间等属性，生成一个 SERVICE_ROLE_KEY，这是权限更高服务角色的身份凭据。
• 如果您使用的 PostgreSQL 业务用户使用了不同于默认值的密码，请相应修改 `POSTGRES_PASSWORD`` 的值
• 如果您的对象存储使用了不同于默认值的密码，请相应修改 S3_ACCESS_KEY``](https://github.com/pgsty/pigsty/blob/main/conf/supabase.yml#L154) 与 [S3_SECRET_KEY`` 的值

Supabase 部分的凭据修改后，您可以重启 Docker Compose 容器以应用新的配置：

./app.yml -t app_config,app_launch

cd /opt/supabase; make up

进阶主题：域名接入

如果你在本机或局域网内使用 Supabase，那么可以选择 IP:Port 直连 Kong 对外暴露的 HTTP 8000 端口访问 Supabase。

你可以使用一个内网静态解析的域名，但对于严肃的生产部署，我们建议您使用真域名 + HTTPS 来访问 Supabase。 在这种情况下，您的服务器应当有一个公网 IP 地址，你应当拥有一个域名，使用云/DNS/CDN 供应商提供的 DNS 解析服务，将其指向安装节点的公网 IP（可选默认下位替代：本地 /etc/hosts 静态解析）。

比较简单的做法是，直接批量替换占位域名（supa.pigsty）为你的实际域名，假设为 supa.pigsty.cc：

sed -ie 's/supa.pigsty.cc/supa.pigsty/g/' ~/pigsty/pigsty.yml

如果你没有事先配置好，那么重载 Nginx 和 Supabase 的配置生效即可：

make nginx      # 重载 nginx 配置
make cert       # 申请 certbot 免费 HTTPS 证书
./app.yml       # 重载 Supabase 配置

修改后的配置应当类似下面的片段：

all:
  vars:
    infra_portal:
      supa :
        domain: supa.pigsty.cc        # 替换为你的域名！
        endpoint: "10.10.10.10:8000"
        websocket: true
        certbot: supa.pigsty.cc       # 证书名称，通常与域名一致即可

  children:
    supabase:
      vars:
          supabase:                                       # the definition of supabase app
            conf:                                         # override /opt/supabase/.env
              SITE_URL: https://supa.pigsty                # <------- Change This to your external domain name
              API_EXTERNAL_URL: https://supa.pigsty        # <------- Otherwise the storage api may not work!
              SUPABASE_PUBLIC_URL: https://supa.pigsty     # <------- DO NOT FORGET TO PUT IT IN infra_portal!

完整的域名/HTTPS 配置可以参考 证书管理 教程，您也可以使用 Pigsty 自带的本地静态解析与自签发 HTTPS 证书作为下位替代。

进阶主题：外部对象存储

您可以使用 S3 或 S3 兼容的服务，来作为 PGSQL 备份与 Supabase 使用的对象存储。这里我们使用一个 阿里云 OSS 对象存储作为例子。

Pigsty 提供了一个 terraform/spec/aliyun-meta-s3.tf 模板， 可以用于在阿里云上拉起一台服务器，以及一个 OSS 存储桶。

首先，我们修改 all.children.supa.vars.apps.[supabase].conf 中 S3 相关的配置，将其指向阿里云 OSS 存储桶：

# if using s3/minio as file storage
S3_BUCKET: data                       # 替换为 S3 兼容服务的连接信息
S3_ENDPOINT: https://sss.pigsty:9000  # 替换为 S3 兼容服务的连接信息
S3_ACCESS_KEY: s3user_data            # 替换为 S3 兼容服务的连接信息
S3_SECRET_KEY: S3User.Data            # 替换为 S3 兼容服务的连接信息
S3_FORCE_PATH_STYLE: true             # 替换为 S3 兼容服务的连接信息
S3_REGION: stub                       # 替换为 S3 兼容服务的连接信息
S3_PROTOCOL: https                    # 替换为 S3 兼容服务的连接信息

同样使用以下命令重载 Supabase 配置：

./app.yml -t app_config,app_launch

您同样可以使用 S3 作为 PostgreSQL 的备份仓库，在 all.vars.pgbackrest_repo 新增一个 aliyun 备份仓库的定义：

all:
  vars:
    pgbackrest_method: aliyun          # pgbackrest 备份方法：local,minio,[其他用户定义的仓库...]，本例中将备份存储到 MinIO 上
    pgbackrest_repo:                   # pgbackrest 备份仓库: https://pgbackrest.org/configuration.html#section-repository
      aliyun:                          # 定义一个新的备份仓库 aliyun
        type: s3                       # 阿里云 oss 是 s3-兼容的对象存储
        s3_endpoint: oss-cn-beijing-internal.aliyuncs.com
        s3_region: oss-cn-beijing
        s3_bucket: pigsty-oss
        s3_key: xxxxxxxxxxxxxx
        s3_key_secret: xxxxxxxx
        s3_uri_style: host
        path: /pgbackrest
        bundle: y                         # bundle small files into a single file
        bundle_limit: 20MiB               # Limit for file bundles, 20MiB for object storage
        bundle_size: 128MiB               # Target size for file bundles, 128MiB for object storage
        cipher_type: aes-256-cbc          # enable AES encryption for remote backup repo
        cipher_pass: pgBackRest.MyPass    # 设置一个加密密码，pgBackRest 备份仓库的加密密码
        retention_full_type: time         # retention full backup by time on minio repo
        retention_full: 14                # keep full backup for the last 14 days

然后在 all.vars.pgbackrest_mehod 中指定使用 aliyun 备份仓库，重置 pgBackrest 备份：

./pgsql.yml -t pgbackrest

Pigsty 会将备份仓库切换到外部对象存储上，更多备份配置可以参考 PostgreSQL 备份 文档。

进阶主题：使用SMTP

你可以使用 SMTP 来发送邮件，修改 supabase 应用配置，添加 SMTP 信息：

all:
  children:
    supabase:        # supa group
      vars:          # supa group vars
        apps:        # supa group app list
          supabase:  # the supabase app
            conf:    # the supabase app conf entries
              SMTP_HOST: smtpdm.aliyun.com:80
              SMTP_PORT: 80
              SMTP_USER: no_reply@mail.your.domain.com
              SMTP_PASS: your_email_user_password
              SMTP_SENDER_NAME: MySupabase
              SMTP_ADMIN_EMAIL: adminxxx@mail.your.domain.com
              ENABLE_ANONYMOUS_USERS: false

不要忘了使用 app.yml 来重载配置

进阶主题：真·高可用

经过这些配置，您拥有了一个带公网域名，HTTPS 证书，SMTP，PITR 备份，监控，IaC，以及 400+ 扩展的企业级 Supabase （基础单机版）。 高可用的配置请参考 Pigsty 其他部份的文档，如果您懒得阅读学习，我们提供手把手扶上马的 Supabase 自建专家咨询服务 —— ¥2000 元免去折腾与下载的烦恼。

单节点的 RTO / RPO 依赖外部对象存储服务提供兜底，如果您的这个节点挂了，外部 S3 存储中保留了备份，您可以在新的节点上重新部署 Supabase，然后从备份中恢复。 这样的部署在故障时可以提供一个最低标准的 RTO （小时级恢复时长）/ RPO （MB级数据损失）兜底容灾水平 兜底。

如果想要达到 RTO < 30s ，切换零数据丢失，那么需要使用多节点进行高可用部署，这涉及到：

• ETCD： DCS 需要使用三个节点或以上，才能容忍一个节点的故障。
• PGSQL： PGSQL 同步提交不丢数据模式，建议使用至少三个节点。
• INFRA：监控基础设施故障影响稍小，建议生产环境使用双副本
• Supabase 无状态容器本身也可以是多节点的副本，可以实现高可用。

在这种情况下，您还需要修改 PostgreSQL 与 MinIO 的接入点，使用 DNS / L2 VIP / HAProxy 等 高可用接入点 关于这些部分，您只需参考 Pigsty 中各个模块的文档进行配置部署即可。 建议您参考 conf/ha/trio.yml 与 conf/ha/safe.yml 中的配置，将集群规模升级到三节点或以上。

面向未来数据库的现代硬件

原文链接：https://transactional.blog/blog/2024-modern-database-hardware

本文是一篇关于硬件发展如何影响数据库设计的综述，介绍了网络、存储、计算三个领域的关键硬件进展。充分利用好新硬件而非折腾分布式，才是数据库内核发展的正路。 阅读全文

MySQL还有机会赶上PostgreSQL吗？

原文链接：https://www.percona.com/blog/can-mysql-catch-up-with-postgresql/

Percona创始人Peter Zaitsev讨论MySQL是否还能跟上PostgreSQL的脚步。作为MySQL生态的主要扛旗者，Percona的看法在相当程度上代表了MySQL社区的想法，这篇文章值得每个关注数据库发展的人阅读。 阅读全文

开源“暴君”Linus清洗整风

Linus踢出了几位俄罗斯籍开发者，引发开源世界一片哀嚎。但Linux是Linus的个人项目，三十年前是，现在也依然是。Linux社区本质是帝制的，而Linus本人就是最早且最成功的技术独裁者。 阅读全文

先优化碳基BIO核，再优化硅基CPU核

原文链接：https://world.hey.com/dhh/optimize-for-bio-cores-first-silicon-cores-second-112a6c3f

程序员是昂贵稀缺的生物计算核心，是软件成本的锚钉。硅制计算内核丰富而成本不断下降，而生物核却日益稀缺昂贵。因此优化CPU核之前，请优先考虑优化生物核——这正是Ruby on Rails的设计哲学。 阅读全文

MongoDB没有未来：好营销救不了烂芒果

MongoDB在诚信上劣迹斑斑，在产品和技术上乏善可陈，在正确性、性能、功能上被PostgreSQL吊打，开发者口碑崩塌，热度下滑，股价腰斩，亏损扩大。碰瓷引战PG，好营销也救不了它。 阅读全文

MongoDB：现在由PostgreSQL强力驱动？

MongoDB 3.2的分析子系统竟然是一个嵌入式的PostgreSQL数据库？由MongoDB的合作伙伴发出的血泪控诉与吹哨故事，揭露了MongoDB对待生态伙伴的态度和一些黑历史。 阅读全文

瑞士强制政府软件开源

瑞士政府通过开源立法走在时代前沿，强制要求公共部门使用开源软件。真正的自主可控根源在于"开源社区"，而不是某些民族主义式的国产软件。公共资金，公共代码。 阅读全文

MySQL安魂九霄，PostgreSQL驶向云外

MySQL 9.0终于发布，距离上一次大版本更新已经过去八年。然而这个空洞无物的所谓"创新版本"犹如一个恶劣的玩笑，宣告着MySQL正在死去。Percona CEO也表示：有了PostgreSQL，谁还需要MySQL呢？ 阅读全文

CVE-2024-6387 SSH漏洞修复

CVE-2024-6387是一个严重的OpenSSH漏洞，影响EL9、Ubuntu 22.04、Debian 12等较新版本操作系统。老系统如CentOS 7.9、Ubuntu 20.04因OpenSSH版本老反而逃过一劫，请用户及时更新修复。 阅读全文

Oracle还能挽救MySQL吗？

原文链接：https://www.percona.com/blog/can-oracle-save-mysql/

Percona创始人Peter Zaitsev在官方博客上公开表达了对MySQL及其知识产权属主Oracle的失望，以及对版本越高性能越差的不满。作为MySQL生态的主要扛旗者，Percona的公开表态是一个值得关注的信号。 阅读全文

Oracle最终还是杀死了MySQL

原文链接：https://www.percona.com/blog/is-oracle-finally-killing-mysql/

Peter Zaitsev是MySQL生态重要公司Percona的创始人，他撰文痛批Oracle的作为与不作为杀死了MySQL。约15年前Oracle收购了Sun从而拥有了MySQL，当时关于Oracle何时会"扼杀MySQL"的讨论此起彼伏，如今一语成谶。 阅读全文

MySQL性能越来越差，Sakila将何去何从？

原文链接：https://www.percona.com/blog/sakila-where-are-you-going/

MySQL版本越高性能反而越差？Percona监控发现从5.7迁移到8.x的步伐明显缓慢。在PostgreSQL高歌猛进吞噬数据库世界的同时，MySQL的性能和功能被甩开越来越远。云厂商白嫖是主要原因之一。 阅读全文

20刀好兄弟PolarDB：论数据库该卖什么价？

PolarDB数据库每节点许可证只卖130块？国内IT已经卷到这个阶段了吗？今天来聊聊商业数据库、开源数据库、云数据库、国产数据库的公允价格到底是多少。 阅读全文

国产数据库到底能不能打？

国产数据库到底能不能打？这是个得罪人的问题，不妨用数据说话。本文通过流行度等指标分析数据库生态格局，帮助读者建立更为准确的比例感认知，了解国产数据库在全球市场中的真实位置。 阅读全文

Redis不开源是“开源”之耻，更是公有云之耻

Redis从7.4起使用RSALv2与SSPLv1，不再满足OSI关于开源软件的定义。这不是Redis的耻辱，而是开源/OSI的耻辱，更是公有云厂商白嫖社区成果的耻辱。当下软件自由的头号敌人是公有云服务。 阅读全文

MySQL正确性竟如此垃圾？

MySQL的事务ACID存在缺陷，且与文档承诺不符。JEPSEN测试揭示MySQL的可重复读隔离级别既不原子也不单调，连基本的单调原子视图都不满足。这可能导致严重的正确性问题，使用时请务必谨慎。 阅读全文

数据库应该放入K8S里吗？

数据库是否应该放入Kubernetes里，到今天仍然是一个充满争议的话题。K8S在无状态应用管理上非常趁手，但处理有状态服务特别是数据库时有本质局限性。本文深入探讨为什么将数据库放入K8S不是明智选择。 阅读全文

专用向量数据库凉了吗？

向量存储检索是个真需求，然而专用向量数据库已经凉了。小微需求OpenAI亲自下场解决了，标准需求被加装向量扩展的现有成熟数据库抢占。想靠讲AI故事做成一个产业已经是不可能了。 阅读全文

数据库真被卡脖子了吗？

很多"国产数据库"就是烂泥扶不上墙的残次品，信创约等于IT预制菜进校园。用户捏着鼻子迁移，开发者假装在卖力。基础软件行业其实没人卡脖子，真卡脖子的都是所谓"自己人"。 阅读全文

EL系操作系统发行版哪家强？

RHEL系列操作系统发行版兼容水平：RHEL = Rocky ≈ Anolis > Alma > Oracle » Euler。推荐使用RockyLinux 8.8，有国产化要求可以使用Anolis 8.8。CentOS 7.9明年EOL，是时候升级OS了。 阅读全文

基础软件需要什么样的自主可控？

当我们说自主可控时，到底在说什么？运维自主可控与研发自主可控，国家/用户真正需要的自主可控是前者，而不是华而不实的"自研"。国家的需求很简单：打仗吃制裁后，现有系统还能不能继续跑起来。 阅读全文

正本清源：技术反思录

降本增效的主旋律触发了所有技术的价值重估，当然也包括数据库。本系列将评述数据库领域热点技术，并对其在当下的利弊权衡发出灵魂拷问：云数据库、分布式数据库、微服务、K8S容器化等技术，究竟是真需求还是伪需求？ 阅读全文

数据库需求层次金字塔

与马斯洛需求金字塔类似，用户对数据库的需求也有递进的层次：功能正确性、安全备份、高可用监控、性能成本、可观测性、易用性控制、标准化产品化、最终达到超越与自我实现。 阅读全文

分布式数据库是不是伪需求？

随着硬件技术进步，单机数据库的容量和性能已达到前所未有的高度。分布式TP数据库在这种变革面前显得极为无力，和"数据中台"一样穿着皇帝的新衣，处于自欺欺人的状态里。 阅读全文

微服务是不是个蠢主意？

原文链接：https://world.hey.com/dhh/microservices-are-a-bad-idea-7a8dbddc

连SOA典范亚马逊自己都觉得微服务和Serverless拉胯了。Prime Video团队放弃微服务改用单体架构，运营成本节省了惊人的90%。微服务就像塞壬歌声一样诱惑你为系统添加毫无必要的复杂度。 阅读全文

是时候和GPL说再见了

原文链接：https://martin.kleppmann.com/2021/04/14/goodbye-gpl.html

DDIA作者Martin Kleppmann认为应远离GPL及相关许可证，因为它们未能实现其目的，造成的麻烦比产生的价值更大。在2020年代，计算自由的敌人是云软件，本文倡导本地优先软件的概念。 阅读全文

容器化数据库是个好主意吗？

生产环境的数据库是否应当放入容器中，仍然是一个充满争议的问题。站在开发者角度我喜欢Docker，但站在DBA立场上，我认为就目前而言，将生产环境数据库放入Docker/K8S中仍然是一个馊主意。 阅读全文

理解时间：闰年闰秒，时间与时区

四年一遇的闰年2月29日，总有土鳖软件出现大翻车。对时间的正确理解，对正确处理工作生活中的时间问题很有帮助。本文聊一聊闰年、闰秒、时间与时区的原理，以及在数据库与编程语言中的注意事项。 阅读全文

理解字符编码原理

如果不了解字符编码的基本原理，即使只是简单常规的字符串比较、排序、随机访问操作，都可能会一不小心栽进大坑中。本文详细解析ASCII、Unicode、UTF-8等编码原理，希望能讲清楚这个问题。 阅读全文

并发异常那些事

并发程序很难写对，更难写好。很多程序员只是把问题丢给数据库，但即使最强大的ACID数据库也会使用弱隔离级别。本文阐述SQL92标准定义的隔离级别及其缺陷，以及现代模型中的隔离级别定义。 阅读全文

区块链与分布式数据库

区块链的技术本质、提供的功能及演化方向就是分布式数据库。确切地讲，是拜占庭容错（抗恶意节点攻击）的分布式（无领导者复制）数据库。智能合约本质上就是这个分布式数据库上的存储过程。 阅读全文

一致性：过载的术语

一致性这个词重载得很厉害，在不同语境中代表着不同的东西。ACID里的C指事务一致性，CAP里的C指线性一致性，此外还有"一致性哈希"、“最终一致性"等不同涵义。本文梳理这些概念的区别。 阅读全文

为什么要学习数据库原理

只会写代码的是码农，学好数据库基本能混口饭吃。然而对优秀的工程师来说，只会用数据库是远远不够的。绝大多数应用都是数据密集型应用，数据库提供了对应用通用存储需求的高级抽象。 阅读全文