PostgreSQL
- 为什么PG将主宰AI时代的数据库
- 立足中国，面向全球的 PostgreSQL 发行版
- PG扩展云：解锁 PG 生态的全部潜力
- 从PG“断供”看软件供应链中的信任问题
- PostgreSQL主宰数据库世界，而谁来吞噬PG？
- PostgreSQL 已主宰数据库世界
- 卡脖子：PGDG切断镜像站同步通道
- Postgres Extension Day，咱们不见不散
- OrioleDB来了！4x性能，消除顽疾，存算分离
- OpenHalo：MySQL线缆兼容的PostgreSQL来了！
- PGFS：将数据库作为文件系统
- PostgreSQL 生态前沿进展
- 小猪骑大象：PG内核与扩展包管理神器
- 不要更新！发布当日叫停：PG也躲不过大翻车
- PostgreSQL 12 过保，PG 17 上位
- PostgreSQL神功大成！最全扩展仓库来了！
- PostgreSQL 规约（2024版）
- PostgreSQL 17 发布：摊牌了，我不装了！
- PostgreSQL可以替代微软SQL Server吗？
- 谁整合好DuckDB，谁赢得OLAP世界
- StackOverflow 2024调研：PostgreSQL已经杀疯了
- 使用Pigsty自建Dify：AI工作流平台
- 让PG停摆一周的大会：PGCon.Dev 2024 参会记
- PostgreSQL 17 beta1 发布！
- 为什么PostgreSQL是未来数据库的事实标准？
- PostgreSQL会修改开源许可证吗？
- PostgreSQL 正在吞噬数据库世界
- 技术极简主义：一切皆用Postgres
- PG生态新玩家：ParadeDB
- 令人惊叹的PostgreSQL可伸缩性
- PostgreSQL荣获2024年度数据库之王！（第五次）
- 展望 PostgreSQL 的2024
- PostgreSQL 宏观查询优化之 pg_stat_statements
- FerretDB：假扮成MongoDB的PG
- 如何用 pg_filedump 抢救数据？
- 向量是新的 JSON
- PostgreSQL：最成功的数据库
- AI大模型与向量库 PGVector
- PostgreSQL 到底有多强？
- 为什么PostgreSQL是最成功的数据库？
- 开箱即用的PG发行版：Pigsty
- 为什么PostgreSQL前途无量？
- PG中的本地化排序规则
- 高级模糊查询的实现
- PG复制标识详解（Replica Identity）
- PostgreSQL 逻辑复制详解
- PG慢查询诊断方法论
- 故障档案：时间回溯导致的Patroni故障
- 在线修改主键列类型
- 黄金监控指标：错误延迟吞吐饱和
- 数据库集群管理概念与实体命名规范
- PostgreSQL的KPI
- 在线修改PG字段类型
- 前后端通信线缆协议
- 事务隔离等级注意事项
- 故障档案：PG安装Extension导致无法连接
- CDC 变更数据捕获机理
- PostgreSQL中的锁
- GIN搜索的O(n²)复杂度
- PostgreSQL 常见复制拓扑方案
- 温备：使用pg_receivewal
- 故障档案：pg_dump导致的连接池污染
- PostgreSQL数据页面损坏修复
- 关系膨胀的监控与治理
- PipelineDB快速上手
- TimescaleDB 快速上手
- 故障档案：PostgreSQL事务号回卷
- 故障档案：序列号消耗过快导致整型溢出
- GeoIP 地理逆查询优化
- PostgreSQL的触发器使用注意事项
- PostgreSQL开发规约（2018版）
- PostgreSQL好处都有啥
- KNN极致优化：从RDS到PostGIS
- PostGIS高效解决行政区划归属查询
- 监控PG中的表大小
- PgAdmin安装配置
- 故障档案：快慢不匀雪崩
- Bash与psql小技巧
- Distinct On 去除重复数据
- 函数易变性等级分类
- 用 Exclude 实现互斥约束
- PostgreSQL例行维护
- 备份恢复手段概览
- PgBackRest2中文文档
- Pgbouncer快速上手
- PG服务器日志常规配置
- 空中换引擎：PostgreSQL不停机迁移数据
- 使用FIO测试磁盘性能
- 使用sysbench测试PostgreSQL性能
- 找出没用过的索引
- 批量配置SSH免密登录
- Wireshark抓包分析协议
- file_fdw妙用无穷——从数据库读取系统信息
- Linux 常用统计 CLI 工具
- 源码编译安装 PostGIS
- Go数据库教程：database/sql
- GO与PG实现缓存同步
- 用触发器审计数据变化
- SQL实现ItemCF推荐系统
- UUID性质原理与应用
- PostgreSQL MongoFDW安装部署
为什么PG将主宰AI时代的数据库
上下文窗口经济学，多元持久化的问题，以及零胶水架构的胜利，让 PG 成为 AI 时代的数据库之王。 阅读全文
立足中国，面向全球的 PostgreSQL 发行版
如何打造一个立足中国，面向全球的 PostgreSQL 数据库发行版？在第八届中国PG生态大会上的主题演讲。 阅读全文
PG扩展云：解锁 PG 生态的全部潜力
开源免费免翻墙，一键安装PG与431个扩展插件 14个Linux发行版 x 6大PG主版本原生 RPM/DEB。 阅读全文
从PG“断供”看软件供应链中的信任问题
PostgreSQL官方仓库切断全球镜像站同步通道，开源制成品断供，很好的试出了各家数据库厂商和云厂商的成色。 阅读全文
PostgreSQL主宰数据库世界，而谁来吞噬PG？
那些曾经让 MongoDB，MySQL 走向封闭的力量，如今也同样在 PostgreSQL 的生态中发挥作用，PG世界需要一个代表"软件自由"价值观的发行版。 阅读全文
PostgreSQL 已主宰数据库世界
2025 年的 SO 全球开发者调研结果新鲜出炉，PostgreSQL 连续第三年成为全球最流行，最受喜爱，需求量最高的数据库。 阅读全文
卡脖子：PGDG切断镜像站同步通道
PGDG 切断 FTP rsync 同步通道，全球镜像站普遍断连，这次还真是卡了一把全球用户的脖子。 阅读全文
Postgres Extension Day，咱们不见不散
一年一度的 PostgreSQL 开发者大会即将在五月于蒙特利尔举办。同上次第一届 PG Con.Dev 一样，这次也有一天的额外的专场活动 —— Postgres Extensions Day。 阅读全文
OrioleDB来了！4x性能，消除顽疾，存算分离
Supabase收购的一个PG内核分支，号称解决了PG XID回卷的问题，没有表膨胀问题，性能提升4倍，还支持云原生存储。 阅读全文
OpenHalo：MySQL线缆兼容的PostgreSQL来了！
PostgreSQL现在可以使用MySQL客户端访问了！愚人节刚开源的openHalo提供了这样的能力，现已加入Pigsty内核全家桶。 阅读全文
PGFS：将数据库作为文件系统
利用 JuiceFS，将 PostgreSQL 变为一个带 PITR 的文件系统！ 阅读全文
PostgreSQL 生态前沿进展
和大家分享一下最近 PG 生态有趣的一些进展：Omnigres、PG Mooncake、Citus 13、FerretDB 2.0、ParadeDB等。 阅读全文
小猪骑大象：PG内核与扩展包管理神器
PostgreSQL 与 Pigsty 中长期缺失的一个包管理器 —— PIG。 阅读全文
不要更新！发布当日叫停：PG也躲不过大翻车
不要在星期五发布代码，否则你会多忙一整周！PG小版本发布当天，紧急回滚新发布的小版本。 阅读全文
PostgreSQL 12 过保，PG 17 上位
PG17使用PG16一半的时间实现扩展生态适配，300个可用扩展就绪，达到生产可用状态。PG12正式脱离支持生命周期。 阅读全文
PostgreSQL神功大成！最全扩展仓库来了！
PG扩展很多很强大，但如何安装并使用起来一直都是社区的难题。现在有了Pigsty扩展仓库，390个强力插件开箱即用。 阅读全文
PostgreSQL 规约（2024版）
没有规矩，不成方圆。本文是22-24年针对PostgreSQL 15-17大版本的更新，希望可以减少大家在使用与管理PostgreSQL数据库过程中遇到的困惑。 阅读全文
PostgreSQL 17 发布：摊牌了，我不装了！
现在PG是世界上最先进的开源数据库，已经是各种规模组织的首选开源数据库，与顶尖商业数据库旗鼓相当，甚至更胜一筹。 阅读全文
PostgreSQL可以替代微软SQL Server吗？
PostgreSQL可以直接从内核层面替换掉Oracle、SQL Server与MongoDB，最彻底的是SQL Server，AWS出品的Babelfish直接做到了线缆协议级兼容。 阅读全文
谁整合好DuckDB，谁赢得OLAP世界
正如两年前开展的向量数据库扩展插件赛马一样，当下PG生态进行的扩展竞赛已经开始围绕DuckDB进行，MotherDuck官方亲自下场标志着竞争进入白热化。 阅读全文
StackOverflow 2024调研：PostgreSQL已经杀疯了
2024年的SO全球开发者调研结果新鲜出炉，PostgreSQL连续第二年成为全球最流行、最受喜爱、需求量最高的数据库。 阅读全文
使用Pigsty自建Dify：AI工作流平台
Dify 是一个生成式 AI 应用创新引擎，开源的 LLM 应用开发平台，本文介绍了如何使用 Pigsty 自建 Dify。 阅读全文
让PG停摆一周的大会：PGCon.Dev 2024 参会记
大会议程与主题分享，酒吧社交，自组织会议，PG仓库是如何维护的，社区参与度，一些中国特色问题。 阅读全文
PostgreSQL 17 beta1 发布！
PostgreSQL 全球开发组宣布，PostgreSQL 17 的首个 Beta 版本现已开放，这次 PG 真的是把牙膏管给挤爆啦！ 阅读全文
为什么PostgreSQL是未来数据库的事实标准？
原文链接：https://www.timescale.com/blog/postgres-for-everything/
如今软件开发中最大的趋势之一，是PostgreSQL正在成为事实上的数据库标准。直到现在还没有多少文章能解释这一现象背后的原因。 阅读全文
PostgreSQL会修改开源许可证吗？
原文链接：https://jkatz05.com/post/postgres/postgres-license-2024/
PostgreSQL 不会改变其许可证。本文是 PostgreSQL 核心组成员对此问题的回答。 阅读全文
PostgreSQL 正在吞噬数据库世界
PostgreSQL 并不是一个简单的关系型数据库，而是一个数据管理的抽象框架，具有吞噬整个数据库世界的力量。而这也是正在发生的事情 —— “一切皆用 Postgres” 已经不再是少数精英团队的前沿探索，而是成为了一种进入主流视野的最佳实践。
OLAP 领域迎来踢馆者
在 2016 年的一次数据库沙龙里，我提出了一个观点： 现在 PostgreSQL 生态的一个主要遗憾是，缺少一个足够好的列式存储分析插件来做 OLAP 分析。尽管PostgreSQL 本身提供了很强大的分析功能集，应付常规的分析任务绰绰有余。但在较大数据量下全量分析的性能，相比专用的实时数仓仍然有些不够看。
以分析领域的权威评测 ClickBench 为例，我们在其中标注出了 PostgreSQL 与生态扩展插件以及兼容衍生数据库在其中的性能表现。原生未经过调优的 PostgreSQL 表现较为拉垮（x1050），但经过调优后可以达到（x47）；此外还有三个与分析有关系的扩展：列存 Hydra（x42），时序扩展 TimescaleDB（x103），以及分布式扩展 Citus（x262）。
ClickBench c6a.4xlarge, 500gb gp2，Hot Run 执行相对耗时
这样的分析性能表现不能说烂，因为比起 MySQL，MariaDB 这样的纯 OLTP 数据库的辣眼表现（x3065,x19700）确实好很多；但第三梯队的性能表现也绝对说不上足够好，与专注于 OLAP 的第一梯队组件：Umbra，ClickHouse，Databend，SelectDB（x3~x4）相比，在分析性能上仍然有十几倍的性能差距。食之无味，弃之可惜。
然而， ParadeDB 和 DuckDB 的出现改变了这一点！
ParadeDB 提供的 PG 原生扩展 pg_analytics 实现了第二梯队（x10）的性能水准，与第一梯队只有 3～4 倍的性能差距。相对于其他功能上的收益，这种程度的性能差距通常是可以接受的 —— ACID，新鲜性与实时性，无需 ETL、额外学习成本、维护独立的新服务，更别提它还提供了 ElasticSearch 质量的全文检索能力。
而 DuckDB 则专注于 OLAP ，将分析性能这件事做到了极致（x3.2） —— 略过第一名 Umbra 这种学术研究型闭源数据库，DuckDB 也许是 OLAP 实战性能最快的数据库了。它并不是 PG 的扩展插件，但它是一个嵌入式文件数据库，而 DuckDB FDW 以及 pg_quack 这样的 PG 生态项目，能让 PostgreSQL 充分利用 DuckDB 带来的完整分析性能红利！
ParadeDB 与 DuckDB 的出现让 PostgreSQL 的分析性能来到了 OLAP 的第一梯队与金字塔尖，弥补了 PostgreSQL 在 OLAP 性能这最后一块关键短板。
分久必合的数据库领域
数据库诞生伊始，并没有 OLTP 与 OLAP 的分野。OLAP 数据仓库从数据库中“独立”出来，已经是上世纪九十年代时候的事了 —— 因为传统的 OLTP 数据库难以支撑起分析场景下的查询模式，数据量与性能要求。
在相当一段时间里，数据处理的最佳实践是使用 MySQL / PG 处理 OLTP 工作负载，并通过 ETL 将数据同步到专用的 OLAP 组件中去处理，比如 Greenplum, ClickHouse, Doris, Snowflake 等等。
设计数据密集型应用，Martin Kleppmann，第三章
与许多 “专用数据库” 一样，专业的 OLAP 组件的优势往往在于性能 —— 相比原生 PG 、MySQL 上有 1～3 个数量级的提升；而代价则是数据冗余、 大量不必要的数据搬运工作、分布式组件之间缺乏一致性、额外的专业技能带来的复杂度成本、学习成本、以及人力成本、 额外的软件许可费用、极其有限的查询语言能力、可编程性、可扩展性、有限的工具链、以及与OLTP 数据库相比更差的数据完整性和可用性 —— 但这是一个合理的利弊权衡。
然而天下大势，分久必合，合久必分。硬件遵循摩尔定律又发展了三十年，性能翻了几个数量级，成本下降了几个数量级。在 2024 年的当下，x86 单机可以达到几百核 (512 vCPU EPYC 9754x2)，几个TB的内存，单卡 NVMe SSD 可达 64TB，全闪单机柜 2PB ；S3 这样对象存储更是能实现几乎没有上限的存储。
硬件的发展解决了数据量的问题，而数据库软件的发展（PostgreSQL，ParadeDB，DuckDB）解决了查询模式的问题，而这导致分析领域 —— 所谓的“大数据” 行业基本工作假设面临挑战。
正如 DuckDB 发表的宣言《大数据已死》所主张的：大数据时代已经结束了 —— 大多数人并没有那么多的数据，大多数数据也很少被查询。大数据的前沿随着软硬件发展不断后退，99% 的场景已经不再需要所谓“大数据”了。
如果 99% 的场景甚至都可以放在一台计算机上用单机/主从的 DuckDB 或 PostgreSQL 搞定，那么使用专用的分析组件还有多少意义？如果每台手机都可以自由自主收发短信，那么 BP 机还有什么存在价值？（北美医院还在用BP机，正好比也还有 1% 不到的场景也许真的需要“大数据”）
基本工作假设的变化，将重新推动数据库世界从百花齐放的“合久必分”阶段，走向“分久必合”的阶段，从大爆发到大灭绝，大浪淘沙中，新的大一统超融合数据库将会出现，重新统一 OLTP 与 OLAP。而承担重新整合数据库领域这一使命的会是谁？
吞食天地的 PostgreSQL
数据库领域有许多“细分领域”：时序数据库，地理空间数据库，文档数据库，搜索数据库，图数据库，向量数据库，消息队列，对象数据库。而 PostgreSQL 在任何一个领域都不会缺席。
一个 PostGIS 插件，成为了地理空间事实标准；一个 TimescaleDB 扩展，让一堆“通用”时序数据库尴尬的说不出话来；一个向量扩展 PGVector 插件，更是让整个 专用向量数据库细分领域 变成笑话。
同样的事情已经发生过很多次，而现在，我们将在拆分最早，地盘最大的一个子领域 OLAP 分析中再次见证这一点。但 PostgreSQL 要替代的可不仅仅是 OLAP 数仓，它的野望是整个数据库世界！
然 PostgreSQL 有何德何能，可当此大任？诚然 PostgreSQL 先进，但 Oracle 也先进；PostgreSQL 开源，但 MySQL 也开源。PostgreSQL 先进且开源，这是它与 Oracle / MySQL 竞争的底气，但要说其独一无二的特点，那还得是它的极致可扩展性，与繁荣的扩展生态！
TimescaleDB 2022 社区调研：用户选择 PostgreSQL 的原因：开源，先进，扩展。
PostgreSQL 并不是一个简单的关系型数据库，而是一个数据管理的抽象框架，具有囊括一切，吞噬整个数据库世界的力量。而它的核心竞争力（除了开源与先进）来自可扩展性，即基础设施的可复用性与扩展插件的可组合性。
极致可扩展性的魔法
PostgreSQL 允许用户开发功能模块，复用数据库公共基础设施，以最低的成本交付功能。例如，仅有两千行代码的向量数据库扩展 pgvector 与百万行代码的 PostgreSQL 在复杂度上相比可以说微不足道，但正是这“微不足道”的扩展，实现了完整的向量数据类型与索引能力，干翻了几乎所有专用向量数据库。
为什么？因为 PGVECTOR 作者不需要操心数据库的通用额外复杂度：事务 ACID，故障恢复，备份PITR，高可用，访问控制，监控，部署，三方生态工具，客户端驱动这些需要成百上千万行代码才能解决好的问题，只需要关注自己所需问题的本质复杂度即可。
向量数据库哪家强？
再比如，ElasticSearch 基于 Lucene 搜索库开发，而 Rust 生态有一个改进版的下一代 Tantivy 全文搜索库作为 Lucene 的替代；而 ParadeDB 只需要将其封装对接到 PostgreSQL 的接口上，即可提供比肩 ElasticSearch 的搜索服务。更重要的是，它可以站在 PostgreSQL 巨人的肩膀上，借用 PG 生态的全部合力（例如，与 PG Vector 做混合检索），不讲武德地用数据库全能王的力量，去与一个专用数据库单品来对比。
Pigsty 中提供了 255 个可用扩展插件，在生态中还有 1000+ 扩展
可扩展性带来的另一点巨大优势是扩展的可组合性，让不同扩展相互合作，产生出 1+1 » 2 的协同效应。例如，TimescaleDB 可以与 PostGIS 组合使用，提供时空数据支持；再比如，提供全文检索能力的 BM25 扩展可以和提供语义模糊检索的 PGVector 扩展组合使用，提供混合检索能力。
再比如，分布式扩展 Citus 可以将单机主从数据库集群，原地升级改造为透明水平分片的分布式数据库集群。而这个能力是可以与其他功能正交组合的，因此，PostGIS 可以成为分布式地理数据库，PGVector 可以成为分布式向量数据库，ParadeDB 可以成为分布式全文搜索数据库，诸如此类。
更强大的地方在于，扩展插件是独立演进的，不需要繁琐的主干合并，联调协作。因此可以 Scale —— PG 的可扩展性允许无数个团队并行探索数据库前研发展方向，而扩展全部都是的可选的，不会影响主干核心能力的稳定性。那些非常强大成熟的特性，则有机会以稳定的形态进入主干中。
通过极致可扩展性的魔法，PostgreSQL 做到了**守正出奇，实现了主干极致稳定性与功能敏捷性的统一。**扎实的基本盘配上惊人的演进速度，让它成为了数据库世界中的一个异数，改变了数据库世界的游戏规则。
改变游戏规则的玩家
PostgreSQL 的出现，改变了数据库领域的游戏规则：任何试图开发“新数据库内核”的团队，都需要经过这道试炼与考验 —— 相比开源免费、功能齐备的 Postgres，价值点在哪里？
至少到硬件出现革命性突破前，实用的通用数据库新内核都不太可能诞生了，因为任何单一数据库都无法与所有扩展加持下的 PG 在整体实力上相抗衡 —— 包括 Oracle，因为 PG 还有开源免费的必杀技。
而某个细分领域的数据库产品，如果能在单点属性（通常是性能）上相比 PostgreSQL 实现超过一个数量级的优势，那也许还有一个专用数据库的生态位存在。但通常用不了多久，便会有 PostgreSQL 生态的开源替代扩展插件滚滚而来。因为选择开发 PG 扩展，而不是一个完整数据库的团队会在追赶复刻速度上有碾压性优势！
因此，如果按照这样的逻辑展开，PostgreSQL 生态的雪球只会越滚越大，随着优势的积累，不可避免地进入一家独大的状态。在几年的时间内，实现 Linux 内核在服务器操作系统领域的状态。而各种开发者调研报告，数据库流行趋势都在印证着这一点。
在引领潮流的 HackerNews StackOverflow 上，PostgreSQL 早已成为了最受欢迎的数据库。许多新的开源项目都默认使用 PostgreSQL 作为首要，甚至唯一的数据库 —— 例如，给各种数据库做模式管理的 Bytebase。《云时代数据库DevOps：硅谷调研》也提出，许多新一代互联网公司都开始积极拥抱并 All in PostgreSQL。
正如《技术极简主义：一切皆用 Postgres 》所言：简化技术栈、减少组件、加快开发速度、降低风险并提供更多功能特性的方法之一就是 “一切皆用 Postgres”。Postgres 能够取代许多后端技术，包括 MySQL，Kafka、RabbitMQ、ElasticSearch，Mongo和 Redis，至少到数百万用户时都毫无问题。一切皆用 Postgres ，已经不再是少数精英团队的前沿探索，而是成为了一种进入主流视野的最佳实践。
还有什么可以做的？
我们已经不难预见到数据库领域的终局。但我们又能做什么，又应该做什么呢？
PostgreSQL 对于绝大多数场景都已经是一个足够完美的数据库内核了，在这个前提下，数据库内核卡脖子纯属无稽之谈。这些Fork PostgreSQL 和 MySQL 并以内核魔改作为卖点的所谓“数据库”基本没啥出息。
这好比今天我们看 Linux 操作系统内核一样，尽管市面上有这么多的 Linux 操作系统发行版，但大家都选择使用同样的 Linux 内核，吃饱了撑着魔改内核属于没有困难创造困难也要上，会被业界当成山炮看待。
同理，数据库内核本身已经不再是主要矛盾，焦点将会集中到两个方向上 —— 数据库扩展与数据库服务！前者体现为数据库内部的可扩展性， 后者体现为数据库外部的可组合性。而竞争的形式，正如操作系统生态一样 —— 集中于数据库发行版上。对于数据库领域来说，只有那些以扩展和服务作为核心价值主张的发行版，才有最终成功的可能。
做内核的厂商不温不火，MariaDB 作为 MySQL 的亲爹 Fork 甚至都已经濒临退市，而白嫖内核自己做服务与扩展卖 RDS 的 AWS 可以赚的钵满盆翻。投资机构已经出手了许多 PG 生态的扩展插件与服务发行版：Citus，TimescaleDB，Hydra，PostgresML，ParadeDB，FerretDB，StackGres，Aiven，Neon，Supabase，Tembo，PostgresAI，以及我们正在做的 Pigsty 。
PostgreSQL 生态中的一个困境就是，许多扩展插件，生态工具都是独立演进，各自为战的，没有一个整合者能将他们凝聚起来形成合力。例如，提供分析的 Hydra 会打一个包一个 Docker 镜像， PostgresML 也会打自己的包和镜像，各家只发行加装了自己扩展的 Postgres 镜像。而这些朴素的镜像与包也距离 RDS 这样完整的数据库服务相距甚远。
即使是类似于 AWS RDS 这样的服务提供商与生态整合者，在诸多扩展面前也依然力有所不逮，只能提供其中的少数。更多的强力扩展出于各种原因（AGPLv3 协议，多租户租赁带来的安全挑战）而无法使用。从而难以发挥 PostgreSQL 生态扩展的协同增幅作用。
这里列出了一些重要扩展，对比基于最新的 PostgreSQL 16 主干版本进行，截止至 2024-02-28
扩展类目 Pigsty RDS / PGDG 官方仓库 阿里云 RDS AWS RDS PG 加装扩展 自由加装 不允许 不允许 地理空间 PostGIS 3.4.2 PostGIS 3.3.4 / Ganos 6.1 PostGIS 3.4.1 雷达点云 PG PointCloud 1.2.5 Ganos PointCloud 6.1 向量嵌入 PGVector 0.6.1 / Svector 0.5.6 pase 0.0.1 PGVector 0.6 机器学习 PostgresML 2.8.1 时序扩展 TimescaleDB 2.14.2 水平分布式 Citus 12.1 列存扩展 Hydra 1.1.1 全文检索 pg_bm25 0.5.6 图数据库 Apache AGE 1.5.0 GraphQL PG GraphQL 1.5.0 OLAP pg_analytics 0.5.6 消息队列 pgq 3.5.0 DuckDB duckdb_fdw 1.1 模糊分词 zhparser 1.1 / pg_bigm 1.2 zhparser 1.0 / pg_jieba pg_bigm 1.2 CDC抽取 wal2json 2.5.3 wal2json 2.5 膨胀治理 pg_repack 1.5.0 pg_repack 1.4.8 pg_repack 1.5.0 许多关键扩展在RDS中并不可用
扩展是 PostgreSQL 的灵魂，无法自由使用扩展的 Postgres 就像做菜不放盐。只能和 MySQL 放在同一个 RDS 的框子里同台，龙游浅水，虎落平阳。
而这正是我们想要解决的首要问题之一。
知行合一的实践：Pigsty
虽然接触 MySQL 和 MSSQL 要早得多，但我在 2015 年第一次上手 PostgreSQL 时，就相信它会是数据库领域的未来了。快十年过去，我也从 PG 的使用者，管理者，变为了贡献者，开发者。也不断见证着 PG 走向这一目标。
在与形形色色的用户沟通交流中，我早已发现数据库领域的木桶短板不是内核 —— 现有的 PostgreSQL 已经足够好了，而是用好数据库内核本身的能力，这也是 RDS 这样的服务赚的钵满盆翻的原因。
但我希望这样的能力，应该像自由软件运动所倡导的理念那样，像 PostgreSQL 内核本身一样 —— 普及到每一个用户手中，而不是必须向赛博空间上的封建云领主花大价钱租赁。
所以我打造了 Pigsty —— 一个开箱即用的开源 PostgreSQL 数据库发行版，旨在凝聚 PostgreSQL 生态扩展的合力，并把提供优质数据库服务的能力普及到每个用户手中。
Pigsty 是 PostgreSQL in Great STYle 的缩写，意为 PostgreSQL 的全盛状态。
我们提出了六点核心价值主张，对应 PostgreSQL 数据库服务中的的六个核心问题：Postgres 的可扩展性，基础设施的可靠性，图形化的可观测性，服务的可用性，工具的可维护性，以及扩展模块和三方组件可组合性。
Pigsty 六点价值主张的首字母合起来，则为 Pigsty 提供了另外一种缩写解释：
Postgres, Infras, Graphics, Service, Toolbox, Yours.
属于你的图形化 Postgres 基础设施服务工具箱。
可扩展的 PostgreSQL 是这个发行版中最重要的价值主张。在刚刚发布的 Pigsty v2.6 中，我们整合了上面提到的 DuckdbFDW 与 ParadeDB 扩展，这两个插件让 PostgreSQL 的分析能力得到史诗级增强，而我们确保每个用户都能轻松用得上这样的能力。
来自 ParadeDB 创始人与 DuckdbFDW 作者的感谢致意
我们希望整合 PostgreSQL 生态里的各种力量，并将其凝聚在一起形成合力，打造一个数据库世界中的 Ubuntu 发行版。而我相信，内核之争早已尘埃落定，而这里才会是数据库世界的未来竞争焦点。
- PostGIS：提供地理空间数据类型与索引支持，GIS 事实标准 （& pgPointCloud 点云，pgRouting 寻路）
- TimescaleDB：添加时间序列/持续聚合/分布式/列存储/自动压缩的能力
- PGVector：添加 AI 向量/嵌入数据类型支持，以及 ivfflat 与 hnsw 向量索引。（& pg_sparse 稀疏向量支持）
- Citus：将经典的主从PG集群原地改造为水平分片的分布式数据库集群。
- Hydra：添加列式存储与分析能力，提供比肩 ClickHouse 的强力分析能力。
- ParadeDB：添加 ElasticSearch 水准的全文搜索能力与混合检索的能力。（& zhparser 中文分词）
- Apache AGE：图数据库扩展，为 PostgreSQL 添加类 Neo4J 的 OpenCypher 查询支持，
- PG GraphQL：为 PostgreSQL 添加原生内建的 GraphQL 查询语言支持。
- DuckDB FDW：允许您通过 PostgreSQL 直接读写强力的嵌入式分析数据库 DuckDB 文件 （& DuckDB CLI 本体）。
- Supabase：基于 PostgreSQL 的开源的 Firebase 替代，提供完整的应用开发存储解决方案。
- FerretDB：基于 PostgreSQL 的开源 MongoDB 替代，兼容 MongoDB API / 驱动协议。
- PostgresML：使用SQL完成经典机器学习算法，调用、部署、训练 AI 模型。
Pigsty 支持的 180+ 扩展列表
开发者朋友们，你们的选择会塑造数据库世界的未来。希望我的这些工作，可以帮助你们更好的用好这世界上最先进的开源数据库内核 —— PostgreSQL。
参考阅读
Pigsty v2.6：PostgreSQL 踢馆 OLAP
展望PostgreSQL的2024 (Jonathan Katz)
2023年度数据库：PostgreSQL (DB-Engine)
技术极简主义：一切皆用Postgres
使用 Postgres 替代 Kafka、RabbitMQ、ElasticSearch、Mongo 和 Redis 是切实可行的方式，可以极大降低系统复杂度。 阅读全文
PG生态新玩家：ParadeDB
ParadeDB 旨在成为 Elasticsearch 的替代：用于搜索和分析的 PostgreSQL。 阅读全文
令人惊叹的PostgreSQL可伸缩性
原文链接：https://newsletter.systemdesign.one/p/postgresql-scalability
本文讲述了Cloudflare是如何利用15个PostgreSQL集群，伸缩到支持每秒5500万个请求，以及PostgreSQL的可伸缩性表现。 阅读全文
PostgreSQL荣获2024年度数据库之王！（第五次）
DB-Engines今日正式宣布PostgreSQL再度加冕为"年度数据库"，最近七年里这已经是PG第五次获得此荣誉头衔。 阅读全文
展望 PostgreSQL 的2024
本文是 PostgreSQL 核心组成员 Jonathan Katz 对 2024 年 PostgreSQL 项目的未来展望，并回顾过去几年 PostgreSQL 所取得的进展。 阅读全文
PostgreSQL 宏观查询优化之 pg_stat_statements
查询优化是 DBA 的核心工作内容之一，本文介绍了如何使用 pg_stat_statements 提供的指标，针对 PostgreSQL 进行宏观查询优化。 阅读全文
FerretDB：假扮成MongoDB的PG
FerretDB旨在提供一个基于 PostgreSQL 的，真正开源的 MongoDB 替代。 阅读全文
如何用 pg_filedump 抢救数据？
备份是DBA的生命线，但如果你的PostgreSQL数据库已经爆炸了又没有备份，该怎么办？也许pg_filedump可以帮到你！ 阅读全文
向量是新的 JSON
原文链接：https://jkatz05.com/post/postgres/vectors-json-postgresql/
以向量为代表的功能将成为构建应用时的关键要素，正如历史上的JSON一样。而PostgreSQL再一次站在时代风口浪尖引领数据库潮流，在向量扩展的加持下稳拿AI时代的高速增长。 阅读全文
PostgreSQL：最成功的数据库
数据库终局已现，PostgreSQL称王。PG在SF2023开发者调研中拿下大满贯，占住了Linux之于服务器操作系统的生态位。 阅读全文
AI大模型与向量库 PGVector
本文聚焦被 AI 炒火了的向量数据库，介绍了AI嵌入与向量存储检索的基本原理，并用一个具体的知识库检索案例来介绍向量数据库插件 PGVECTOR 的功能与应用。 阅读全文
PostgreSQL 到底有多强？
用性能数据说话，为什么PostgreSQL是世界上最先进的开源关系型数据库。MySQL和PgSQL性能谁好？分布式数据库到底怎么样？ 阅读全文
为什么PostgreSQL是最成功的数据库？
总览StackOverflow过去六年的调研结果，在2022年PostgreSQL已经同时在流行度、喜爱度、需求度三项上登顶夺冠，成了字面意义上最成功的数据库。 阅读全文
开箱即用的PG发行版：Pigsty
昨天在PostgreSQL中文社区做了一个直播分享，介绍了开源的PostgreSQL全家桶解决方案 —— Pigsty。 阅读全文
为什么PostgreSQL前途无量？
数据库是信息系统的核心组件，关系型数据库是数据库中的绝对主力，而PostgreSQL是世界上最先进的开源关系型数据库。占据天时地利，何愁大业不成？ 阅读全文
故障档案：时间回溯导致的Patroni故障
机器因为故障重启，NTP服务在PG启动后修复了PG的时间，导致Patroni无法启动。 阅读全文
数据库集群管理概念与实体命名规范
概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。 阅读全文
PostgreSQL的KPI
管数据库和管人差不多，都需要定KPI。本文介绍了一种衡量PostgreSQL负载的方式：使用一种单一横向可比的指标，名曰PG Load（PG负载）。 阅读全文
事务隔离等级注意事项
PostgreSQL实际上只有两种事务隔离等级：读已提交（Read Commited）与可序列化（Serializable）。 阅读全文
故障档案：PG安装Extension导致无法连接
今天遇到一个比较有趣的Case，客户报告说数据库连不上了，发现是扩展导致的。 阅读全文
GIN搜索的O(n²)复杂度
GIN索引如果使用很长的关键词列表进行搜索，会导致性能显著下降。本文解释了为什么GIN索引关键词搜索的时间复杂度为O(n²)。 阅读全文
故障档案：pg_dump导致的连接池污染
有时候，组件之间的相互作用会以微妙的形式表现出来。例如使用pg_dump从连接池中导出数据，就可能产生连接池污染的问题。 阅读全文
PostgreSQL数据页面损坏修复
采用二进制编辑的方式修复PostgreSQL数据页，以及如何让一条主键查询出现两条记录来。 阅读全文
关系膨胀的监控与治理
PostgreSQL使用了MVCC作为主要并发控制技术，它有很多好处，但也会带来一些其他的影响，例如关系膨胀。 阅读全文
PipelineDB快速上手
PipelineDB是PostgreSQL的一个扩展插件，提供流式数据处理的相关功能。 阅读全文
TimescaleDB 快速上手
TimescaleDB是PostgreSQL的一个扩展插件，提供时序数据库的一些功能。 阅读全文
GeoIP 地理逆查询优化
在应用开发中，一个很常见的需求就是GeoIP转换：将请求的来源IP转换为相应的地理坐标，或者行政区划。 阅读全文
PostgreSQL开发规约（2018版）
没有规矩，不成方圆。本文针对PostgreSQL数据库原理与特性，整理了一份开发规范，可以减少大家在使用PostgreSQL数据库过程中遇到的困惑。 阅读全文
PostgreSQL好处都有啥
PostgreSQL的Slogan是"世界上最先进的开源关系型数据库"，要我说最能生动体现PG特色的口号应该是：一专多长的全栈数据库，一招鲜吃遍天。 阅读全文
KNN极致优化：从RDS到PostGIS
KNN问题极致优化，从传统关系型设计到PostGIS，实现GIS圈选场景下三万倍的性能提升。 阅读全文
监控PG中的表大小
PostgreSQL中的表对应着许多物理文件，本文介绍如何统计一张表在PostgreSQL的实际大小。 阅读全文
PgAdmin安装配置
PgAdmin是一个管理PostgreSQL的GUI程序，用python写成，但实在是过于古早，需要一些额外配置。 阅读全文
故障档案：快慢不匀雪崩
最近发生了一起匪夷所思的故障，某数据库切走了一半的数据量和负载，结果却因为负载变大被打挂了。 阅读全文
用 Exclude 实现互斥约束
Exclude约束是一个PostgreSQL扩展，它可以实现一些更高级，更巧妙的的数据库约束。 阅读全文
PostgreSQL例行维护
汽车需要上油，数据库也需要维护保养。对Pg而言，有三项比较重要的维护工作：备份、重整、清理。 阅读全文
Pgbouncer快速上手
Pgbouncer是一个轻量级的数据库连接池，这里简单介绍Pgbouncer的配置、管理与使用。 阅读全文
PG服务器日志常规配置
建议配置PostgreSQL的日志格式为CSV，方便分析，而且可以直接导入PostgreSQL数据表中。 阅读全文
空中换引擎：PostgreSQL不停机迁移数据
通常涉及到数据迁移，常规操作都是停服务更新。不停机迁移数据是相对比较高级的操作。 阅读全文
使用sysbench测试PostgreSQL性能
尽管PostgreSQL提供了pgbench，但有时候为了吊打一下MySQL，还是需要用到sysbench的。 阅读全文
Wireshark抓包分析协议
Wireshark是一个很有用的工具，特别适合用来分析网络协议，这里简单介绍使用Wireshark抓包分析PostgreSQL协议的方法。 阅读全文
file_fdw妙用无穷——从数据库读取系统信息
通过file_fdw，轻松查看操作系统信息，拉取网络数据，把各种各样的数据源轻松喂进数据库里统一查看管理。 阅读全文
Linux 常用统计 CLI 工具
top, free, vmstat, iostat：四大常用 CLI 工具命令速查。 阅读全文
Go数据库教程：database/sql
同JDBC类似，Go也有标准的数据库访问接口。本文详细介绍了Go语言中database/sql的使用方法和注意事项。 阅读全文
GO与PG实现缓存同步
巧妙运用Pg的Notify功能，可以方便地通知应用元数据变更，实现基于触发器的逻辑复制。 阅读全文
用触发器审计数据变化
有时候，我们希望记录一些重要的元数据变更，以便事后审计之用。PostgreSQL的触发器就可以很方便地自动解决这一需求。 阅读全文
PostgreSQL MongoFDW安装部署
最近有业务要求通过PostgreSQL FDW去访问MongoDB，但是MongoDB FDW编译起来真是要人命啊。 阅读全文