标签: PostgreSQL

2026 年 8 月 19 日，The Register 刊出了一篇对 Michael Stonebraker 的采访。这位图灵奖得主、伯克利 Postgres 项目的发起者、八十多岁还在创业的老先生，被问到 PostgreSQL 为什么会赢，给了一个听上去有点意外的答案： 我们得感谢 Oracle 我们得感谢 Oracle。因为他们买下 MySQL 之后，所有人都开始担心 MySQL 的去向会被 Oracle 主导，而那正是 PostgreSQL 崛起的开端。 他在同一段话里还说 …

微信公众号原文 2026 年 8 月 19 日，The Register 刊出了一篇对 Michael Stonebraker 的采访。这位图灵奖得主、伯克利 Postgres 项目的发起者、八十多岁还在创业的老先生，被问到 PostgreSQL 为什么会赢，给了一个听上去有点意外的答案： 我们得感谢 Oracle。 我们得感谢 Oracle。因为他们买下 MySQL 之后，所有人都开始担心 MySQL 的去向会被 Oracle 主导，而那正是 PostgreSQL 崛起的开端。 他在同一段话 …

PostgreSQL 发布了最新一轮小版本更新。这次更新修复了 28 个安全漏洞和 110 多个 Bug。考虑到 7 月以来 Claude Fable 和 ChatGPT Sol 5.6 级别的模型已普遍可用，发现大量漏洞与 Bug 也是意料之中的结果。 老冯建议所有用户尽快安排 PostgreSQL 小版本升级。Pigsty 将于次日发布 v4.5，提供包含最新 PostgreSQL 18.6 的离线安装包。这将是 Pigsty v5.0 与 PostgreSQL 19 发布之前的最后一次小版 …

今天老冯来和大家聊一聊《母猪的产后护理》。俺做的新开源项目 SOW，翻译成中文就是“老母猪”。 做一个 PostgreSQL 发行版，最折磨人的往往不是把软件编译出来，而是收拾编译出来的东西。 Pigsty 要为多个 Linux 发行版、多个 CPU 架构、多个 PostgreSQL 大版本维护成百上千个组件。不同组合一路展开，最终落到仓库里的制品超过十万个：RPM、DEB、索引、签名、校验和、快照，还有一堆为了兼容包管理器而存在的元数据。 用户看到的只是 apt install 或 dnf …

今天下午几个群里朋友 @ 我：PostgreSQL 官方仓库正式上架龙芯 CPU 支持。 事情是这样的。7 月 22 日，PGDG APT 仓库的维护者 Christoph Berg 在 pgsql-pkg-debian 邮件列表上发了一封很短的公告，交代了三件事：apt.postgresql.org 新增 Loongson loong64 架构；构建主机是一块由 loongfans.cn 社区提供的龙芯 3B6000；软件包的自举构建已在本月初完成，仓库现已正式可用。 我顺手跑到 PGDG …

前两天，一个叫 pgrust 的项目冲上了 Hacker News 头条：作者借助 AI，用 Rust 搬了一遍 PostgreSQL，还跑通了核心回归测试。 中文媒体的标题已经在路上了：“AI 用 Rust 重写了 PostgreSQL”。 可我把仓库、提交历史和测试脚本翻了一遍之后，觉得这件事最有意思的部分，恰恰不在标题里。 pgrust 花了两个月，亲手证明了一个和二手标题相反的事实：它用两个月时间，亲手证明了自己想推翻的东西。 引子：一天十二倍 先说作者。Michael Malis 不是 …

今天（2026 年 7 月 8 日）是 PostgreSQL 的 30 岁生日。 三十年前的这一天，Marc Fournier 在刚刚架设好的 CVS 仓库里敲下了一笔名为「Postgres95 1.01 Distribution - Virgin Sources」的提交。这是 PostgreSQL 代码仓库中的第一笔提交（d31084e），至今仍躺在 Git 历史的最底端。 为什么是 7 月 8 日？ 每年 7 月 8 日，PostgreSQL 社区都会互道一声「Happy …

老冯在半年前（2026-01-08）写过一篇文章《Git for Data：瞬间克隆 PG 数据库与实例》，介绍了 PostgreSQL 18 和 Pigsty v4.0 的一个新特性：瞬间克隆新数据库。利用文件系统 CoW 机制，以及 PG 18 的 file_copy_method = clone 新参数，可以在秒级克隆一个非常大的数据库，而且不占用额外的存储。 这玩意儿其实非常适合 AI Agent 使用。我在《Agent 需要什么样的数据库》里提到过：极低成本的数据库克隆对于反事实推演至 …

经常有人问我：Pigsty 到底是什么？我通常回答：PostgreSQL 发行版。 通常下一个问题就是：那 “PostgreSQL 发行版” 又是什么？ 这是个好问题。而要把它讲清楚，最好的切入点不是数据库，而是操作系统。 一、从 Linux 与操作系统发行版说起 说起 Distribution（发行版），绝大多数人第一反应都是 Linux 发行版 —— Red Hat、Debian、Ubuntu、SUSE、Arch…… 但问题是：既然已经有 Linux，为什么还需要 Linux 发行版？两者到 …

引子：几个数据库人，不约而同做了文件系统 最近半年，Agent 基础设施圈发生了一件耐人寻味的事：几位资深数据库人，先后做起了“给 AI Agent 用的文件系统”。 Timescale 的 TigerFS，把 PostgreSQL 挂载成一棵目录树，每个文件是一行记录，目录是表，写入带事务，变更可版本化。Turso 的 AgentFS，把 agent 的文件、KV 状态、工具调用审计痕迹装进一个 SQLite-backed 的文件系统里，可以快照、隔离、搬走、fork。AGFS 则把数据库、消 …

今天有个直播，是关于 PostgreSQL 三十周年的。我知道绝大多数人都没这个功夫去看一个九十分钟的直播，所以就把老冯的一些观点转成了文章，发在这里。 一、三十岁，是怎么算出来的 先回答一个考据问题：PostgreSQL 的三十岁，到底是怎么算的？ 要按最早的算法，得从 1986 年算起。那一年，数据库祖师爷，图灵奖得主，伯克利的 Michael Stonebraker —— 老冯译作 “石破天”—— 启动了 Ingres 的续作，Post-Ingres，简称 Postgres。照这个算法， …

微信原页已失效；正文从明确署名的公开镜像恢复：https://www.163.com/dy/article/KTG7NBBQ0556CSY5.html。 今天是 PGConf.Dev 2026 开幕的第一天，老冯在大会上有一场 25 分钟的主题演讲，Extensions for Everyone，介绍了我最近两年在扩展 Packaging 与分发上的工作，以及这些工作如何能够帮助到所有人 —— 用户，DBA，扩展作者，PG供应商，以及内核黑客。 \ 演讲的演示文稿与录像后面会放出，不过如果你对 …

在线幻灯片：人人都能用上的 PostgreSQL 扩展 第一部分：引言 0. 人人都能用上的扩展 00. 人人都能用上的扩展 大家好，这次演讲的题目是「人人都能用上的扩展」。 它讨论的是 PostgreSQL 扩展的交付，以及一个共享的交付层，如何同时让用户、扩展作者、厂商和 PostgreSQL 内核开发者受益。 1. 我是谁 01. 我是谁 我是冯若航，Pigsty 的作者和维护者。Pigsty 是一个开源 PostgreSQL 发行版。 我也是 pgext.cloud 的建设者 …

温哥华时间 5 月 19 日，PGConf.Dev 2026 正式拉开序幕。今年的会场在 Simon Fraser University 市区校区，也就是 SFU Vancouver Harbour Centre，和第一届 PGConf.Dev 一样，还是在温哥华。 PGConf.Dev 是 PostgreSQL 全球开发者大会，前身是 PGCon。它是核心开发者、扩展作者、社区组织者一年一度最重要的聚会之一。今年又刚好赶上 PostgreSQL 项目 30 周年，社区围绕这个节点专门安排了不少 …

发布者：PostgreSQL Global Development Group 分类：PostgreSQL 项目安全 PostgreSQL 全球开发组发布了所有受支持 PostgreSQL 版本的更新，包括 18.4、17.10、16.14、15.18 和 14.23。本次发布修复了 11 个安全漏洞，以及过去几个月中报告的 60 多个 bug。 完整变更列表请参阅发行说明。 PostgreSQL 14 生命周期结束提醒 PostgreSQL 14 将于 2026 年 11 月 12 日停止接收 …

几天前，PG 生态的顶级开源备份工具 pgBackRest 宣告停止维护。 老冯的 Pigsty 虽然也用着 pgBackRest，但也不着急，因为我知道这么重要的组件 pgBackRest，PostgreSQL 生态不可能真让它死掉。 但也承诺如果过一段时间都没人接盘，我会来接手维护。现在看来，倒是不需要了。 David Steele 在 GitHub README 上发了一份“维护更新”：归档公告发出之后，他的邮箱被打爆了。 很多用户和厂商都希望项目继续；他自己也愿意继续；更关键的是，多个赞 …

4 月 27 日，PostgreSQL 生态里最重要的备份工具 pgBackRest 被作者 David Steele 正式归档了。 声明发在 GitHub 和 LinkedIn 上，干净利落： 停止维护公告 简而言之：pgBackRest 已不再维护。如果你基于 pgBackRest 创建分叉项目，请为你的项目另取一个新的名称。 经过反复思量，我决定停止继续维护 pgBackRest。这并不是一个轻率的决定。过去十三年里，pgBackRest 一直是我倾注热情的个人项目；期间我很幸运，在相当长 …

HOW 2026 主题演讲：给 DBA Agent 以身体 第一部分：引子 —— 一个离谱的现象 1 封面 大家好，我是冯若航，本次工具会场的出品人。虽然这是一个 PG 工具主题的会场，但今天我不想讲某个命令行工具又加了多少新功能，而是想讲一个更本质的问题： 为什么到了今天，真正能管理生产数据库的 Agent 还是这么少见？ 我的判断很简单——大模型已经够聪明了，它缺的不是脑子，缺的是身体。 它要能看到状态、执行动作、判断风险、留下证据，还要能在搞砸以后退回来。今天我要聊的，就是如何给 DBA …

两年前我写了一篇 《MySQL 安魂九霄，PostgreSQL 驶向云外》，那时候 MySQL 9.0 刚发布，Oracle 敲锣打鼓搞了个 VECTOR 数据类型出来，吹成“AI 时代的 MySQL”。我当时一看：这玩意就是一个 BLOB 换皮。没有距离函数，没有向量索引，除了能往列里存一堆浮点数之外，什么也干不了。 之后的两年，9.0 到 9.6，七个 Innovation Release，每季度一个。Percona 看了一眼这七个版本，一个都没跟。PMM 遥测数据显示 Innovation …

几个月前，老冯写过一篇《Agent 操作系统时刻》。那篇文章里我做了个判断：Agent 基础设施的下一场热闹会发生在“记忆”这个方向，围绕着“Agent 该怎么记住东西”会冒出一大批创业公司和开源项目，资本会涌进来，架构图会画得越来越花。 果不其然，Mem0 又融了一轮，MemGPT 改名 Letta 继续融，Zep、Cognee、Hindsight、MemoryScope、Memobase、SuperMemory、Graphiti、LangMem、EverMemOS——一抓一大把。每家的技术博 …

一个 Issue ，引发扩展马拉松；32 个新扩展告诉你，PostgreSQL 正在变成什么；504 个扩展，PostgreSQL 生态的天花板在哪？ 从一个化学扩展说起 两天前，一位用户在 GitHub 上给我提了个 Issue：他在用 RDKit —— 化学信息学领域的事实标准库，能在 PostgreSQL 里做分子结构存储、子结构检索和相似性计算。 但他发现 PGDG 官方打包的版本缺了 InChI 功能，他自己折腾了半天，加上编译参数后总算跑通了，但还是希望 Pigsty 能原生支持。 …

最近做了一场直(录) 播，聊了聊 PostgreSQL 与 AI 这个话题。直播里主持人问了很多好问题，老冯也做了些回答。 直播将在周二晚上放出，老冯这里把我（很多没说的）观点整理成文字稿，做了些展开和补充，希望对大家有所帮助。 PG 现在是什么状态？ Q：PostgreSQL 当下在数据库世界里是什么状态？ PostgreSQL 已经成为数据库世界的事实标准。 它实现了类似 Linux 内核在操作系统领域的地位——整个生态正在不可逆地向 PostgreSQL 集中。引用 Andy Pavlo …

PostgreSQL 赢得数据库增量世界，并已在存量上与 MySQL 相当。此消彼长之下，未来数据库世界的内核之争已不再有悬念。 一、开发者采用率 直接上数字。 Stack Overflow 2025 49,000+ 份有效回复，177 个国家。PG 同比 +6.9pp，MySQL 同比 +0.2pp。连续三年三冠王。2025 年首次公布的数据库迁移流向图，Stack Overflow 自己的原话是：“all databases are migrating to PostgreSQL”。 …

昨天是愚人节，德哥在公众号发了一篇文章，标题叫《在阿里当牛马的最后一天》。 圈里立刻炸了锅。很多人说这是愚人节玩笑，但老冯知道，这根本不是玩笑。 因为早在几周前的 “HOW 大会” 活动海报上，德哥的 title 就已经悄悄变成了 “前阿里云数据库专家”。 今天，他又发了一篇《阿里离职后的第一站》，算是把这件事彻底实锤了。 之前 通义千问大模型的灵魂人物林俊旸离职，老冯写了一篇聊过。当然因为大模型是当下的 “当红炸子鸡”，关注度摆在那儿。 数据库虽然在 AI 时代依然非常重要，但毕竟没有大模型那 …

昨天，老冯发布了 PostgreSQL 官网的中文镜像站 PG.center。一经上线，就感受到了广大用户的热情。不过在昨天刚发布的时候，站上还只有 PG 18 的中文文档。虽然 PG 17、16、15、14 这四个大版本也都仍在生命周期内，但我之前偷了个懒，先拿英文版顶了一下。 今天我的 Codex 配额刷新了，所以我又“烧掉”了这一周的额度，把剩下这几个大版本的文档全部翻译成了中文。现在，PG 生命周期内的五个大版本中文文档，已经全部正式发布了！ PostgreSQL 18 中文文档（当前最 …

用 PostgreSQL 这么多年，有一件事一直让我觉得遗憾：postgresql.org 官网一直没有中文版。 作为世界上最先进的开源数据库，PostgreSQL 的官方网站承载着项目介绍、版本发布、官方文档、社区活动、开发者资源等核心信息。对于英文用户来说，这是一站式的信息中枢；但对于国内广大的 PG 用户而言，语言门槛始终横亘在那里。 所以我做了一件事：把 postgresql.org 整个 fork 了一份中文版。 域名是：pg.center。 包括当下缺失的 PG 18 中文文档，也随 …

一年前，我写过一篇文章叫《PGFS：将数据库作为文件系统》。当时是为了解决 Odoo 社区的一个需求：将文件与 PostgreSQL 数据库一起做 PITR，回滚到指定时间点。 方案运行得还不错。它用纯软件的方式，实现了原本需要昂贵 CDP 专用硬件才能实现的功能，也就是让文件系统与数据库一起回滚到任意时间点。性能也行，对于 Odoo、Dify 这类应用绰绰有余。 但最近我发现，这个方案吸引了不少意想不到的用户。他们不是来做 ERP 的，而是来 存 AI Agent 状态 的。 做法其实很简单： …

扩展目录：中文站 · 英文站 扩展是 PostgreSQL 的灵魂。没有扩展的 PostgreSQL，只是一个普通的关系型数据库；有了扩展的 PostgreSQL，才是那个能吞噬整个数据库世界的超级平台。 但长期以来，PG 扩展生态一直面临一个尴尬的问题：找不到、看不懂、装不上。你想用一个扩展，得先去 GitHub 翻 README，再去 PGXN 碰运气看有没有包，然后对着不同操作系统的包管理器折腾半天。运气好装上了，运气不好，编译失败、依赖缺失、版本不兼容，一下午就没了。 所以我做了一件事 …

老冯最近发现了一个有意思的项目：InsForge。口号是——为 AI 编程设计的 Supabase。 Apache 2.0 开源，GitHub 约 2000 Star，核心技术栈是 PostgreSQL + PostgREST + Deno + TypeScript，5 个容器就能跑起来。老冯收集大宝贝的毛病又犯了，赶紧把它加入到 Pigsty 代自建全家桶里来（随下个版本一起发布）。 这个项目触及了一个真实的痛点，值得展开聊聊。 Vibe Coding 的“最后一公里” 2025 年以来 …

今天老冯又让 Claude Code 干了一件大好事 —— 做了一个全新的 PostgreSQL 扩展目录。就放在 https://pigsty.cc/ext 这里。 说起来，这已经是第五版了。兜兜转转一大圈，又回到了第一版使用的 Hugo + Docsy 框架，重新融合到 Pigsty 主站。这个过程本身就是个故事，后面再聊。先说说这一版到底做了什么。 不只是有包，还要有文档 之前的扩展目录，核心功能是告诉你：这个扩展叫什么、元数据在哪里、二进制包怎么下载、一键安装怎么搞。你装好了就行，至于怎 …

最近 Pigsty v4.2 刚发布完，手头空了下来。正好一看，这周的 Claude Token 额度快到期了，不用也是白扔。一时心痒，得找个活儿把它挥霍掉。 想了想，去翻译文档吧。 于是我花了一天时间，把 PgBouncer 连接池、pgBackRest 备份工具、Patroni 高可用模板 这三个 PostgreSQL 生态中最重要的开源组件文档，全部翻译成了中文。顺手还把 PostgreSQL 18.3 的官方文档也过了一遍——虽然还在校对中，但主体已经出来了。 干完之后我自己都有点恍惚： …

老冯之前在号外：PG小版本BUG，暂缓一周再安装升级里面说过，之前发布的 PG 小版本有 BUG，需要等新的号外小版本更新之后再部署合适。这不，PG 18.3，17.9 …… 系列小版本如期而至，10 天不到就新鲜出炉了。 不过目前 PGDG 还没出包，镜像站可能还要再晚一天才行。老冯正在快马加鞭测试准备 Pigsty v4.2 ，等 PGDG 一出包就制作离线软件包，发布一个新版本。 PostgreSQL 18.3、17.9、16.13、15.17 和 14.22 发布！ 发布日期 …

很多国产数据库都以 “兼容 Oracle” 作为卖点，说实话，老冯一直都对这件事不感冒。有时候我也会怀疑，PG 去兼容 Oracle 到底是不是一个伪需求—— 改改业务代码能死吗？但是最近我真的碰到了一个极端情况，让我略微改了看法。 一个没有源码的 JAR 包 最近老冯接了个小活儿，挺有意思的。某世界 500 强车企，手里跑着一套 EDB —— 也就是 EnterpriseDB 出品的、带 Oracle 兼容的 PostgreSQL。版本是 9.1。 9.1 是什么概念？2011 年 9 月发布 …

18.2 系列小版本引入两个 BUG，请暂缓新建与升级，并及时在下周 18.3 发布后更新。 一周前 PostgreSQL 社区发布了二月度例行小版本更新，Pigsty v4.1 也于当天跟进。 不过老冯必须提醒各位，最好不要在最近两周进行 PostgreSQL 新增部署与更新，因为这个例行小版本引入了两个 BUG。 这两个 BUG 将在 2026-02-26 的 号外小版本（out-of-cycle release）中修复。 表现 BUG 1：substring() 对非 ASCII …

凌晨三点，数据库告警炸了。 你尝试把告警信息甩给一个 “顶级” DBA Agent。它见多识广，熟读 PostgreSQL 文档，能写出漂亮的诊断 SQL，对每一个内核参数的含义倒背如流。 它愣住了：集群拓扑是什么样的？主从都在哪些服务器上？监控面板怎么看？日志哪里找？上次类似故障怎么解的？我该用什么工具执行什么操作？ 什么都不知道。 而隔壁那个用普通模型、但深度接入了完整运维环境的 Agent，已经定位到根因、完成了切换重启、发出了复盘报告。 原理很朴素 —— 一个熟悉环境的普通人，会比来到陌 …

上午收到邮件，我提交的主题演讲 “Extensions for Everyone” 被 PGConf.dev 2026 正式接收了。 对老冯而言，这意义重大——这不仅是我在 PostgreSQL 生态的工作被核心社区认可，更重要的是：这应该是第一次有来自中国本土的 “厂商” 在 PostgreSQL 最核心的开发者大会上做主题演讲。 —— 或者更准确地说：**数据库个体户 **😊 为什么这很重要？ PGConf.dev 是 PostgreSQL 开发者大会，前身是连续举办了 17 年的 …

一、软件世界大熔断 软件世界正在经历一场史诗级的估值崩塌。 这不是个别公司的问题。这是整个 SaaS 板块的系统性崩盘。华尔街在用真金白银投票：这些软件公司的商业模式，正在被判死刑。 为什么？ 因为资本市场终于意识到一件事：这些 SaaS 产品的本质，不过是 “数据库的漂亮皮肤” 。一个 CRUD 后台，加一套业务逻辑，再包一层好看的 UI。 而这三样东西，AI Agent 全都能做。而且做得更快、更便宜、更个性化。 2025年初，微软 CEO 纳德拉说：“SaaS is Dead”。 当时很多 …

2025 年，编程 Agent 大爆发。Claude Code 能帮你写代码、跑测试、修 Bug，自主完成复杂工程任务， 堪称 ChatGPT 横空出世后的第二次史诗级大地震。 但仔细观察这些 Agent 的工作方式，你会发现一个惊人的事实：它们的底层操作极其 “原始”。 它直接操作你的文件系统和终端，虽然有一些内置的确认机制，但本质上仍依赖 “信任模型” 而非 “隔离模型”。 这就像早期程序可以随意覆写任何内存地址一样 —— 系统的安全边界，取决于程序员的自觉。 这让我想起了 1980 年代的 …

OpenAI 官方博客昨天发了一篇文章，专门讲他们如何把 PostgreSQL 伸缩到今天这个量级： 一套单主 + 近 50 个只读副本的超大 PostgreSQL 集群，支撑其核心产品（ChatGPT 与 OpenAI API）的全球访问流量。 文章的核心内容，其实在 2025 年 PGCon.Dev 上就已对外分享过 (《OpenAI：将PostgreSQL伸缩至新阶段》)， 但这次算是 OpenAI 官方背书，传播面与影响力都明显要大多了。 与半年前的分享相比，这次博客也披露了几个关键变化 …

七八年前，老冯手里维护着一百套大规模 PostgreSQL 集群，两百多台顶配物理机，开始做高可用方案选型。 那段时间我把市面上能叫得出名字的方案都翻了一遍：Patroni、Corosync + Pacemaker、repmgr、Stolon、PAF、pgpool-II…… 最后选了 Patroni。基于它做 HA，上线后效果很稳：这些年碰到几十次真实硬件故障，RTO 基本都在二三十秒区间。 最爽的是：半夜告警响了也不用爬起来抢救，流量自动切换，第二天起床再慢慢研究和调整就好了。 回头看，这个选 …

老冯最近多次被人问到一个问题：“如何上手学习 PostgreSQL”？已经不是一次两次了，所以感觉有必要写个教程集体回答一下。 老冯认为，学习 PostgreSQL 的最好方式就是 Learn by doing —— 通过实践来学习，而不是通过死看书，报什么培训班之类的东西。 现在的学习条件要比以前好太多了，因为每个人都可以有一个非常耐心的高水平老师在身边随时指导 —— 有什么问题直接问 AI 就是了。 不过俗话说：“师傅领进门，修行在个人”。即使有 AI 助力，起步的那个入门过程依然是最难的， …

原作者：VAGE · 微信公众号转载页 2026，1月1日元旦当天，中国银行APP故障： 故障原因，先有消息说因为连接池满、无法与数据库建立新的连接导致。 但进一步暴漏的信息，这里的“连接池”是数据库内的线程池BUG，导致上层应用无法和数据库建立连接，问题直指GaussDB。 现场曾重启数据库、华为的相关人员也介入解决问题，但故障依久，最终故障持续了超过1个小时，才恢复正常。 我对故障具体细节并不关心，去年（2025年）金融行业IT基础设施问题频发，四大行有两家都未能幸免（工行与中行），支付宝 …

原文地址：https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-retrospective.html 作者：Andy Pavlo，翻译与评论：冯若航 2025 数据库世界年度回顾 作者: Andy Pavlo - 卡内基梅隆大学 发布日期: 2026 年 1 月 4 日 译者注: 本文翻译自 CMU Andy Pavlo 教授的博客 又是一年过去了。本来想多写几篇文章，别光指着年底憋一篇大的，奈何春季学期实在太忙，差点累死，根本抽不 …

每个程序员都用过 git clone。敲下回车，几秒钟后，一个完整的代码仓库就躺在硬盘上了。 但数据库呢？ 想给测试环境搞一份生产数据的副本？传统方案是 pg_dump + pg_restore。一个 100GB 的库，喝杯咖啡回来可能还没完。想做并行测试？再等一轮。想给 AI Agent 一个可以随便折腾的沙盒？那得准备好足够的磁盘和耐心。 最近一堆数据库公司都在卷 “Git for Data”，理由是：有了数据版本控制，Agent 就可以放心在数据库里乱搞，坏了随时回滚。 但这玩意 …

最近，图灵奖得主、Postgres 创始人、MIT 与 UC Berkeley 计算机系教授 Mike Stonebraker， 以及数据库领域大网红、卡耐基梅隆大学数据库系教授 Andy Pavlo 联合主持了一期播客， 回顾了 2025 年 AI 对数据库的影响、数据库行业的重大事件，以及 AI 对计算机科学教育和职业发展的作用。 老冯转录了视频的文字稿，翻译并点评了一下，供大家参考。 Data 2025：年度回顾 —— Mike Stonebraker 与 Andy Pavlo 对谈录 录 …

原作者：瑞典马工 · 微信公众号转载页 对于数据库从业者来说， 2026年，只有一个重要的问题：谁将赢得AI时代的数据库市场？ 这不是技术特性的比拼，也不是营销预算的较量。我认为决定数据库胜负的是三个要素：技术套件、标杆案例、生态系统。MySQL用LAMP + Facebook + Stack Overflow赢得2000s。PostgreSQL用Heroku/Vercel + Instagram + 云厂商赢得2020s。都是三要素在起作用。 AI时代谁会赢？除了骗子， 没有人敢说自己已经有 …

当我们讨论"AI 时代的数据库"时，很容易陷入一个思维陷阱——认为这场变革需要什么全新的存储引擎、什么革命性的索引结构、什么颠覆性的查询语言。 但如果我们冷静审视这个问题，答案可能恰恰相反：真正的变革不在数据库内核，而在数据库之上的那一层。 微信公众号原文 一、缸中之脑 当前 AI Agent 的处境颇为尴尬。 它们拥有令人惊叹的推理能力——能写代码、能做分析、能进行复杂的多步规划——却被迫栖身于"文件系统 + 外部脚本"的简陋环境中。LangChain 默认用 InMemoryStore，进程 …

Agent 时代，软件架构的底层逻辑变了。 过去十年，我们为了迁就人类团队的协作边界，搞出了微服务和“多元持久化”（Polyglot Persistence），把系统拆得七零八落。 但在 AI Agent 崛起的新范式下，这种碎片化架构正在成为一种昂贵的“技术负债”。 最稀缺的资源不再是存储或算力，而是 LLM 的 注意力带宽（Context Window）。 微服务带来的复杂度与碎片化，正在向 AI Agent 征收巨额的“认知税”。 而这剂毒药的解药，只有 PostgreSQL。本文就来聊聊 …

大家好，我是冯若航，Pigsty 的作者，独立开源贡献者。 今天我想和大家聊一个话题：如何打造一个立足中国，面向全球的 PostgreSQL 数据库发行版。 这个标题听着有点大，但我想说的很简单：PostgreSQL 已经赢了，问题是 —— 我们中国开发者在这场胜利中扮演什么角色？ 是旁观者，还是参与者？是跟随者，还是引领者？ 数据库内核之争已经尘埃落定，真正的竞争将会发生在数据库发行版上。 而在这个关键的机会窗口里，我们应该凝聚生态合力，打造一个全世界开发者都愿意使用的基础设施，数据库世界中的 …

在《尝鲜须谨慎：PG新存储引擎故障案例》中，老冯简单聊过一下 PostgreSQL 上新的节奏 —— 应该用什么 PostgreSQL 大版本。老冯的策略是：当每个 PostgreSQL 大版本的第二个小版本出来的时候，差不多就能上生产了。最近 PostgreSQL 18.1 也就是第二个小版本已经放出了，加上扩展生态也基本上普遍跟进完成，老冯认为 PG 18 已经可以用于生产环境了。 先把BUG修一修 PostgreSQL 的版本发布策略非常规律：每年一个大版本，基本上大版本都会在九月下旬发布 …

早在 2019 年，老冯就在《把数据库放入 Docker 中是一个好主意吗？》提到过 —— 不要在生产环境用容器运行 PostgreSQL 数据库，因为你有极大概率会遇上一堆在物理机/虚拟机上根本不存在的麻烦与问题。 这不，最近用 Docker “官方” 的 Postgres 镜像的用户在升级的时候就踩雷了。 昨天 PostgreSQL 社区的老法师 Gwen Shapira 在 X 发了个帖子吐槽了这个事。 ⚠️重要提醒：不要在生产环境用 Docker 官方的 Postgres 镜像。 如果非 …

微信公众号链接 PostgreSQL 拥有极为强大的扩展插件体系。 在 《PostgreSQL 正在吞噬数据库世界》中， 老冯已经阐述过 可扩展性 是 PostgreSQL 成功的核心要素。 举例来说，PG 有 GIS 领域的事实标准 PostGIS，向量数据库的瑞士军刀 pgvector，还有可以替代 ElasticSearch 的 pg_search， 以及使用 DuckDB 在 PG 内进行分析的 pg_duckdb / pg_mooncake 等等，这些扩展为 PostgreSQL 赋 …

昨天接到一个咨询的活儿，有位 Pigsty 的用户反馈数据库故障，出现 XID Wraparound 了。这个 PG 中最臭名昭著的故障在近些年已经比较少见了，不过这次的故障原因确实比较有趣，是因为使用了 TimescaleDB Hypercore 导致的 —— 这是一个实验性的新存储引擎，并且已经在最近的版本中弃用与移除。 如果你正在使用这个新的存储引擎，最好立刻检查并退回经典的 TimescaleDB 引擎与 PostgreSQL 原生表，以免数据库爆炸。 Hypercore 是什么 …

昨天在群里看到一则喜讯，Mooncake Lab 被 Databricks 收购了。 今年数据库世界几起大的收购都与 PostgreSQL 有关，Databricks 在六月份的时候 以十亿美元的价格收购了 Neon，它的老对手 Snowflake 则反手买下了 CrunchyData。更有传言说 OpenAI 拟以 20 亿的价格收购 Supabase。这次，做 PG 上 OLAP 扩展的 mooncake 成为新的收购标的。 pg_mooncake 是一个很不错的 PG 扩展插件，旨在 融合 …

原作者：IvorySQL · 微信公众号转载页 PostgreSQL 全球开发组于 2025 年 5 月 8 日发布了 PostgreSQL 18 的首个 Beta 版本，正式版已于 9 月 25 日正式上线。本文 IvorySQL 社区将为大家拆解 PostgreSQL 18 的六大亮点特性。 一、PG 异步 I/O（AIO）框架：迈出打破同步阻塞瓶颈的第一步 PostgreSQL 18 全新引入异步 I/O 子系统。新机制允许特定场景下并行执行多个异步预读操作，CPU 无需等待数据返回即可 …

这个月发生了一起沸沸扬扬的 “开源断供”事件—— KubeSphere 删除镜像跑路， 但其实还有另一件略隐蔽的 “卡脖子案例”，老冯在上个月提到过 —— 《卡脖子：PGDG切断镜像站同步通道》。 这次 “PostgreSQL 断供” 某种程度上扮演了试金石的角色，倒是很好的试出了各家数据库厂商和云厂商的成色。 老冯对此感到非常失望，停止将国内的云厂商和大学镜像站作为软件供应链上游，直接自建了 PGDG YUM/APT 仓库的国内最新同步镜像。 PGDG的“断供” PostgreSQL 是数据库 …

今天老冯起了一个新坑 —— PG 36计。这是一套关于 PostgreSQL 应用开发与运维管理的教程。今天刚刚把架子搭好，准备在后面不断填充内容。 说起这个企划，这本书还是当初 2017 年翻译完 DDIA 第一版后，我想搞的一个系列，PostgreSQL 教程，分应用，管理，内核三篇。昨天刚把 DDIA 第二版的 Claude 机翻给弄好，一下子就想到了这本书，这本书就连目录结构都是照着 DDIA 弄的，原来的版本目录如下： 当初还有两家出版社来找，怂恿我写一本。不过那时候老冯确实比较忙，所 …

生态 从PG“断供”看软件供应链中的信任问题 PostgreSQL主宰数据库世界，而谁来吞噬PG？ PostgreSQL 已主宰数据库世界 卡脖子：PGDG切断镜像站同步通道 PGEXT.DAY 2025，不见不散 OrioleDB 奥利奥数据库来了！ OpenHalo：MySQL兼容的PG PGFS：将数据库作为文件系统 PostgreSQL 生态前沿进展 小猪骑大象：PG包管理神器Pig 发布当日叫停：PG也躲不过大翻车 PG12过保，PG17上位 PostgreSQL神功大成！ …

Percona 是 MySQL 生态的扛旗者与主要三方厂商，最近几年也在进军 PostgreSQL 赛道。本文英文原文今天早上发布在 Percona 博客上。 当然 Percona 主要是想给自己打个广告，但这没毛病，这个问题也确实是存在的。所以老冯将这篇文章翻译点评一下，并与大家聊一聊这个问题。 The growing dominance of PostgreSQL and the emergence of propriety solutions PostgreSQL主导地位不断提升，专有解决 …

2025 年 StackOverflow 全球开发者调研结果已经新鲜出炉 ，来自 177 个国家与地区的 5 万名开发者给出了高质量的问卷反馈。 作为数据库老司机，我最关注的还是 “数据库” 这一项调研结果，今天就来带大家解读一下这份数据，看看数据库领域的最新趋势。 简单来说，PostgreSQL 已经是连续第三年在数据库全部三项指标上获得三冠王了，并且依然保持着高歌猛进的势头。 如果说两年前我们说 “PostgreSQL 正在吞噬数据库世界”，那么从今年的数据上来看，PostgreSQL 已经 …

老冯今天租了个车，自驾从上海一路开回宁波老家。昨天正好看到了懂车帝搞的那个自动驾驶评测视频 —— 封闭高速、真实城市路况、三十多款热门车型“智驾”实测 —— 堪称全军覆没，唯一能打的就是特斯拉，不过这节目一播，附近神州的特斯拉都租掉了，所以老冯最后还是弄了个油车，下次再体验了。 懂车帝这个视频非常及时，让俺不会再有什么选择困难症 —— 我已经决定如果要买台新能源车，认准特斯拉就完事了。 毕竟作为钢铁直男 —— 我并不在乎什么车载大沙发，冰箱内饰之类的东西，我只是想要省掉自己当司机的劳累 —— 牛 …

在《SaaS已死？AI时代，软件从数据库开始》中，微软 CEO 纳德拉曾经表示，在 Agent 时代，SaaS is Dead，而未来的软件形式将是 Agent + Database 。也就是直接由 Agent 在数据库上做 CRUD。当然这篇文章也有不小争议 —— 很多老司机表示，Agent 直通数据库，是嫌安全问题不够多，死的不够快吗？ 老实说，那种直接把整个数据库开放给世界的所谓 “MCP” 确实是这样，当个玩具可以，没人敢上生产用。不过，最近 Google 推出了一个针对数据库的 MCP …

最近老冯在构建 Pigsty 离线包的时候发现，在本地测试的时候安装的 PostgreSQL 版本不太对，17.4 比最新的 17.5 落后了一个小版本。而且在 EL10 上测试的时候发现有几个仓库报错了。奇怪的是，在香港使用全球默认仓库没问题，一旦在本地使用中国的镜像站就报错。 仔细一看，发现国内的镜像站点都与 PostgreSQL 上游仓库失去同步了：清华大学开源软件镜像站（TUNA）最后一次成功同步是5月16号，而阿里云阿里云镜像站最后的同步时间戳是 2025 年 3-31。国外的镜像站， …

这两天老冯在济南参加完 PostgreSQL 高峰论坛，正在回家路上。这次大会的规模有些超出预期 —— 主会场坐的满满当当，听说有一千五百多人。PG 圈的老朋友基本都来了，还有几位刚在蒙特利尔见过的国际友人也在，今天应该跟着大巴在济南一日游呢。 这次大会主办方是瀚高 / IvorySQL 社区，能摇来这么多人，估计得一百多万。听说最近农行投了主办方瀚高几个亿，这场大会也算是秀了秀肌肉。我觉得是挺好的一件事，资源就应该投向做实事的公司，为他们和社区感到高兴。 在中国的 PG 生态中，瀚高算是极个别 …

原作者：digoal · 微信公众号转载页 真相永远是残酷的, 今天这一期恐怕要令很多MySQL从业者、甚至是打着平替/兼容MySQL的国产数据库厂商不爽了! 世人都喜欢听好听的、缕顺毛, 可好听的大多数是唯心的谎言. 不是有句话“撒但是谎言之父”么, 如果公司里老板周围挤满了“撒旦”那这家公司十有八九要玩蛋! 但我是个钢铁直男, 我就喜欢说真话. MySQL在互联网时代风光无限，可惜被Oracle收购后，内部的虹吸效应注定了它的结局，MySQL必将被Oracle玩死最终走向平庸与没落。 参考 …

今天早上业界爆出一个收购案，继 Databricks 以十亿美元收购 Neon 之后，它的老对手 Snowflake 紧接着收购了 CrunchyData。 据知情人士透露，这笔交易的价格为 2.5亿美元。虽然价格是 Neon 的 1/4 ，但不同于 DataBricks 股票置换，这次 SnowFlake 是真金白银出了钱的，颇有 “Databricks 买啥我买啥” 针锋相对的意味。 但这并非两家数仓巨头的意气之争，而是 PostgreSQL 确实占尽了 AI 时代数据库崛起的天时 —— 加 …

作者：Paul Copplestone，Supabase CEO 译者：Vonng，Pigsty Founder，数据库老司机 原文地址: https://supabase.com/blog/open-data-standards-postgres-otel-iceberg 数据世界正在浮出水面的三大新标准：Postgres、Open Telemetry，以及 Iceberg。 Postgres 基本已经是事实标准；OTel 和 Iceberg 尚在成长， 但它们具备当年让 Postgres …

原作者：熊灿灿 · 微信公众号转载页 前言 今天看到冯董发了一篇 OpenAI：将PostgreSQL伸缩至新阶段，其中提到了 OpenAI 大量使用了 PostgreSQL，并且是一个 40+ 从库的巨无霸架构！ 在聊天提问的时候，老冯了解到 OpenAI 使用的是 Azure 上的托管 PostgreSQL，使用最高可用规格的服务器硬件，从库数量达到 40+，包括一些异地副本，这套巨无霸集群总的读写 QPS 为 100 万左右。 看到这段话的时候，颇有感触，一下子又让我回想起了前阵子在群里 …

在 PGConf.Dev 2025 全球 PG 开发者大会上， 来自 OpenAI 的 Bohan Zhang 分享了 OpenAI 在 PostgreSQL 上的最佳实践， 让我们得以一窥最牛独角兽内部的数据库使用情况。 “在 OpenAI，我们在使用一写多读的未分片架构，证明了 PostgreSQL 在海量读负载下也可以伸缩自如” —— PGConf.Dev 2025 Bohan Zhang from OpenAI Bohan Zhang 是 OpenAI Infra 组成员，师从 CMU …

PGConf.Dev 2025 全球开发者大会主会场两天的议程刚刚已经结束了。老冯今天的运气真不错，竟然抽中了一个 “闪电演讲” 的名额。所谓 “闪电演讲” 是 PGConf.Dev 的经典环节 —— 将抽取 12 位提交议题者上台进行 5 分钟的主题演讲，超时就会直接轰下来，所以大家都保持着精简干练的风格。 闪电演讲的含金量非常高，因为整个大会只有开场的院士专场演讲和收尾的闪电演讲，能把整个会场所有的人给摇到一块儿聚在一起听讲。其他的时候人都是分布在几个子会场和大厅社交区域唠嗑。全球 …

老冯今天在蒙特利尔见到几位朋友，分享八卦与行业传言是各种大会最有趣的部分。有一些不算敏感机密的信息，老冯可以与各位读者朋友分享一下。 OpenAI 收购 Supabase ？ 正如过去文章中介绍的，老冯一直以来都很看好 Neon 和 Supabase，最近 Databricks 拟以十亿美金估值收购 Neon 的消息已经众所周知了。目前 Supabase 刚刚融资 200M $ 估值 2B $ ，估值正好是 Neon 的一倍，既然 Neon 都被收了，干的比 Neon 还出彩的 Supabase …

最近 PostgreSQL 生态的公司备受市场青睐，刚刚 Databricks 拟以 10亿美金估值收购 Neon，与此同时，Supabase 则在短短半年时间融到了 D 轮整整 2 亿美金。 与此同时，微软 CEO 纳德拉在昨天的财报会议上多次提到了 PostgreSQL 的惊人表现：《纳德拉财报点名Postgres，助微软夺回市值第一》，PostgreSQL 赢得了资本市场的青睐。PG生态的公司几乎拿完了数据库领域的钱 在 PostgreSQL 生态中，老冯一直特别看好 …

原作者：龚锐 · 微信公众号转载页 老冯喜欢摄影，很早就关注了影视飓风。但俺也没有想到有一天还会出现这种交集：开源 PostgreSQL RDS 软件 Pigsty 有一天会被影视飓风用在影视行业里，用于支持达芬奇这种行业软件。 在 影视飓风达芬奇千万级数据库演化及实践 一文中，影视飓风的专家们分享了他们是如何使用 Pigsty 来解决达芬奇的各种问题。比如高可用，高级权限管控，误删回滚，读写分离，以及简化维护。 本文将介绍影视飓风达芬奇项目数据库建设的过程中遇到的问题和解决方案 01 …

微信公众号 未来的软件形态是 Agent + 数据库。没有前后端中间商，Agent直接CRUD。数据库技能相当保值，而 PostgreSQL 会成为 Agent 时代的数据库。 SaaS已死？软件从数据库开始 AI行业近年大爆发，生成式模型席卷各个领域，仿佛不谈AI就落伍了。然而 软件的世界终究是从数据库开始的 。微软 CEO 纳德拉在公开访谈中表示：在 Agent 时代，SaaS is Dead ，而未来的软件形式将是 Agent + Database 。 “…I think, the …

今天在 PostgreSQL 技术峰会上有人问，什么数据库可以替代 Oracle ？当然有很多数据库都号称自己可以 “替代” Oracle，商业产品这里就不说了，但开源的目前我了解到的只有 IvorySQL。 IvorySQL 是一个开源的“Oracle兼容” PostgreSQL 内核，由瀚高出品，使用 Apache 2.0 许可证。目前 Pigsty 支持在自建本地 RDS 时使用 IvorySQL 内核替代原生的 PostgreSQL 内核，提供和原版一样的监控，备份，高可用，IaC 等能 …

在 2025 年的当下，MySQL 无论是在功能特性集，质量正确性，性能表现，还是生态与社区上都被 PostgreSQL 拉开了差距，而且这个差距还在进一步扩大中。 今天我们就来对 MySQL 与 PostgreSQL 进行一个全方位的对比，从功能，性能，质量，生态来全方位反映这几年的生态变化。 功能 让我们先从开发者最关注的东西 —— 功能特性开始说起。 新版本 昨天，MySQL 发布了 “创新版本” 9.3 但是看上去和先前的 9.x 一样，都是些修修补补，看不到什么创新的东西。 搜索尚未发 …

昨天，至少在十几个微信群里都有人 @ 我，发给我这条消息 《有图有真相，MySQL性能是PG的360倍，DS还建议抛弃PG》。大意就是推特上有个人发了个火焰图，说他有一个“秘密案例”：“PostgreSQL 比 MySQL 慢了 360 倍，难怪中国互联网公司不用 PG”，十几万的浏览。 于是我就去 X 上看了看原博这个帖子，挺长的一个 Thread。作为数据库老司机，我一看内容和发帖者就知道怎么回事了，这是一个很典型的伪装成技术讨论的恶意贬损。当然 MySQL / PG 国际社区可能没见过这种 …

一年一度的 PostgreSQL 开发者大会即将在五月于蒙特利尔举办。同上次第一届 PG Con.Dev 一样，这次也有一天的额外的专场活动 —— Postgres Extensions Day，关注 PG 扩展的开发，交付，发布等方方面面。目前议程刚刚排出来，总共安排了 14 个 Session。 当然这次，我就不当观众了，我的演讲是下午的首场 —— “The Missing Postgres Extension Repo and Package Manager”。即 “PG 生态中长久缺失的 …

OrioleDB 奥利奥数据库，这名字听着很有趣，不过 Oriole 是黄鹂的意思，所以其实中文译名应该是 “黄鹂数据库”。 叫饼干DB还是小鸟DB都不重要，重要的是这个 PG 存储引擎扩展 + 内核分支确实很有趣，而且基本上快要正式发布了。 作为 zheap 的后继，我关注 OrioleDB 已经很久了，它的主要亮点有三个：性能，运维，云原生。 那么今天简单介绍一下这个 PG 内核新秀，以及最近我做的一些工作，可以让用户直接把它跑起来。 极致性能，四倍吞吐 虽然说在当下对于 OLTP 数据库来 …

什么？PostgreSQL 现在可以使用 MYSQL 客户端访问了？没有错，愚人节刚开源的 openHalo 就提供了这样的能力 —— 让用户可以同时用 MySQL 和 PGSQL 的客户端读写访问管理同一个数据库，基于 PG 14.10 提供了 MySQL 5.7 的兼容能力。 前天 openHalo 开源了他们的 MySQL 兼容 PG 内核， 今天我打好了 RPM 包，已经整合进 Pigsty 里了，部署相当丝滑，修改了几处代码后，跟高可用，监控，备份组件都丝滑地融合在一起。 …

前几天，我收到了一条来自 Odoo 社区的需求， 对方苦恼于：“数据库能做PITR（Point-in-Time Recovery），那文件系统有没有办法一起回滚呢？” 为什么会有“PGFS”这个想法？ 从数据库老司机的角度来看，这是个颇具挑战性又让人兴奋的问题。 我们都知道，像 Odoo 这类 ERP 系统，最宝贵的确实是数据库中的核心业务数据，放在一套 PostgreSQL 里。 不过，许多“企业级应用”，多少也要接触一些文件操作，比如上传附件、存储图片和文档等等。 虽然这些文件没有数据库那样 …

蹭热点引出的好话题 昨晚在直播间，我与几位国内 DuckDB 先锋进行了一场对谈。 话题跨度很大，从 DeepSeek 团队在开源周推出的分布式 DuckDB 分析框架 “Smallpond”，聊到 PostgreSQL 与 DuckDB 的深度融合，相当热闹。 DeepSeek 的开源的 “小池塘”用把 DuckDB 改为分布式的用法，从营销上给 DuckDB 打了很好的广告。 但从实用角度和影响力来说，我个人对分布式 DuckDB 的价值保持保留态度（那个3FS实际上更有用）。 因为这与 …

看到有人发了一篇《天上的“PostgreSQL” 说 地上的 PostgreSQL 都是“小垃圾”》， 文中大肆宣扬阿里云 RDS 新增了一个 rds_duckdb 插件，可以用来做 OLAP 分析， 并进一步带出“云 RDS PG 高高在上、PostgreSQL 开源只是‘小垃圾’”的极端观点，令人不适。 我对 DuckDB 及衍生的 pg_duckdb 扩展都很熟悉。 其实无论阿里云或其他云厂商在技术层面如何整合开源，只要合法合理合情，我个人都乐见商业与开源互利共赢。 但如果有人在宣传层面贬 …

昨天在 X 上看到暴跳发了个帖。暴跳以前是 PolarDB InnoDB 引擎的负责人，现在是阿里云 RDS PG + MySQL 的头儿： 所以虽然这是个 “我朋友说” 的疑问句式，但我也并不怀疑这个数字的真实性。大概在两年～三年前，AWS 上 PostgreSQL 的实例数量刚好超过 MySQL，而按照这两年 PG 发展的迅猛势头，从 1:1 提升到 3:2 也并不算离谱。 StackOverflow 2024调研：PostgreSQL已经超神了 当然，在去年 PGCon.Dev 上我也特意 …

原文：Laurenz Albe 事务系统是关系型数据库的核心组成部分，在应用开发中，为确保 数据完整性 提供了重要支持。 SQL 标准规范了数据库事务的一些功能，但并未明确规定许多细节。因此，关系型数据库的事务系统可能存在显著差异。 近年来，许多人尝试从 Oracle 数据库迁移到 PostgreSQL。为了顺利将应用从 Oracle 迁移到 PostgreSQL，理解两者事务系统之间的差异至关重要。 否则，您可能会遇到一些令人头痛的意外情况，危及到性能和数据完整性。所以，我认为有必要编写一篇 …

老话说的好，不要在星期五发布。昨天晚上， PostgreSQL 全球开发者宣布发布了每季度一次的例行小版本更新，我没有立刻发布一个中文翻译，因为上次 11 月的小版本更新翻车场景《号外：发布当日叫停，PG也躲不过翻车》还历历在目。 不过我没想到的是，还真的又让我连着撞上第二次翻车。仅仅十二小时后，PGDG 就宣布了将在2月20号紧急发布一个号外小版本，来回滚这次的错误。 在 2.14 号例行发布的 17.3, 16.7, 15.11, 14.16, 以及 13.19 小版本中，修复了 …

读者朋友们，今天我要开始休假了。也许会停更两周，在这里提前祝大家新年快乐。 当然在开始休假之前，这篇文章和大家分享一下最近 PG 生态有趣的一些进展。昨天我也赶紧趁着还有时间，推出了 Pigsty 3.2.2 版本与 Pig v0.1.3 ：这个版本将可用的 PG 扩展从 350 一路干到 400 个，其中包含了上面大部分花活，下面简单介绍一下： Omnigres：在PG里搞前后端Web全栈开发 PG Mooncake：在PG中实现Clickhouse的分析性能 Citus：支持 PG17 的分 …

数据库是业务架构的核心，是不言自明的共识。但如果我们更进一步，将数据库作为业务架构本身，将业务逻辑，Web Server，甚至是整个前后端都放入数据库中，又会擦出怎么样的火花？未来会是一个数据库吞噬后端，前端，操作系统，甚至一切的世界吗？ 驱动未来的数据库 不久之前，Omnigres 的创始人 Yurii 在 第七届PG生态大会 上 进行了题为《数据库驱动未来》的演讲分享。抛出了一个有趣的观点 —— 数据库就是业务架构。 他的开源项目 Omnigres 做了一件“疯狂”的事：把所有应用逻辑，甚至 …

今天我们来聊一聊个人信息合规问题，以及如何在数据库中实践各国法律的 “匿名化” 要求。最后介绍新出炉的 PostgreSQL Anonymizer 2.0 以及使用方法。 1. 哎呀，谁在PII上翻车了？ 还记得前几年那个堪称“翻车现场”的事件吗？滴滴公司因为在个人信息收集和使用方面存在严重违法违规问题，被监管部门找上门来并狠狠罚了一大笔钱，瞬间引爆社交媒体的讨论。再往后没多久，亚马逊因其广告业务不符合欧盟 GDPR 要求，也被卢森堡监管机构揪住“数据黑洞”，祭出了高达 7.46 亿欧元的天价罚 …

1月4号，PostgreSQL 生态大会在上海国际饭店成功举办。参会的观众与嘉宾填满了整个会场，这其实是挺不容易的一件事，已经有相当一阵子没有看到这么热闹的大会了，组织得也的相当不错。当然，我是懒得写那种流水账说谁谁谁讲了啥啥啥的簿记文章，我就说说我参会的一些心得体会与感想吧。 如何请外国人参会 虽然这是一场 “中国 PostgreSQL” 会议，但我确实认为中国的厂商与开发者应该看看海外/全球的同行先行者们正在做什么。这也是我邀请加拿大 PG 公司 Omnigres 的创始人 Yurii 来参 …

原作者：熊灿灿 · 微信公众号转载页 前言 各位 PGer 大家好，在此很高兴地告诉各位 ——《PostgreSQL 内参：深入解析运行原理》正式发布了。从最开始萌生翻译成册的想法，再到现今电子版书籍的正式发布，期间磕绊无数，但好在结果是喜人的，三年磨一剑，《PostgreSQL 14 Internals》中文版终于如期而至，各位可以通过 🔗：https://postgres-internals.cn[1] 进行访问，原计划在元旦发布，思考良久，最终还是决定提前与各位见面。对于中文版的发布，原 …

微信公众号 最近我在忙一个非常有趣的新项目，这两天总算弄完了。各位朋友们，给大家介绍一下这个有趣的小东西，PostgreSQL 与 Pigsty 中久久缺失的一个命令行工具，我称之为 “pig”。 那么 pig 是干什么的？简单来说，这是一个 PostgreSQL 的包管理器，也是 PostgreSQL 与 Pigsty 中久久缺失的一个命令行工具，它可以在主流 Linux 操作系统上提供跨发行版的丝滑无缝的 PostgreSQL 安装部署体验。而且还通过国内镜像解决了下载速度慢和部分仓库被墙 …

由 TimescaleDB 主办的年度 PostgreSQL 社区现状调研报告最近发布了结果。 此次问卷调查收集到了 688 份样本，相比于 StackOverflow 全球开发者调研** **的近十万份样本来说实在有些少。但因其受众为 PostgreSQL 社区成员，相当一部分结论依然有一定的参考价值。以下是报告中的亮点。 概括 在一个软件生命周期短暂的世界里，作为全球领先的开源数据库之一，PostgreSQL的坚韥实在是非凡。PostgreSQL经过30多年的活跃开发，经受住了时间的考验，建 …

题目如下： 《数据库编程大赛：一条SQL计算扑克牌24点》 有一张表 cards，id 是自增字段的数字主键，另外有4个字段 c1,c2,c3,c4 ，每个字段随机从 1~10 之间选择一个整数 要求选手使用一条 SQL 给出 24 点的计算公式，返回的内容示例如右图： 其中 result 字段是计算的表达式，只需返回1个解，如果没有解，result 返回null 24 点的计算规则：只能使用加减乘除四则运算，不能使用阶乘、指数等运算符，每个数字最少使用一次，且只能使用一次，可以使用小括号改变优 …

作者：Matt Blewitt，原文：七周七数据库（2025年） 译者：Vonng，数据库老司机，云计算泥石流 https://matt.blwt.io/post/7-databases-in-7-weeks-for-2025/ 长期以来，我一直在运营数据库即服务（Databases-as-a-Service），这个领域总有新鲜事物需要跟进 —— 新技术、解决问题的不同方法，更别提大学里不断涌现的研究成果了。展望2025年，考虑花一周时间深入了解以下每项数据库技术吧。 前言 这不是 “七大最佳 …

正如《号外：发布当日叫停，PG也躲不过翻车》一文所述，PostgreSQL 在上周四发布的 17.1 打破了 ABI 当天紧急叫停了发布，并于本周四，也就是几分钟前刚刚发布了新的号外小版本序列：17.2, 16.6, 15.10, 14.15, 13.18, 以及 12.22，修复了此问题。 如果你在过去一周中通过互联网上游直接从官方仓库或镜像安装或升级过 PostgreSQL， 那么你可能有概率会遇到一些扩展兼容性的问题，我们强烈建议你立即升级到最新的 PostgreSQL 小版本以解决此问题 …

老话说的好，不要在星期五发布代码。前天刚发布的 PostgreSQL 例行小版本虽然特意避开了星期五发布，但却给社区加了一周的活 —— PostgreSQL 社区将于下周四发布一个非常规紧急小版本 PostgreSQL 17.2，16.6， 15.10，14.15，13.20，甚至是刚刚已经 EOL 的 PG 12 也会有 12.22…… 。 在过去十年里这是第一次出现这样的情况：在 PostgreSQL 发布日的当天，新版本就因为社区发现的问题而叫停。紧急发布的原因有两个，第一是修复 …

根据 PostgreSQL 的 版本策略，在 2019 年发布的 PostgreSQL12 将于今日（2024-11-14）正式脱离支持生命周期。 PG 12 最后一个小版本为 2024-11-14 发布的 12.21，而这将是 PG 12 的最终版本，而新发布的 PostgreSQL 17.1 则将成为当下合适的新业务选择。 Version Current minor Supported First Release Final Release 17 17.1 Yes September 26, …

原作者：熊灿灿 · 微信公众号转载页 前言 这两天，被一个和技术完全搭不上边的事情给整得直抠脑壳，最后发现，居然是 License 在作祟！实在忍不住，必须吐槽一番，且听笔者慢慢道来。 来龙去脉 这两天，笔者一直在折腾一个 GP 数据库。起初是客户找到我说，将数据库节点所在服务器内存缩容了之后，提示数据库连接过多。报错其实很简单： psql：error：FATAL：too many connections for database xxx. **即使是一名外行，我想光看这个报错也都知道是连接数 …

作者：Peter Zaitsev | 译：冯若航（@Vonng）| 微信公众号 Percona 的老板 Peter Zaitsev最近发表一篇博客，讨论了MySQL是否还能跟上PostgreSQL的脚步。 Percona 作为MySQL 生态扛旗者，Percona 开发了知名的PT系列工具，MySQL备份工具，监控工具与发行版。他们的看法在相当程度上代表了 MySQL 社区的想法。 作者：Peter Zaitsev，Percona 老板，原文：How Can MySQL Catch Up …

最近没怎么更新，因为在憋大招。最近功成出关，遂发此文为贺 —— 我做了一个收录PG生态所有能打的390个扩展的仓库，让 PostgreSQL 在成为数据库全能王的道路上又往前迈出了坚实的一步！ 自从我在 《PostgreSQL正在吞噬数据库世界》 一文中指出 可扩展性 对于 PostgreSQL 的重要性以来，PG 社区对此进行了热烈的讨论，并且达成了共识。 最终体现在《PostgreSQL 17 发布注记！》中。 但真正重要的事情不是认识世界，而是改变世界。既然大家都已经认清了扩展很重要，那么 …

0x00背景 没有规矩，不成方圆。 PostgreSQL的功能非常强大，但是要把PostgreSQL用好，需要后端、运维、DBA的协力配合。 本文针对PostgreSQL数据库原理与特性，整理了一份开发/运维规约，希望可以减少大家在使用PostgreSQL数据库过程中遇到的困惑：你好我也好，大家都好。 本文第一版主要针对 PostgreSQL 9.4 - PostgreSQL 10 版本 ，当前最新版本针对 PostgreSQL 15/16/17 进行更新与调整。 0x01 命名规范 计算机科 …

昨天，Supabase 官宣了八千万美金的 C 轮融资，这是继 2022 年八千万 B 轮融资后的新一轮融资，在当下资本市场与数据库行业环境中难能可贵。 老实说，我并不感到意外，在《PostgreSQL正在吞噬数据库世界》一文中，我就说过，PostgreSQL 将会成为数据库世界的 Linux，而聪明的资本已经开始涌入这个领域。 看看过去一年来数据库领域的融资纪录，不难发现几乎都是 PostgreSQL 生态的创业公司，以下是 PostgreSQL 生态或相关的公司最近的融资纪录。可以说，PG …

一年一度的 PostgreSQL 大版本发布来了！这次的 PostgreSQL 17 ，又给我们带来了什么惊喜呢？ 在这次大版本发布注记中， PostgreSQL 全球社区直接摊牌了 —— 不好意思，我不装了 —— “现在PG就是世界上最先进的开源数据库，已经是各种规模组织的首选开源数据库了”。虽然没有指名道姓，但官方已经无限接近喊出“干翻顶级商业数据库”（Oracle）的口号了。 在年初发表的 《PostgreSQL 正在吞噬数据库世界》中，我提出 可扩展性 是 PostgreSQL 独一无二 …

这两天 MongoDB 整的营销花活让人眼花缭乱：《MongoDB向PostgreSQL宣战》，《MongoDB 击败 PostgreSQL 赢下价值 300 亿美元项目》，以及原文 The Register 的《MongoDB在战胜强敌之后准备乱拳干翻 PostgreSQL》，活生生一副要乱拳打死老师傅的架势。 有朋友得意洋洋的特意转给我想看 PG 的笑话，这着实让我感到无奈 —— 这么离谱的新闻都有人信！ 但事实是 —— 这么离谱的东西真就有人信！ 包括某些CEO也照样会中招翻车。诚如石破天 …

前言 明天我会发一篇批判 MongoDB 的文章，作为对其近期恶劣营销碰瓷 PostgreSQL 的回应。在那之前，我想先分享一篇在 2015 年时的精彩文章，揭露了 MongoDB 的一些黑历史。 这篇文章最经典的一点在于，它是由 MongoDB 的合作伙伴发出的血泪控诉，MongoDB 对尝试在生态中做分析的伙伴不屑一顾，而是跑去拿了一个 PostgreSQL 作为自己的分析引擎忽悠用户，从而让合作伙伴彻底灰心丧气的故事。 本文原文链接 …

许多人对于 PostgreSQL 生态已经发展到什么阶段并没有一个直观的印象 —— 除了 吞噬数据库世界，囊括万物的扩展生态之外，PostgreSQL 还可以直接从内核层面，替换掉 Oracle，SQL Server 与 MongoDB，当然 MySQL 就更不在话下了。 当然要说主流数据库中，暴露风险最高的是谁，那毫无疑问是 微软的 SQL Server 了。MSSQL 被替代的是最彻底的 —— 直接在 WireProtocol 层面被替代了。而主导这件事的是 AWS，亚马逊云服务。 …

在 《PostgreSQL正在吞噬世界中》 一文中，我曾经抛出过这个问题：谁会最终统一数据库世界？。我认为是 PostgreSQL 生态与各种各样的扩展插件 —— 而我的判断是，要想征服 OLAP 这个最大也是最显著的数据库独立王国，这个分析扩展一定与 DuckDB 有关。 PostgreSQL 一直以来都是我最喜欢的数据库，然而我第二喜欢的数据库在这两年中从 Redis 变为了 DuckDB。DuckDB 是一个非常小巧且强大的 嵌入式 OLAP 分析数据库，在分析性能、易用性上都做到了极致水 …

PostgreSQL全球开发组发布了所有受支持PG大版本的更新，包括16.4、15.8、14.13、13.16 和 12.20 版本，以及PostgreSQL 17 的第三个 beta 测试版。此次发布修复了1个安全漏洞和过去几个月报告的 55 个 BUG。 欲了解更多变更详情，请查阅发布说明[1]。 PostgreSQL 12 终止支持通知 PostgreSQL 12将于2024年11月14日停止发布修复补丁。如果您在生产环境中运行PostgreSQL 12，我们建议您计划升级到更新的、受支持 …

ClickHouse[1] 是一家开源实时分析数据库初创公司，2021 年从 Yandex 分拆出来。周二，该公司宣布收购 PeerDB，这是一家专注于高性价比 Postgres 复制和变更数据捕获的公司。 自成立以来，甚至在作为 Yandex 支持的开源项目期间，ClickHouse 就已经凭借其大型企业实时数据仓库的优势建立了良好声誉。其客户包括德意志银行、eBay、Fastly、GitLab、HubSpot、微软、ServiceNow 和 Spotify。虽然 ClickHouse 早已提 …

2024 年 StackOverflow 全球开发者调研结果已经新鲜出炉， 来自 185 个国家与地区的 6 万名开发者给出了高质量的问卷反馈。当然，作为数据库老司机，我最关注的还是 “Database” 这一项调研结果： 流行度 首先是数据库流行度：专业开发者中的数据库使用率 一项技术使用者占总体的比例，就是 流行度。它的含义是：过去一年有多少比例的用户使用了这项技术。流行度代表过去一年的积累使用，是存量指标，也是最核心的事实指标。 在使用率上，PostgreSQL 在专业开发者中以 …

原作者：alitrack · 微信公众号转载页 也许是因为我一直在小公司工作，公司资源相对有限，我总是习惯寻找那些资源占用少但功能强大的项目。最早进入我视野的是 MonetDB[1]，可惜后来停止开发了。2020年，我发现了 DuckDB，感觉这正是我需要的。 在2020年，我同时在学习 PostgreSQL，了解到了它的强大之处，也发现了它的短板，尤其在 OLAP 方面。因此，我萌生了一个想法：如果能够借助 DuckDB 提升 PostgreSQL 的 OLAP 分析能力，那就太好了。虽然我 …

微信公众号 本月，MySQL 9.0 终于发布了（@2024-07），距离上一次大版本更新 8.0 (@2016-09) 已经过去八年了。然而这个空洞无物的所谓“创新版本”却犹如一个恶劣的玩笑，宣告着 MySQL 正在死去。 PostgreSQL 正在高歌猛进，而 MySQL 却日薄西山，作为 MySQL 生态主要扛旗者的 Percona 也不得不悲痛地承认这一现实，连发三篇《MySQL将何去何从》，《Oracle最终还是杀死了MySQL》，《Oracle还能挽救MySQL吗》，公开表达了对 …

尽管有少部分人人钻研折腾数据库是出于兴趣，但大多数开发者学一门技术的主要动机还是赚钱。那么今天我们就来看看，懂 MySQL 和 PostgreSQL 的开发者，在不同的国家都能赚多少钱？ StackOverflow 2023 年全球开发者调研的数据，可以作为我们分析的重要参考依据。这份问卷调研总共采访了 89184 名开发者，其中 69098 位专业开发者，在这些专业开发者中，共有 44354 名开发者上报了年薪（按照货币种类，数量，与即时汇率核算为万元人民币年薪） 太长不看 一言以蔽之 …

原作者：瑞典马工 · 微信公众号转载页 瑞典马工在软件行业里干了二十年，干了不少岗位，换了不少公司。在这无聊的北欧乡村，有时候就把这些年目睹之怪现状记下来聊以自娱。如果各位看官觉得有趣，也请转发评论。 第一篇要谈一谈软件行业的 废话文学家。废话文学家就像一个个劣质的大语言模型，不管你用的什么提示词，他总可以接上话，但是不会给你有用的内容。 为了研究的方便，瑞典马工把废话文学家再细分为几类，分别是：性学家，化学家，辩证哲理家。 性学家 性学家每天在办公室里无所事事，时不时的就开会谈性。每次谈资都 …

Dify 是一个生成式 AI 应用创新引擎，开源的 LLM 应用开发平台。提供从 Agent 构建到 AI workflow 编排、RAG 检索、模型管理等能力，帮助用户轻松构建和运营生成式 AI 原生应用。 当然，像这样的一个 AI 工作流编排软件，在底下也少不得用到数据库 —— Dify 便是用 PostgreSQL 存储数据的，当然还有 Redis 缓存，与一个专用的向量数据库。Docker 镜像拉起来本地玩玩可以，生产环境部署的话，数据库肯定不能这么搞，高可用，备份，监控啥都没有。 好在 …

PGCon.Dev 的前身是 PGCon —— 最知名的 PostgreSQL Hacker 年度聚会，也可以说是决定 PostgreSQL 未来的一场会。从 2007 年成立以来，一直都是在加拿大渥太华举办至今。 这次会议有些特殊，原来的主办者 Dan 交班给下一届大会组织者，举办地点也转移到了温哥华市的 SFU 港区活动中心，算是新班组开门红第一次大会，自然更为隆重。 全都来参会了，谁还在写代码？ 有多隆重呢？PG 核心组的 Peter Eisentraut 在会后做了一个统计，在这次 …

PostgreSQL 全球开发组宣布，PostgreSQL 17 的首个 Beta 版本现已开放下载。 这一版本包含了 PostgreSQL 17 正式发布时所有功能的预览，但在 Beta 测试期间，某些细节可能会有所调整。 您可以在发布说明中找到关于 PostgreSQL 17 的所有功能和变更的信息： https://www.postgresql.org/docs/17/release-17.html 秉承 PostgreSQL 开源社区的精神，我们强烈支持您在您的系统上测试 …

如今，软件开发中最大的趋势之一，是 PostgreSQL 正在成为事实上的数据库标准。已经有一些博客阐述了如何做到 万物皆用 PostgreSQL，但还没有多少文章能解释这一现象背后的原因。（更重要的是，为什么这件事很重要） —— 所以我写下了这篇文章。 本文作者为 Ajay Kulkarni，TimescaleDB CEO ，原文发表于 TimescaleDB 博客：《Why PostgreSQL Is the Bedrock for the Future of Data》。 译者 …

原作者：熊灿灿 · 微信公众号转载页 前言 昨日，终于见到了数据库圈的前辈梁大师，梁大师的名号用文字描述略显苍白，懂得都懂。茶余饭后，绕湖一圈，好不快哉。 (原谅我油光满面，属实是加班够呛) 虽然我与梁大师结识时间并不久，并且一直是"网友"，但正如文章标题，一见如故，仿佛相识多年的老友一样，交谈甚欢，也没有感受到任何隔阂。梁大师是位和蔼幽默的人，每每交流到尽兴之时，便会开怀大笑。梁大师也赠予了我他编著的知名书籍——《收获，不止 SQL 优化》，亲笔签名😎 (请容笔者小小炫个富) 聊起 SQL …

在开源世界中，我们都是站在巨人的肩膀上前行。但不幸的是在昨天，我们失去了其中最好的一位。我怀着沉重的心情分享这个消息[1]：在英国时间 2024年3月26日下午1:41分，北京时间昨晚十点。PostgreSQL 的主要贡献者 西蒙·里格斯（Simon Riggs）驾驶私人通用航空 Cirrus SR22 飞机在杜克斯福德机场坠毁，并在事故中丧生[2]。 \ 西蒙·里格斯[3] 是 PostgreSQL 内核的 47 位主要贡献者[4]之一 ，也是著名的 PostgreSQL 服务公司第二象限 …

作者：Jonathan Katz，PostgreSQL 核心组成员（1 of 7），AWS RDS 首席产品经理 译者：Vonng，PostgreSQL 专家，Free RDS PG Alternative —— Pigsty 作者 PostgreSQL会修改开源许可证吗 声明：我是PostgreSQL 核心组 的成员，但本文内容是我的个人观点，并非 PostgreSQL 官方声明 …… 除非我提供了指向官方声明的链接； 今天得知 Redis 项目将不再使用开源许可证发布，我感到非常遗憾。原因 …

在上一篇《PostgreSQL正在吞噬数据库世界》中，我们提到，尽管 PostgreSQL 是世界上最先进的开源关系型数据库，但其独一无二的特点在于其极致可扩展性，与繁荣的扩展生态！ 不幸地是，云上的 RDS 阉割掉了 PostgreSQL 的灵魂 —— 用户无法在 RDS 上自由加装扩展，而一些强力扩展也注定不会出现在 RDS 中。使用 RDS 无法发挥出 PostgreSQL 真正的实力，而这是一个对云厂商来说无法解决的缺陷。 RDS 缺失重要扩展 在 PostgreSQL 生态中有着上千 …

PostgreSQL 并不是一个简单的关系型数据库，而是一个数据管理的抽象框架，具有吞噬整个数据库世界的力量。而这也是正在发生的事情 —— “一切皆用 Postgres” 已经不再是少数精英团队的前沿探索，而是成为了一种进入主流视野的最佳实践。 OLAP 领域迎来踢馆者 在 2016 年的一次数据库沙龙里，我提出了一个观点： 现在 PostgreSQL 生态的一个主要遗憾是，缺少一个 足够好 的列式存储分析插件来做 OLAP 分析。尽管PostgreSQL 本身提供了很强大的分析功能集，应付常规 …

本文由 Stephan Schmidt @ KingOfCoders 发表于 Hacker News 并引发热议[1]：使用 Postgres 替代 Kafka、RabbitMQ、ElasticSearch、Mongo 和 Redis 是一种切实可行的方式，这样做可以极大降低系统复杂度，并将敏捷性发挥到极致。 如何简化复杂度并快速前进：用 PostgreSQL 完成所有任务 欢迎，HN（Hacker News）读者们。技术是关于取舍的艺术。全面使用 PostgreSQL 完成所有工作，也是一种策 …

微信公众号原文链接 PG生态新玩家ParadeDB YC S23 投了一个新项目 ParadeDB， 非常有意思。他们的 Slogan 是 “Postgres for Search & Analytics —— Modern Elasticsearch Alternative built on Postgres”。就是用于搜索和分析的 PostgreSQL，旨在成为 Elasticsearch 的替代。 PostgreSQL 的生态确实越来越繁荣了，在基于 PG 的扩展与衍生中，我们已经有了基 …

最近朋友新出了一本书，书名朴实无华简单直接：《快速掌握PostgreSQL版本新特性》。内容是详细介绍了 PostgreSQL 最近7个大版本的新特性。我收到了一本样书，浏览了一遍之后，感觉写的确实不错，所以推荐给大家。 这本书的组织结构很简单，就是每个大版本对应一章，从 PG10 开始，到2023年刚发布的 PG 16 结束。每一章按照性能、可靠性、运维管理、开发易用性、系统架构五个大方向对特性进行逐一介绍与梳理，一目了然。\ PostgreSQL 文档与 ReleaseNote 里面对于新特 …

本文概述了 Cloudflare 是如何利用 15 个 PostgreSQL 集群，伸缩到支持每秒 5500 万个请求。 2009年7月，美国加州，一个创业团队搞了一个名为 Cloudflare 的内容分发网络（CDN），用于加速互请求，让网络访问更稳定且更快捷。他们在发展初期面临着各种挑战，然而其增长速度却十分惊人。 互联网流量全局概览 现在他们承载着 20% 的互联网流量，每秒 5500 万个 HTTP 请求。 而他们仅仅使用 15 个 PostgreSQL 集群就做到了这一点。 …

飞总今天发了一篇《2023年，中国对PostgreSQL的贡献≈0！！！》，振聋发聩。所以我特意去扫了一遍 PostgreSQL 生态的开源项目，看一看这里中国人或者中国公司作为主导者，或主要贡献者的到底有多少。\ 内核贡献者 不幸地是，在内核贡献上也许让飞总言中了 —— 对于 PostgreSQL 这样堪称全世界最成功的开源项目之一：“没有什么中国的公司，中国人，在里面扮演了重要的角色“ —— 别说 PostgreSQL 核心组（Core Team）了，就连一个主要贡献者（Major …

本文是 PostgreSQL 核心组成员 Jonathan Katz 对 2024 年 PostgreSQL 项目的未来展望，并回顾过去几年 PostgreSQL 所取得的进展。 作者：Jonathan Kats，Amazon RDS 首席产品经理兼技术主管， PostgreSQL 全球开发组核心成员与主要贡献者。博客：https://jkatz05.com/。 译者：Vonng，磐吉云数创始人 / CEO，PostgreSQL 专家与布道师，开源 RDS PG —— Pigsty 作者。博客 …

微信公众号原文 今天，著名的数据库流行度榜单 DB-Engine 发布了 2024 年度数据库。PostgreSQL 已经是第五次获得这个荣誉头衔了。 确实印证了我的判断 —— 《PostgreSQL正在吞噬数据库世界》 当然，2023 年，2019，2018，2017 年的年度数据库也是 PostgreSQL，如果不是 2020 和 2021 年的风头被 Snowflake 夺走了，屈居第二，否则 PG 就是连续七年的全冠王了。 最有意思的是，其实今年按照 DB-Engine 的流行度榜单分 …

PostgreSQL 从我们的DB-Engines 排名监测的417个系统中脱颖而出，是过去一年里流行度增长最快的数据库系统，因此我们宣布 2023年度数据库为 —— PostgreSQL ！ 为了选出年度数据库，我们用 2024年1月的最新的流行度分数减去 2023年1月的分数。我们使用差值而非增长百分比 —— 因为用百分比会更偏向于年初流行度很低的系统。结果是一个数据库/DBMS列表，按照 2023 年流行度分数增量排序。流行度的意思是，有多少新来的人开始以某种方式参与这种数据库的讨论，衡 …

在线业务数据库中，慢查询不仅影响终端用户体验，还会浪费系统资源、拉高资源饱和度、导致死锁和事务冲突，增加数据库连接压力，导致主从复制延迟等问题。因此，查询优化 是 DBA 的核心工作内容之一。 在查询优化这条路上，有两种不同的方法： 宏观优化：整体分析工作负载，对其进行剖分下钻，自上而下地识别并改进其中表现最糟糕的部分。 微观优化：分析并改进一条特定的查询，这便需要记录慢查询日志，掌握 EXPLAIN 的玄机，领悟执行计划的奥妙。 今天我们先来说说前者，宏观优化 有三个主要目标与动机： 减少资源 …

MongoDB 曾经是一项令人惊叹的技术，让开发者能够抛开关系型数据库的“模式束缚”，快速构建应用程序。然而随着时间推移，MongoDB 放弃了它的开源本质，这使得许多开源项目和早期商业项目无法使用它。 大多数 MongoDB 用户其实并不需要 MongoDB 提供的高级功能，但他们确实需要一个易于使用的 开源 文档数据库解决方案。PostgreSQL 的 JSON 功能支持已经足够完善了：二进制存储 JSONB，GIN 任意字段索引 ，各种 JSON 处理函数，JSON PATH 和 JSON …

备份是DBA的生命线 —— 但如果你的 PostgreSQL 数据库已经爆炸了又没有备份，那么该怎么办呢？也许 pg_filedump 可以帮到你！ 最近遇到了一个比较离谱的活儿，情况是这样的：有个用户的 PostgreSQL 数据库损坏了，是 Gitlab 自己拉起的 PostgreSQL。没有从库，没有备份，也没有 dump。跑在拿 SSD 当透明缓存的BCACHE上，断电后起不来了。 但这还没完，接连经受了几轮摧残之后，它彻底歇菜了：首先是因为忘了挂BCACHE盘，导致 Gitlab重新 …

Pigsty v2.4.1已于9月24日正式发布。核心关注点是：如何聚拢** PostgreSQL 生态里游离的超能力，发挥出 1 + 1 远大于2 的协同增幅效果。** 我们引入了 12 个由自己编译打包、整合维护的全新扩展，并加入了三个强力组件的原生支持： Suapbase，PostgresML 与 FerretDB 。让 Pigsty 收录的扩展数量已经达到了破纪录的 150 个，全部开箱即用！ 在这些新增/现有扩展的加持下，PostgreSQL —— 这个世界上最先进的开源关系型数据库， …

昨天在群里遇到一个有趣的关于 PostgreSQL 的问题： ”写脏数据页和写入WAL缓冲区的先后顺序是什么？“ 我们都知道， WAL 就是 Write Ahead Log / 预写式日志 的缩写，那从逻辑上说，好像是先写 WAL 再写数据页才对。 但其实这个问题有趣在，写入其实是发生在两个地方的：内存与磁盘。而这对这两者的写入顺序是不一样的：在内存中，先写脏数据页，再写 WAL记录。在刷盘时，先刷 WAL 记录，再刷脏数据页。 我们可以用一个简单的例子来说明，当你执行一条 INSERT 时到底 …

8月9号晚，开源中国举办了一场 《MySQL 和 PostgreSQL，谁是世界第一？》的主题辩论活动。我作为 PostgreSQL 方的代表参与。本来我准备了一些数据与资料，想着来一场建设性的交流，擦出点思想火花。却不想这场直播在姜某人的胡搅蛮缠下，变成了一场闹剧与笑话，我感到遗憾 —— 对不起观众们的时间。 回放地址：https://www.modb.pro/video/8261?slink 这场辩论的缘由要追溯到上个月我写的这篇文章：《PostgreSQL：世界上最成功的数据库》。姜某人立 …

这篇《MySQL：这个星球最成功的数据库》是对我《PostgreSQL：世界上最成功的数据库》一文的回应。可惜文中充斥着大量事实性错误，谎言与诡辩，扣大帽子和人身攻讦。既然有人不要体面，那今天我就用数据与事实来帮他体面。扫码预约今晚的直播，观看几分钟后开始的 MySQL 与 PostgreSQL 对决开源中国直播。 问卷能否代表全球？ 2023 年 StackOverflow 调研结果已经新鲜出炉， 来自185个国家与地区的9万名开发者给出了高质量的反馈。在今年的调研中，PostgreSQL 在 …

原作者：姜承尧 · 微信公众号转载页 最近有篇公众号文章大火，说 PostgreSQL 是世界上最成功的数据库。姜老师双手插兜，仰望海底星空，心想这篇文章的标题取得真好，妥妥的1W+的阅读量。为什么自己做不到如此厚颜无耻呢？\ 其实，姜老师没这么玻璃心，也没怎么把这篇文章放心上。 一个卖 PostgreSQL 数据库服务的人，自卖自夸，好为后续自己的生意做铺垫。这就是那篇文章的底层逻辑。问题不少 IMG 同学让姜老师出来发言，更有素未谋面的专业数据库内核从业同学在 Twitter 上留言希望姜 …

“向量是新的JSON”，这本身就是一种很有趣的说法。因为 向量（Vector）是一种已经被深入研究过的 数学结构，而 JSON 是一种 数据交换格式。然而，在数据存储和检索的世界中，这两种数据表示方式都已经成为了各自领域的通用语言，成为（或即将成为）现代应用开发中必不可少的要素。如果按当下的趋势发展，向量将会像 JSON 一样，成为构建应用时的关键要素。 生成型AI 引发的热潮促使开发者寻找一种简便的方法来存储与查询这些系统的 输出。出于很多因素，PostgreSQL 成为了最自然的选择。但即使 …

2023 年 StackOverflow 调研结果已经新鲜出炉，来自185个国家与地区的9万名开发者给出了高质量的反馈。 在今年的调研中，PostgreSQL 在数据库全部三项调研指标（流行度，喜爱度，需求度）上获得无可争议的全能冠军，成为真正意义上“最成功”的数据库 —— “PostgreSQL is the Linux of Database!” https://demo.pigsty.cc/d/sf-db-survey 当我们说一个数据库“成功”时，究竟在说什么？评价一个数据库有许多标准： …

新 AI 应用在过去一年中出现了指数爆炸的增长态势，而这些应用面临的一个共同挑战是如何大规模地 存储 与 查询 以向量表示的 AI Embedding。本文聚焦被 AI 炒火了的 向量数据库，介绍了AI嵌入与向量存储检索的基本原理，并用一个具体的知识库检索案例来串联介绍向量数据库插件 PGVECTOR 的功能、性能、获取与应用。 AI是怎么工作的 GPT 展现出来了强大的智能水平，它的成功有很多因素，但在工程上关键的一步是：神经网络与大语言模型将一个语言问题转化为数学问题，并使用工程手段高效解决 …

上回，我们通过分析 StackOverflow 的用户调研数据，说明了《为什么PostgreSQL是最成功的数据库》。 而这一次我们将用性能数据来说话，聊聊最成功的 PostgreSQL 到底有多强，帮助大家做到“心中有数”。 太长不看 如果您对以下这些问题有兴趣，那么本文会对您有所帮助： PostgreSQL 到底性能有多强？ 点查 QPS 60万+，最高达 200 万。读写 TPS （4写1读）每秒 7 万+，最高达14万。 PostgreSQL 与 MySQL 的极限性能对比 极限条件下 …

当我们说一个数据库"成功"时，到底在说什么？是指功能性能易用性，还是成本生态复杂度？评价指标有很多，但这件事最终还得由用户来定夺。 数据库的用户是开发者，而开发者的意愿、喜好、选择又如何？StackOverflow 连续六年，向来自180个国家的七万多开发者问了这三个问题。 总览这六年的调研结果，不难看出在2022年，PostgreSQL 已经同时在这三项上登顶夺冠，成了字面意义上 “最成功的数据库”： PostgreSQL 成为 专业开发者 最常使用 的数据库！（Used） …

什么，PostgreSQL已经成为最流行，最先进，开发者最想学习使用的数据库了？ 最近，StackOverflow公布了在5月份进行的一次开发者调研报告。其中PostgreSQL获得了三连冠： PostgreSQL成为专业开发者中最流行的数据库！超越MySQL攀升至第一！ PostgreSQL成为开发者最喜爱，且最想学习的数据库，超越Redis攀升至第一！ PostgreSQL成为现有其他数据库用户最感兴趣的数据库！ StackOverflow是享誉全球的开发者社区，其用户调研覆盖7万名开发者 …

在介绍Pigsty前，我们必须要先说一说PostgreSQL！ PG是世界上最先进的开源关系型数据库 ** PG是一个足够完美的内核，一颗强劲的引擎。 但用户要的 并不是发动机，而是 开门即走 的整车！ Pigsty要做的就是这辆车： 开箱即用，物美价廉，自动驾驶，数据库界的 TESLA ！ Pigsty, 让天下没有难用的数据库！ ** ** PostgreSQL数据库发行版 RedHat for Linux! 开箱即用！从无到有，让用户用得上！ Pigsty将高可用集群部署，扩容缩容，主从复 …

上周，我们进行了一次题为PostgreSQL与Pigsty用户需求调研的问卷调查。主要希望对用户的数据库需求进行了解，两天时间共收集有77份有效问卷。 本次问卷调查基于 PostgreSQL 社区 与 Pigsty 社区用户群体，通过微信公众号与群组进行发放。部分结果可能存在Bias，但足以真实反映用户满意度与整体用户需求。 基本情况 此次接受调研的用户群体中，DBA占近半数，DBA与运维共计占71%，应用研发次之，占17%。 其中，近半数参与调研者与数据库打交道的时间在5-10年范围内，90% …

什么是Pigsty Pigsty是开箱即用的生产级开源PostgreSQL发行版。 所谓 发行版（Distribution），指的是由数据库内核及其一组软件包组成的数据库整体解决方案。例如，Linux是一个 操作系统内核，而RedHat，Debian，SUSE则是基于此内核的 操作系统发行版。PostgreSQL是一个 数据库内核，而 Pigsty，BigSQL，Percona，各种云RDS，换皮数据库则是基于此内核的 数据库发行版。 Pigsty区别于其他数据库发行版的五个核心特性为： 全面专 …

PostgreSQL中文社区又开始在线直播啦！本周日（5月23日晚7:30），由我带给大家来一段单口相声 —— 《开源PG全家桶上手指南》。 Pigsty是 开源 的PostgreSQL一条龙解决方案，主要有以下三个目标： 做最顶尖最专业的 开源PostgreSQL 监控系统 做门槛最低最好用的 开源PostgreSQL 管控方案 做开箱即用的数据分析可视化集成环境 \ \ 详情参考：https://pigsty.cc 谁会感兴趣？ PostgreSQL DBA，运维，DevOps：Pigsty …

最近做的事儿都围绕着PostgreSQL生态，因为我一直觉得这是一个前途无量的方向。 为什么这么说？因为数据库是信息系统的核心组件，关系型数据库是数据库中的绝对主力，而PostgreSQL是世界上最先进的开源关系型数据库。占据天时地利，何愁大业不成？ 做一件事最重要的就是认清形势，时来天地皆同力，运去英雄不自由。 天下大势 今天下三分，然Oracle ｜ MySQL ｜ SQL Server 疲敝，日薄西山。PostgreSQL紧随其后，如日中天。前四的数据库中，前三者都在走下坡路，唯有PG增长 …

把数据库拉起来是一回事，部署专业水准的数据库集群又是另一回事。想要真正用好管好数据库，需要良好的架构设计让多种组件协同配合起来。今天我们就来介绍一下典型的高可用PgSQL集群架构及其 落地方式。 本文将以 Pigsty v0.8 为例，介绍高可用集群的设计与部署。 “ Pigsty针对大规模数据库集群监控与管理而设计，提供业界顶尖的PostgreSQL监控系统与开箱即用的高可用数据库供给方案，为用户带来极致的可观测性与丝滑的数据库使用体验。 Pigsty基于开源生态构建，旨在降低 …

日常开发中，经常见到有模糊查询的需求。今天就简单聊一聊如何用PostgreSQL实现一些高级一点的模糊查询。 当然这里说的模糊查询，不是 LIKE 表达式前模糊后模糊两侧模糊，这种老掉牙的东西。让我们直接用一个具体的例子开始吧。 问题 现在，假设我们做了个应用商店，想给用户提供 搜索功能。用户随便输入点什么，找出所有与输入内容匹配的应用，排个序返回给用户。 严格来说，这种需求其实是需要一个搜索引擎，最好还是用专用软件，例如ElasticSearch来搞。但实际上只要不是特别复杂的逻辑，也可以很好 …

为什么Pigsty在初始化Postgres数据库时默认指定了 locale=C 与 encoding=UTF8 答案其实很简单，除非真的明确知道自己会用到LOCALE相关功能，否则就根本不应该配置 C.UTF8 之外的任何字符编码与本地化排序规则选项。 关于字符编码的部分，之前写过一篇文章专门介绍，这里表过不提。今天专门说一下 LOCALE（本地化）的配置问题。 如果说服务端字符编码配置因为某些原因配置为 UTF8 之外的值也许还情有可原，那么 LOCALE 配置为 C 之外的任何选就是 无可救 …

逻辑复制 逻辑复制（Logical Replication），是一种根据数据对象的 复制标识（Replica Identity）（通常是主键）复制数据对象及其变化的方法。 逻辑复制 这个术语与 物理复制 相对应，物理复制使用精确的块地址与逐字节复制，而逻辑复制则允许对复制过程进行精细的控制。 逻辑复制基于 发布（Publication） 与 订阅（Subscription）模型： 一个 发布者（Publisher） 上可以有多个 发布，一个 订阅者（Subscriber） 上可以有多个 订阅 …

引子：土法逻辑复制 复制身份的概念，服务于 逻辑复制。 逻辑复制的基本工作原理是，将逻辑发布相关表上 对行的增删改 事件解码，复制到逻辑订阅者上执行。 逻辑复制的工作方式有点类似于行级触发器，在事务执行后对变更的元组逐行触发。 假设您需要自己通过触发器实现逻辑复制，将一章表A上的变更复制到另一张表B中。通常情况下，这个触发器的函数逻辑通常会长这样： -- 通知触发器 CREATE OR REPLACE FUNCTION replicate_change() RETURNS TRIGGER AS …

You can’t optimize what you can’t measure 慢查询是在线业务数据库的大敌，如何诊断定位慢查询是DBA的必修课题。 本文介绍了使用监控系统 —— Pigsty诊断慢查询的一般方法论。 慢查询：危害 对于实际服务于在线业务事务处理的PostgreSQL数据库而言，慢查询的危害包括： 慢查询挤占数据库连接，导致普通查询无连接可用，堆积并导致数据库雪崩。 慢查询长时间锁住了主库已经清理掉的旧版本元组，导致流复制重放进程锁死，导致主从复制延迟。 查询越慢，查询间相 …

摘要：机器因为故障重启，NTP服务在PG启动后修复了PG的时间，导致 Patroni 无法启动。 Patroni中的故障信息如下所示： Process %s is not postmaster, too much difference between PID file start time %s and process start time %s patroni 进程启动时间和pid时间不一致。就会认为：postgres is not running。 两个时间相差超过30秒。patroni 就 …

如何在线修改主键列类型，比如将 INT 至 BIGINT，同时又不影响业务？ 假设在PG中有一个表，在设计的时候拍脑袋使用了 INT 整型主键，现在业务蓬勃发展发现序列号不够用了，想升级到BIGINT类型。这时候该怎么做呢？ 拍脑袋的方法当然是直接使用DDL修改类型： ALTER TABLE pgbench_accounts ALTER COLUMN aid SET DATA TYPE BIGINT; 但这种方式对于访问频繁的生产大表是不可行的 太长；不看 让我们以 pgbench 自带的场景为 …

前言 玩数据库和玩车有一个共通之处，就是都需要经常看仪表盘。 盯着仪表盘干什么，看指标。为什么看指标，掌握当前运行状态才能有效施加控制。 车有很多指标：车速，胎压，扭矩，刹车片磨损，各种温度，等等等等，各式各样。 但人的注意力空间有限，仪表盘也就那么大， 所以，指标可以分两类： 你会去看的：黄金指标 / 关键指标 / 核心指标 你不会看的：黑匣子指标 / 冷指标。 黄金指标就是那几个关键性的核心数据，需要时刻保持关注（或者让自动驾驶系统/报警系统替你时刻保持关注），而冷指标通常只有故障排查时才 …

名之则可言也，言之则可行也。 概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。因此需要审慎地设计。 TL;DR 集群（Cluster） 是基本自治单元，由用户指定唯一标识，表达业务含义，作为顶层命名空间。 集群在硬件层面上包含一系列的 节点（Node），即物理机，虚机（或Pod），可以通过IP唯一标识。 集群在软件层面上包含一系列的 实例（Instance），即软件服务器，可以通过IP:Port唯一标识。 …

近自己做了套数据库监控系统，搞的还可以，简单给大家介绍一下。 Pigsty is an advanced PostgreSQL monitoring systemd based on open source projects like prometheus & grafana. PIGSTY /pɪɡ staɪ/ is the abbreviation of “Postgres in Grafana Style”. Pigsty是一个基于Grafana与Prometheus与Consul的 …

管数据库和管人差不多，都需要定KPI（关键性能指标）。那么数据库的KPI是什么？本文介绍了一种衡量PostgreSQL负载的方式：使用一种单一横向可比，与负载类型和机器类型基本无关的指标，名曰 PG Load（PG负载）。 0x01 Introduction 在现实生产中，经常会有衡量数据库性能与负载，评估数据库水位的需求。一种最朴素的形式就是，能不能有一个类似于KPI的单一指标，能直接了当地告诉用户他心爱的数据库负载有没有超过警戒线？工作量到底饱和不饱和？ 当然这里其实隐含着一个重要信息，即用 …

场景 在数据库的生命周期中，有一类需求是很常见的，修改字段类型。例如： 使用 INT 作为主键，结果发现业务红红火火，INT32的21亿序号不够用了，想要升级为 BIGINT 使用 BIGINT 存身份证号，结果发现里面有个 X 需要改为 TEXT 类型。 使用 FLOAT 存放货币，发现精度丢失，想要修改为Decimal 使用 TEXT 存储JSON字段，想用到PostgreSQL的JSON特性，修改为JSONB类型。 那么，如何应对这种需求呢？ 常规操作 通常来说，ALTER TABLE 可 …

PostgreSQL实际上只有两种事务隔离等级：读已提交（Read Commited） 与 可序列化（Serializable） 基础 SQL标准定义了四种隔离级别，但PostgreSQL实际上只有两种事务隔离等级：读已提交（Read Commited） 与 可序列化（Serializable） SQL标准定义了四种隔离级别，但实际上这也是很粗鄙的一种划分。详情请参考并发异常那些事。 查看/设置事务隔离等级 通过执行：SELECT …

了解PostgreSQL服务器与客户端通信使用的TCP协议 启动阶段 启动阶段的基本流程如下所示： 客户端发送一条 StartupMessage (F) 向服务端发起连接请求 载荷包括 0x30000 的Int32版本号魔数，以及一系列kv结构的运行时参数（NULL0分割，必须参数为 user）， 客户端等待服务端响应，主要是等待服务端发送的 ReadyForQuery (Z) 事件，该事件代表服务端已经准备好接收请求。 上面是连接建立过程中最主要的两个事件，其他事件包括包括认证消息 …

今天遇到一个比较有趣的Case，客户报告说数据库连不上了。报这个错： psql: FATAL: could not load library "/export/servers/pgsql/lib/pg_hint_plan.so": /export/servers/pgsql/lib/pg_hint_plan.so: undefined symbol: RINFO_IS_PUSHED_DOWN 当然，这种错误一眼就知道是插件没编译好，报符号找不到。因此数据库后端进程在启动时尝试加载 …

在实际生产中，我们经常需要把数据库的状态同步到其他地方去，例如同步到数据仓库进行分析，同步到消息队列供下游消费，同步到缓存以加速查询。总的来说，搬运状态有两大类方法：ETL与CDC。 前驱知识 CDC与ETL 数据库在本质上是一个 状态集合，任何对数据库的 变更（增删改）本质上都是对状态的修改。 在实际生产中，我们经常需要把数据库的状态同步到其他地方去，例如同步到数据仓库进行分析，同步到消息队列供下游消费，同步到缓存以加速查询。总的来说，搬运状态有两大类方法：ETL与CDC。 …

PostgreSQL的并发控制以 快照隔离（SI） 为主，以 两阶段锁定（2PL） 机制为辅。PostgreSQL对DML（SELECT, UPDATE, INSERT, DELETE 等命令）使用SSI，对DDL（CREATE TABLE 等命令）使用2PL。 PostgreSQL有好几类锁，其中最主要的是 表级锁 与 行级锁，此外还有页级锁，咨询锁等，表级锁 通常是各种命令执行时自动获取的，或者通过事务中的 LOCK 语句显式获取；而行级锁则是由 SELECT FOR …

GIN索引如果使用很长的关键词列表进行搜索，会导致性能显著下降。本文解释了为什么GIN索引关键词搜索的时间复杂度为O(n^2) Here is the detail of why that query have O(N^2) inside GIN implementation. Details Inspect the index example_keys_idx postgres=# select oid,* from pg_class where relname = …

复制是系统架构中的核心问题之一。 集群拓扑 假设我们使用4单元的标准配置：主库，同步从库，延迟备库，远程备库，分别用字母M,S,O,R标识。 M：Master, Main, Primary, Leader, 主库，权威数据源。 S: Slave, Secondary, Standby, Sync Replica，同步副本，需要直接挂载至主库 R: Remote Replica, Report instance，远程副本，可以挂载到主库或同步从库上 O: Offline，离线延迟备库，可以挂载到主 …

备份是DBA的安身立命之本，也是数据库管理中最为关键的工作之一。有各种各样的备份，但今天这里讨论的备份都是物理备份。物理备份通常可以分为以下四种： 热备（Hot Standby）：与主库一模一样，当主库出现故障时会接管主库的工作，同时也会用于承接线上只读流量。 温备（Warm Standby）：与热备类似，但不承载线上流量。通常数据库集群需要一个延迟备库，以便出现错误（例如误删数据）时能及时恢复。在这种情况下，因为延迟备库与主库内容不一致，因此不能服务线上查询。 冷备（Code Backup）： …

PostgreSQL驾驶技巧 PostgreSQL是一个很棒的数据库，但也相当复杂。上手虽简单，但想要用好不容易，想要管理好就更麻烦了。监控系统是几乎所有运维工作的基础，更亦是驾驭数据库的必备工具。用好一个监控系统，理解各种指标背后的意义并不是一件简单的事情，因此本司机决定写一系列文章，来介绍了PostgreSQL监控系统的设计，实施与使用。 0x01 PostgreSQL监控面板 为了帮助读者形成一种直觉，这里展示了在实际环境中，我所使用的监控面板。最为常用的监控面板为“单数据库实例”监控，并 …

PostgreSQL很棒，但这并不意味着它是Bug-Free的。这一次在线上环境中，我又遇到了一个很有趣的Case：由 pg_dump 导致的线上故障。这是一个非常微妙的Bug，由Pgbouncer，search_path，以及特殊的 pg_dump 操作所触发。 背景知识 连接污染 在PostgreSQL中，每条数据库连接对应一个后端进程，会持有一些临时资源（状态），在连接结束时会被销毁，包括： 本会话中修改过的参数。RESET ALL; 准备好的语句。 DEALLOCATE ALL 打开的游 …

PostgreSQL是一个很可靠的数据库，但是再可靠的数据库，如果碰上了不可靠的硬件，恐怕也得抓瞎。本文介绍了在PostgreSQL中，应对数据页面损坏的方法。 最初的问题 线上有一套统计库跑离线任务，业务方反馈跑SQL的时候碰上一个错误： ERROR: invalid page in block 18858877 of relation base/16400/275852 看到这样的错误信息，第一直觉就是硬件错误导致的关系数据文件损坏，第一步要检查定位具体问题。 这里，16400是数据库的 …

PostgreSQL使用了MVCC作为主要并发控制技术，它有很多好处，但也会带来一些其他的影响，例如关系膨胀。关系（表与索引）膨胀会对数据库性能产生负面影响，并浪费磁盘空间。为了使PostgreSQL始终保持在最佳性能，有必要及时对膨胀的关系进行垃圾回收，并定期重建过度膨胀的关系。 在实际操作中，垃圾回收并没有那么简单，这里有一系列的问题： 关系膨胀的原因？ 关系膨胀的度量？ 关系膨胀的监控？ 关系膨胀的处理？ 本文将详细说明这些问题。 关系膨胀概述 假设某个关系实际占用存储100G，但其中有很 …

官方网站：https://www.timescale.com 官方文档：https://docs.timescale.com/v0.9/main Github：https://github.com/timescale/timescaledb 为什么使用TimescaleDB 什么是时间序列数据？ 我们一直在谈论什么是“时间序列数据”，以及与其他数据有何不同以及为什么？ 许多应用程序或数据库实际上采用的是过于狭窄的视图，并将时间序列数据与特定形式的服务器度量值等同起来： Name: CPU …

PipelineDB安装与配置 PipelineDB可以直接通过官方rpm包安装。 加载PipelineDB需要添加动态链接库，在 postgresql.conf 中修改配置项并重启： shared_preload_libraries = 'pipelinedb' max_worker_processes = 128 注意如果不修改 max_worker_processes 会报错。其他配置都参照标准的PostgreSQL PipelineDB使用样例 —— 维基PV数据 -- 创建Stream …

0x01 概览 故障表现： 某张使用自增列的表序列号涨至整型上限，无法写入。 发现表中的自增列存在大量空洞，很多序列号没有对应记录就被消耗掉了。 故障影响：非核心业务某表，10分钟左右无法写入。 故障原因： 内因：使用了INTEGER而不是BIGINT作为主键类型。 外因：业务方不了解 SEQUENCE 的特性，执行大量违背约束的无效插入，浪费了大量序列号。 修复方案： 紧急操作：降级线上插入函数为直接返回，避免错误扩大。 应急方案：创建临时表，生成5000万个浪费空洞中的临时ID，修改插入函 …

遇到一次磁盘坏块导致的事务回卷故障： 主库（PostgreSQL 9.3）磁盘坏块导致几张表上的VACUUM FREEZE执行失败。 无法回收老旧事务ID，导致整库事务ID濒临用尽，数据库进入自我保护状态不可用。 磁盘坏块导致手工VACUUM抢救不可行。 提升从库后，需要紧急VACUUM FREEZE才能继续服务，进一步延长了故障时间。 主库进入保护状态后提交日志（clog）没有及时复制到从库，从库产生存疑事务拒绝服务。 摘要 这是一个即将下线老旧库，疏于管理。坏块征兆在一周前就已经出现，没有及 …

概览 触发器行为概述 触发器的分类 触发器的功能 触发器的种类 触发器的触发 触发器的创建 触发器的修改 触发器的查询 触发器的性能 触发器概述 触发器行为概述：英文，中文 触发器分类 触发时机：BEFORE, AFTER, INSTEAD 触发事件：INSERT, UPDATE, DELETE,TRUNCATE 触发范围：语句级，行级 内部创建：用于约束的触发器，用户定义的触发器 触发模式：origin|local(O), replica(R),disable(D) 触发器操作 触发器的操作通 …

IP归属地查询的高效实现 在应用开发中，一个‘很常见’的需求就是GeoIP转换。将请求的来源IP转换为相应的地理坐标，或者行政区划（国家-省-市-县-乡-镇）。这种功能有很多用途，譬如分析网站流量的地理来源，或者干一些坏事。使用PostgreSQL可以多快好省，优雅高效地实现这一需求。 0x01 思路方法 通常网上的IP地理数据库的形式都是：start_ip, stop_ip , longitude, latitude，再缀上一些国家代码，城市代码，邮编之类的属性字段。大概长这样： …

微信公众号原文 0x00背景 没有规矩，不成方圆。 PostgreSQL的功能非常强大，但是要把PostgreSQL用好，需要后端、运维、DBA的协力配合。 本文针对PostgreSQL数据库原理与特性，整理了一份开发规范，希望可以减少大家在使用PostgreSQL数据库过程中遇到的困惑。你好我也好，大家都好。 0x01 命名规范 无名，万物之始，有名，万物之母。 【强制】 通用命名规则 本规则适用于所有对象名，包括：库名、表名、表名、列名、函数名、视图名、序列号名、别名等。 对象名务必只使用 …

PostgreSQL的Slogan是“世界上最先进的开源关系型数据库”，但我觉得这口号不够响亮，而且一看就是在怼MySQL那个“世界上最流行的开源关系型数据库”的口号，有碰瓷之嫌。要我说最能生动体现PG特色的口号应该是：一专多长的全栈数据库，一招鲜吃遍天嘛。 全栈数据库 成熟的应用可能会用到许许多多的数据组件（功能）：缓存，OLTP，OLAP/批处理/数据仓库，流处理/消息队列，搜索索引，NoSQL/文档数据库，地理数据库，空间数据库，时序数据库，图数据库。传统的架构选型呢，可能会组合使用多种组 …

微信公众号原文 在应用开发中，很多时候我们需要解决这样一个问题：根据用户的经纬度坐标，定位用户的行政区划。 我们收集到的是诸如 28°00'00"N 100°00'00.000"E 这样的经纬度坐标，但实际感兴趣的是这个点所属的行政区划：（中华人民共和国，云南省，迪庆藏族自治州，香格里拉市）。这种将地理坐标映射到某条记录的操作就称为 地理编码（GeoEncode）。高效实现地理编码是一个很有趣的问题。 本文介绍了该问题的解决与优化方案：能在确保正确性的前提下，能用几兆的空间，110μs的执行时 …

灵活应用数据库的功能，可以轻松实现 GIS 圈选场景下三万倍的性能提升。 Level 方法 性能/耗时(ms) 可维护性/可靠性 备注 1 暴力扫表 30,000 - 形式简单 2 经纬索引 35 复杂度/魔数问题 额外复杂度 3 联合索引 10 复杂度/魔数问题 额外复杂度 4 GIST 4 最简表达，完全精确 形式简单，距离更精确，PostgreSQL限定 5 btree_gist 联合索引 1 最简表达，完全精确 形式简单，距离更精确，PostgreSQL限定 场景 互联网中的很多业务都涉 …

表的空间布局 宽泛意义上的 表（Table），包含了 本体表 与 TOAST表 两个部分： 本体表，存储关系本身的数据，即狭义的关系，relkind='r'。 TOAST表，与本体表一一对应，存储过大的字段，relinkd='t'。 而每个表，又由 主体 与 索引 两个 关系（Relation） 组成（对本体表而言，可以没有索引关系） 主体关系：存储元组。 索引关系：存储索引元组。 每个 关系 又可能会有 四种分支： main: 关系的主文件，编号为0 fsm：保存关于main分支中空闲空间的信 …

PgAdmin4的安装与配置 PgAdmin是一个为PostgreSQL定制设计的GUI。用起来很不错。可以以本地GUI程序或者Web服务的方式运行。因为Retina屏幕下面PgAdmin依赖的GUI组件显示效果有点问题，这里主要介绍如何以Web服务方式（Python Flask）配置运行PgAdmin4。 下载 PgAdmin可以从官方FTP下载。 postgresql网站FTP目录地址 wget …

最近发生了一起匪夷所思的故障，某数据库切走了一半的数据量和负载。 其他什么都没变，本来还好；压力减小，却在高峰期陷入濒死状态，完全不符合直觉。 但正如福尔摩斯所说，当你排除掉一切不可能之后，剩下的即使再离奇，也是事实。 一、摘要 某日凌晨4点，进行了核心库进行分库迁移，拆走一半的表和一半的查询负载，原库节点规模不变。 当日晚高峰核心库所有热备库（15台）出现连接堆积，压力暴涨，针对性地清理慢查询不再起效。 无差别持续杀查询，有立竿见影的救火效果（22:30后），且暂停后故障立刻重现 …

一些PostgreSQL与Bash交互的技巧。 使用严格模式编写Bash脚本 使用Bash严格模式，可以避免很多无谓的错误。在Bash脚本开始的地方放上这一行很有用： set -euo pipefail -e：当程序返回非0状态码时报错退出 -u：使用未初始化的变量时报错，而不是当成NULL -o pipefail：使用Pipe中出错命令的状态码（而不是最后一个）作为整个Pipe的状态码1。 执行SQL脚本的Bash包装脚本 通过psql运行SQL脚本时，我们期望有这么两个功能： 能向脚本中传入 …

Exclude约束是一个PostgreSQL扩展，它可以实现一些更高级，更巧妙的的数据库约束。 前言 数据完整性是极其重要的，但由应用保证的数据完整性并不总是那么靠谱：人会犯傻，程序会出错。如果能通过数据库约束来强制数据完整性那是再好不过了：后端程序员不用再担心竞态条件导致的微妙错误，数据分析师也可以对数据质量充满信心，不需要验证与清洗。 关系型数据库通常会提供 PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK 约束，然而并不是所有的业务约束都可以用这几种约束表达。 …

PgSQL中的函数默认有三种易变性等级，合理使用可以显著改善性能。 核心种差 VOLATILE : 有副作用，不可被优化。 STABLE： 执行了数据库查询。 IMMUTABLE: 纯函数，执行结果可能会在规划时被预求值并缓存。 什么时候用？ VOLATILE : 有任何写入，有任何副作用，需要看到外部命令所做的变更，或者调用了任何 VOLATILE 的函数 STABLE： 有数据库查询，但没有写入，或者函数的结果依赖于配置参数（例如时区） IMMUTABLE: 纯函数。 具体解释 每个函数都带 …

Distinct On是PostgreSQL提供的特有语法，可以高效解决一些典型查询问题，例如，快速找出分组内具有最大最小值的记录。 前言 找出分组内具有最大最小值的记录，这是一个非常常见的需求。用传统SQL当然有办法解决，但是都不够优雅，PostgreSQL的SQL扩展语法Distinct ON能一步到位解决这一类问题。 DISTINCT ON 语法 SELECT DISTINCT ON (expression [, expression ...]) select_list ... Here …

汽车需要上油，数据库也需要维护保养。 PG中的维护工作 对Pg而言，有三项比较重要的维护工作：备份、重整、清理 备份（backup）：最重要的例行工作，生命线。 制作基础备份 归档增量WAL 重整（repack） 重整表与索引能消除其中的膨胀，节约空间，确保查询性能不会劣化。 清理（vacuum） 维护表与库的年龄，避免事务ID回卷故障。 更新统计数据，生成更好的执行计划。 回收死元组。节约空间，提高性能。 备份 备份可以使用 pg_backrest 作为一条龙解决方案，但这里考虑使用脚本进行备 …

备份是DBA的安身立命之本，有备份，就不用慌。 备份有三种形式：SQL转储，文件系统备份，连续归档 1. SQL转储 SQL 转储方法的思想是： 创建一个由SQL命令组成的文件，服务器能利用其中的SQL命令重建与转储时状态一样的数据库。 1.1 转储 工具 pg_dump、pg_dumpall 用于进行SQL转储。结果输出到stdout。 pg_dump dbname > filename pg_dump dbname -f filename pg_dump 是一个普通的PostgreSQL客户 …

Pgbouncer是一个轻量级的数据库连接池。 概要 pgbouncer [-d][-R][-v][-u user] <pgbouncer.ini> pgbouncer -V|-h 描述 pgbouncer 是一个PostgreSQL连接池。 任何目标应用程序都可以连接到 pgbouncer， 就像它是PostgreSQL服务器一样，pgbouncer 将创建到实际服务器的连接， 或者它将重用其中一个现有的连接。 pgbouncer 的目的是为了降低打开PostgreSQL新连接时的性能影响。 …

pgBackRest主页：http://pgbackrest.org pgBackRest Github主页：https://github.com/pgbackrest/pgbackrest 前言 pgBackRest旨在提供一个简单可靠，容易纵向扩展的PostgreSQL备份恢复系统。 pgBackRest并不依赖像tar和rsync这样的传统备份工具，而在内部实现所有备份功能，并使用自定义协议来与远程系统进行通信。 消除对tar和rsync的依赖可以更好地解决特定于数据库的备份问题。 自定义 …

sysbench首页：https://github.com/akopytov/sysbench 安装 二进制安装，在Mac上，使用brew安装sysbench。 brew install sysbench --with-postgresql 源代码编译（CentOS）： yum -y install make automake libtool pkgconfig libaio-devel # For MySQL support, replace with mysql-devel on …

Fio是一个很好用的磁盘性能测试工具，可以通过以下命令测试磁盘的读写性能。 fio --filename=/tmp/fio.data \ -direct=1 \ -iodepth=32 \ -rw=randrw \ --rwmixread=80 \ -bs=4k \ -size=1G \ -numjobs=16 \ -runtime=60 \ -group_reporting \ -name=randrw \ --output=/tmp/fio_randomrw.txt \ && unlink …

通常涉及到数据迁移，常规操作都是停服务更新。不停机迁移数据是相对比较高级的操作。 不停机数据迁移在本质上，可以视作由三个操作组成： 复制：将目标表从源库 逻辑复制 到宿库。 改读：将应用 读取路径 由源库迁移到宿库上。 改写：将应用 写入路径 由源库迁移到宿库上。 但在实际执行中，这三个步骤可能会有不一样的表现形式。 逻辑复制 使用逻辑复制是比较稳妥的做法，也有几种不同的做法：应用层逻辑复制，数据库自带的逻辑复制（PostgreSQL 10 之后的逻辑订阅），使用第三方逻辑复制插件（例如 …

建议配置PostgreSQL的日志格式为CSV，方便分析，而且可以直接导入PostgreSQL数据表中。 日志相关配置项 log_destination ='csvlog' logging_collector =on log_directory ='log' log_filename ='postgresql-%a.log' log_min_duration_statement =1000 log_checkpoints =on log_lock_waits =on log_statement …

索引很有用， 但不是免费的。没用到的索引是一种浪费，使用以下SQL找出未使用的索引： 首先要排除用于实现约束的索引（删不得） 表达式索引（pg_index.indkey 中含有0号字段） 然后找出走索引扫描的次数为0的索引（也可以换个更宽松的条件，比如扫描小于1000次的） 找出没有使用的索引 视图名称：monitor.v_bloat_indexes 计算时长：1秒，适合每天检查/手工检查，不适合频繁拉取。 验证版本：9.3 ~ 10 功能：显示当前数据库索引膨胀情况。 在版本9.3与10.4上 …

配置SSH是运维工作的基础，有时候还是要老生常谈一下。 生成公私钥对 理想的情况是全部通过公私钥认证，从本地免密码直接连接所有数据库机器。最好不要使用密码认证。 首先，使用 ssh-keygen 生成公私钥对 ssh-keygen -t rsa 注意权限问题，ssh内文件的权限应当设置为 0600，.ssh 目录的权限应当设置为 0700，设置失当会导致免密登录无法使用。 配置ssh config穿透跳板机 把 User 换成自己的名字。放入 .ssh/config，这里给出了有跳板机环境下配置 …

Wireshark是一个很有用的工具，特别适合用来分析网络协议。 这里简单介绍使用Wireshark抓包分析PostgreSQL协议的方法。 假设调试本地PostgreSQL实例：127.0.0.1:5432 快速开始 下载并安装Wireshark：下载地址 选择要抓包的网卡，如果是本地测试选择 lo0 即可。 添加抓包过滤器，如果PostgreSQL使用默认设置，使用 port 5432 即可。 开始抓包 添加显示过滤器 pgsql，这样就可以滤除无关的TCP协议报文。 然后就可以执行一些操作 …

PostgreSQL是最先进的开源数据库，其中一个非常给力的特性就是FDW：外部数据包装器（Foreign Data Wrapper）。通过FDW，用户可以用统一的方式从Pg中访问各类外部数据源。file_fdw 就是其中随数据库附赠的两个fdw之一。随着pg10的更新，file_fdw 也添加了一颗赛艇的功能：从程序输出读取。 小霸王妙用无穷，我们能通过 file_fdw，轻松查看操作系统信息，拉取网络数据，把各种各样的数据源轻松喂进数据库里统一查看管理。 安装与配置 file_fdw 是Pg …

强烈建议使用使用 yum / apt 命令从 PostgreSQL 官方二进制仓库安装 PostGIS。 参考http://www.postgresonline.com/journal/archives/362-An-almost-idiots-guide-to-install-PostgreSQL-9.5,-PostGIS-2.2-and-pgRouting-2.1.0-with-Yum.html 1. 安装环境 CentOS 7 PostgreSQL10 PostGIS2.4 …

top free vmstat iostat top 显示Linux任务 摘要 按下空格或回车强制刷新 使用 h 打开帮助 使用 l,t,m 收起摘要部分。 使用 d 修改刷新周期 使用 z 开启颜色高亮 使用 u 列出指定用户的进程 使用 <> 来改变排序列 使用 P 按CPU使用率排序 使用 M 按驻留内存大小排序 使用 T 按累计时间排序 批处理模式 -b 参数可以用于批处理模式，配合 -n 参数指定批次数目。同时 -d 参数可以指定批次的间隔时间 例如获取机器当前的负载使用情况，以 …

Go使用SQL与类SQL数据库的惯例是通过标准库database/sql。这是一个对关系型数据库的通用抽象，它提供了标准的、轻量的、面向行的接口。不过 database/sql 的包文档只讲它做了什么，却对如何使用只字未提。快速指南远比堆砌事实有用，本文讲述了 database/sql 的使用方法及其注意事项。 1. 顶层抽象 在Go中访问数据库需要用到 sql.DB 接口：它可以创建语句(statement)和事务(transaction)，执行查询，获取结果。 sql.DB 并不是数据库连接 …

Parallel与Hierarchy是架构设计的两大法宝，缓存 是Hierarchy在IO领域的体现。单线程场景下缓存机制的实现可以简单到不可思议，但很难想象成熟的应用会只有一个实例。在使用缓存的同时引入并发，就不得不考虑一个问题：如何保证每个实例的缓存与底层数据副本的数据一致性（和实时性）。 PostgreSQL在版本9引入了流式复制，在版本10引入了逻辑复制，但这些都是针对PostgreSQL数据库而言的。如果希望PostgreSQL中某张表的部分数据与应用内存中的状态保持一致，我们还是需要 …

有时候，我们希望记录一些重要的元数据变更，以便事后审计之用。 PostgreSQL的触发器就可以很方便地自动解决这一需求。 -- 创建一个审计专用schema，并废除所有非superuser的权限。 DROP SCHEMA IF EXISTS audit CASCADE; CREATE SCHEMA IF NOT EXISTS audit; REVOKE CREATE ON SCHEMA audit FROM PUBLIC; -- 审计表 CREATE TABLE …

推荐系统大家都熟悉，猜你喜欢，淘宝个性化什么的，前年双十一搞了个大新闻，还拿了CEO特别贡献奖。 今天就来说说怎么用PostgreSQL 5分钟实现一个最简单ItemCF推荐系统，以推荐系统最喜闻乐见的movielens数据集为例。 原理 ItemCF的原理可以看项亮的《推荐系统实战》，不过还是稍微提一下吧，了解的直接跳过就好。 Item CF，全称Item Collaboration Filter，即基于物品的协同过滤，是目前业界应用最多的推荐算法。ItemCF不需要物品与用户的标签、属性，只 …

最近一个项目需要生成业务流水号，需求如下： ID必须是分布式生成的，不能依赖中心节点分配并保证全局唯一。 ID必须包含时间戳并尽量依时序递增。（方便阅读，提高索引效率） ID尽量散列。（分片，与HBase日志存储需要） 在造轮子之前，首先要看一下有没有现成的解决方案。 Serial 传统实践上业务流水号经常通过数据库自增序列或者发码服务来实现。 MySQL 的 Auto Increment,Postgres 的 Serial,或者 Redis+lua 写个小发码服务都是方便快捷的解决方案。这种方 …

更新：最近MongoFDW已经由Cybertech接手维护，也许没有这么不堪了。 最近有业务要求通过PostgreSQL FDW去访问MongoDB。开始我觉得这是个很轻松的任务。但接下来的事真是让人恶心的吐了。MongoDB FDW编译起来真是要人命：混乱的依赖，临时下载和Hotpatch，错误的编译参数，以及最过分的是错误的文档。总算，我在生产环境(Linux RHEL7u2)和开发环境(Mac OS X 10.11.5)都编译成功了。赶紧记录下来，省的下次蛋疼。 环境概述 理论上编译这套 …