PostgreSQL

开箱即用的 PostgreSQL 元发行版，Pigsty v3.7.0 发布，PG18成为默认版本，Debian13 与 EL10 支持到位，扩展数量达到437个，荣获“PG万磁王”奖。

PostgreSQL 开发，使用，运维，管理，诊断，调优的的经验

上下文窗口经济学，多元持久化的问题，以及零胶水架构的胜利，让 PostgreSQL 成为 AI 时代的数据库之王。

如何打造一个立足中国，面向全球的 PostgreSQL 数据库发行版

大量用官方 docker postgres 镜像的用户在最近小版本升级中翻车踩雷。老冯再次提醒，谨慎在容器中跑生产数据库。

开源免费免翻墙，一键安装PG与431个扩展插件 14个Linux发行版 x 6大PG主版本原生 RPM/DEB。

PostgreSQL官方仓库切断全球镜像站同步通道，开源制成品断供，很好的试出了各家数据库厂商和云厂商的成色。

关于 PostgreSQL 的开发，管理，原理，生态，工具，架构设计，性能优化，故障排查等方面的文章导航。

那些曾经让 MongoDB，MySQL 走向封闭的力量，如今也同样在 PostgreSQL 的生态中发挥作用，PG世界需要一个代表“软件自由”价值观的发行版。

2025 年的 SO 全球开发者调研结果新鲜出炉，PostgreSQL 连续第三年成为全球最流行，最受喜爱，需求量最高的数据库。已经没有什么力量能阻止 PostgreSQL 整合整个数据库世界了！

什么时候国产数据库和云计算也能有个“封闭高速”给大家上来溜一溜，拆穿这股满嘴跑火车的行业歪风。

最近 Google 推出了一个针对数据库的 MCP 工具箱，也许是第一个生产可用的方案。

PGDG 切断 FTP rsync 同步通道，全球镜像站普遍断连，这次还真是卡了一把全球用户的脖子。

AI 时代的数据库已经尘埃落定。资本市场对 PostgreSQL 标的密集出手，PG 已经成为 AI 时代的默认数据库。

在 PGConf.Dev 2025 全球 PG 开发者大会上， 来自 OpenAI 的 Bohan Zhang 分享了 OpenAI 在 PostgreSQL 上的最佳实践， 让我们得以一窥最牛独角兽内部的数据库使用情况。

一年一度的 PostgreSQL 开发者大会即将在五月于蒙特利尔举办。同上次第一届 PG Con.Dev 一样，这次也有一天的额外的专场活动 —— Postgres Extensions Day

Supabase 收购的一个 PG 内核分支，号称解决了 PG XID 回卷的问题，没有表膨胀问题，性能提升4倍，还支持云原生存储，现已加入 Pigsty 全家桶。

什么？PostgreSQL 现在可以使用 MYSQL 客户端访问了？没有错，愚人节刚开源的 openHalo 就提供了这样的能力，现已加入 Pigsty 内核全家桶。

利用 JuiceFS，将 PostgreSQL 变为一个带 PITR 的文件系统！

老冯很看好 “ DuckDB + PostgreSQL深度融合” 这路径。 我甚至认为，它可能会引爆数据库世界下一场“火星撞地球”式的变革。

和大家分享一下最近 PG 生态有趣的一些进展。

数据库是业务架构的核心，但如果更进一步，让数据库成为业务架构本身，那么会发生什么？

PostgreSQL 与 Pigsty 中长期缺失的一个包管理器 —— PIG

PostgreSQL是无聊数据库之王？2025年哪些是有前途能打的数据库？

不要在星期五发布代码，否则你会多忙一整周！PG小版本发布当天，紧急回滚新发布的小版本。

PG17使用PG16一半的时间实现扩展生态适配，300个可用扩展就绪，达到生产可用状态。PG 12正式脱离支持生命周期

PG扩展很多很强大，但如何安装并使用起来，一直都是社区的难题。现在有了Pigsty扩展仓库，390个强力插件开箱即用，有了这些扩展的加持，PG不能说在数据库里天下无敌，但也非常接近了。

没有规矩，不成方圆。本文是 22-24 年针对 PostgreSQL 15-17 大版本的更新，希望可以减少大家在使用与管理 PostgreSQL 数据库过程中遇到的困惑。

现在PG是世界上最先进的开源数据库，已经是各种规模组织的首选开源数据库，与顶尖商业数据库旗鼓相当，甚至更胜一筹。

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

PostgreSQL 可以直接从内核层面替换掉 Oracle，SQL Server 与 MongoDB，当然，最彻底的还是 SQL Server，AWS 出品的 Babelfishpg 直接做到了线缆协议级兼容。

正如两年前开展的向量数据库扩展插件赛马一样，当下 PG 生态进行的扩展竞赛已经开始围绕 DuckDB 进行，而MotherDuck官方亲自下场做PG扩展，毫无疑问标志着竞争进入白热化

2024 年的 SO 全球开发者调研结果新鲜出炉，PostgreSQL 连续第二年成为全球最流行，最受喜爱，需求量最高的数据库。已经没有什么力量能阻止 PostgreSQL 吞噬整个数据库世界了！

MySQL 9 新发布，这个所谓“创新版”成为一个酸楚的笑话 —— 曾经“最流行”的数据库 MySQL 正在死去。MySQL is dead，Long live PostgreSQL！

Dify 是一个生成式 AI 应用创新引擎，开源的 LLM 应用开发平台，本文介绍了如何使用 Pigsty 自建 Dify。

大会议程与主题分享，酒吧社交，自组织会议，PG仓库是如何维护的，社区参与度，一些中国特色问题。

PostgreSQL 全球开发组宣布，PostgreSQL 17 的首个 Beta 版本现已开放，这次 PG 真的是把牙膏管给挤爆啦！

如今，软件开发中最大的趋势之一，是 PostgreSQL 正在成为事实上的数据库标准。已经有一些博客阐述了如何在所有的场景下都是用 PostgreSQL，但直到现在，还没有多少文章能解释这一现象背后的原因。（更重要的是，为什么这件事很重要）。

PostgreSQL 不会改变其许可证

PostgreSQL 并不是一个简单的关系型数据库，而是一个数据管理的抽象框架，具有吞噬整个数据库世界的力量。而这也是正在发生的事情 —— “一切皆用 Postgres” 已经不再是少数精英团队的前沿探索，而是成为了一种进入主流视野的最佳实践。

生产环境的数据库是否应当放入容器中，仍然是一个充满争议的问题。站在DBA的立场上，我认为就目前而言，将生产环境数据库放入Docker中仍然是一个馊主意。

ParadeDB 旨在成为 Elasticsearch 的替代：Modern Elasticsearch Alternative built on Postgres —— 就是用于搜索和分析的 PostgreSQL。

本文讲述了 Cloudflare 是如何利用 15 个 PostgreSQL 集群，伸缩到支持每秒 5500 万个请求。以及 PostgreSQL 的可伸缩性表现。

本文是 PostgreSQL 核心组成员 Jonathan Katz 对 2024 年 PostgreSQL 项目的未来展望，并回顾过去几年 PostgreSQL 所取得的进展。

DB-Engines 今日正式宣布PostgreSQL 再度加冕为“年度数据库”，最近七年里，这已经是PG第五次获得此荣誉头衔，要不是中间有两年被Snowflake抢了风头，数据库世界几乎都变成PG的独角秀场了。

查询优化是 DBA 的核心工作内容之一，本文介绍了如何使用 pg_stat_statements 提供的指标，针对 PostgreSQL 进行宏观查询优化。

FerretDB旨在提供一个基于 PostgreSQL 的，真正开源的 MongoDB 替代。

备份是DBA的生命线 —— 但如果你的 PostgreSQL 数据库已经爆炸了又没有备份，那么该怎么办呢？也许 pg_filedump 可以帮到你！

以向量为代表的功能将成为构建应用时的关键要素，正如历史上的JSON一样。而PostgreSQL再一次站在时代风口浪尖引领数据库潮流，在向量扩展的加持下稳拿AI时代的高速增长。

数据库终局已现，PostgreSQL 称王。PG在SF2023开发者调研中拿下大满贯，占住了 Linux 之于服务器操作系统的生态位。本文便来说一说，为什么 PostgreSQL 是最成功的数据库。

本文聚焦被 AI 炒火了的向量数据库，介绍了AI嵌入与向量存储检索的基本原理，并用一个具体的知识库检索案例来串联介绍向量数据库插件 PGVECTOR 的功能、性能、获取与应用。

用性能数据说话，为什么PostgreSQL是世界上最先进的开源关系型数据库，暨世界上最成功的数据库。MySQL 和 PgSQL 性能谁好？分布式数据库到底怎么样？

数据库的用户是开发者，而开发者的意愿、喜好、选择又如何？总览 StackOverflow 过去六年的调研结果，不难看出在2022年，PostgreSQL 已经同时在这三项上登顶夺冠，成了字面意义上 “最成功的数据库”：

昨天在PostgreSQL中文社区做了一个直播分享，介绍了开源的PostgreSQL全家桶解决方案 —— Pigsty

数据库是信息系统的核心组件，关系型数据库是数据库中的绝对主力，而PostgreSQL是世界上最先进的开源关系型数据库。占据天时地利，何愁大业不成？

如何在PostgreSQL中实现比较复杂的模糊查询逻辑？

什么？不知道COLLATTION是什么，那记住一件事，用C COLLATE准没错！

本文介绍PostgreSQL 13中逻辑复制的相关原理，以及最佳实践。

慢查询是在线业务数据库的大敌，本文介绍了使用监控系统定位诊断慢查询的一般方法论。

机器因为故障重启，NTP服务在PG启动后修复了PG的时间，导致Patroni无法启动。

如何在线修改表中列的类型，例如从INT升级为BIGINT？

了解PostgreSQL中的黄金监控指标

概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。因此需要审慎地设计。

管数据库和管人差不多，都需要定KPI（关键性能指标）。那么数据库的KPI是什么？本文介绍了一种衡量PostgreSQL负载的方式：使用一种单一横向可比，与负载类型和机器类型基本无关的指标，名曰PG Load（PG负载）。

如何在线修改PostgreSQL中的字段类型？一种通用方法

PostgreSQL实际上只有两种事务隔离等级：读已提交（Read Commited）与可序列化（Serializable）

了解PostgreSQL服务器与客户端通信使用的TCP协议，并使用Go语言打印消息

今天遇到一个比较有趣的Case，客户报告说数据库连不上了，发现是扩展导致的。

数据变更捕获是一种很有趣的ETL替代方案。

详细介绍PostgreSQL中的各种锁

GIN索引如果使用很长的关键词列表进行搜索，会导致性能显著下降。本文解释了为什么GIN索引关键词搜索的时间复杂度为O(n^2)

复制是系统架构中的核心问题之一。

备份有各种各样的策略，物理备份通常可以分为四种。

有时候，组件之间的相互作用会以微妙的形式表现出来。例如使用pg_dump从连接池中导出数据，就可能产生连接池污染的问题。

采用二进制编辑的方式修复PostgreSQL数据页，以及如何让一条主键查询出现两条记录来。

PostgreSQL使用了MVCC作为主要并发控制技术，它有很多好处，但也会带来一些其他的影响，例如关系膨胀。

TimescaleDB是PostgreSQL的一个扩展插件，提供时序数据库的一些功能。

PipelineDB是PostgreSQL的一个扩展插件，提供流式数据处理的相关功能。

如果您在表上用了Interger的序列号，最好还是考虑一下可能溢出的情况。

XID WrapAround也许是PostgreSQL特有的一种故障

详细了解PostgreSQL中触发器的管理与使用

在应用开发中，一个‘很常见’的需求就是GeoIP转换。将请求的来源IP转换为相应的地理坐标，或者行政区划（国家-省-市-县-乡-镇）

没有规矩，不成方圆。本文针对PostgreSQL数据库原理与特性，整理了一份开发规范，可以减少大家在使用PostgreSQL数据库过程中遇到的困惑。

PostgreSQL的Slogan是“世界上最先进的开源关系型数据库”，要我说，最能生动体现PG特色的口号应该是：一专多长的全栈数据库，一招鲜吃遍天。

如何高效解决典型地理逆编码问题：根据用户的经纬度坐标，定位用户的行政区划。

KNN问题极致优化，从传统关系型设计到PostGIS

PostgreSQL中的表对应着许多物理文件，本文介绍如何统计一张表在PostgreSQL的实际大小

PgAdmin是一个管理PostgreSQL的GUI程序，用python写成，但实在是过于古早，需要一些额外配置。

最近发生了一起匪夷所思的故障，某数据库切走了一半的数据量和负载，结果却因为负载变大被打挂了。

一些PostgreSQL与Bash交互的技巧。

Exclude约束是一个PostgreSQL扩展，它可以实现一些更高级，更巧妙的的数据库约束。

PgSQL中的函数默认有三种易变性等级，合理使用可以显著改善性能。

使用Distinct On扩展字句快速找出分组内具有最大最小值的记录

汽车需要上油，数据库也需要维护保养。对Pg而言，有三项比较重要的维护工作：备份、重整、清理

备份是DBA的安身立命之本，有备份，就不用慌。

Pgbouncer是一个轻量级的数据库连接池，这里简单介绍Pgbouncer的配置、管理与使用。

PgBackRest是用perl写的一组PostgreSQL备份工具

尽管PostgreSQL提供了pgbench，但有时候为了吊打一下MySQL，还是需要用到sysbench的。

FIO可以很方便地测试磁盘IO性能

通常涉及到数据迁移，常规操作都是停服务更新。不停机迁移数据是相对比较高级的操作。

建议配置PostgreSQL的日志格式为CSV，方便分析，而且可以直接导入PostgreSQL数据表中。

索引很有用， 但不是免费的。没用到的索引是一种浪费，使用这里的方法找出未使用的索引