前言
前阵子看到 Datadog 发了一篇文章，叫 The State of Postgres in 2026。
说实话，这种报告每年都不少，很多文章看完之后，大概也就留下几个印象：谁增长了，谁下降了，谁又成了年度宠儿。赶巧的是，这两天笔者又看到 Álvaro Herrera 在 Postgres Conference Germany 2026 上的一份演讲材料，叫 The next ten years of Postgres。
一个是从大量生产环境遥测数据里看 PostgreSQL 的今天；一个是从内核开发者视角看 PostgreSQL 未来十年可能会往哪里走。
PostgreSQL 今天的大热，并不是一蹴而就的，MySQL 就像是早年互联网里的轻骑兵，简单、直接、普及面广；PostgreSQL 则更像一位慢热的长跑选手，不靠一两次爆点出圈，而是每年拱一点，一步一个脚印。跑着跑着，大家回头一看，它已经站到舞台中央了。
Datadog 看到了什么？
报告里有几组数字挺扎眼。
第一，PostgreSQL 的使用比例还在涨。
按照 Datadog 的统计，在 2024 年 7 月到 2026 年 5 月之间，至少拥有一个生产 PostgreSQL 实例的组织比例，从 54% 增长到了 60%。这说明 PostgreSQL 并没有因为 NoSQL、云数据库、向量数据库这些概念的兴起而被边缘化，反而还在继续往应用系统里渗透。
第二，云上 PostgreSQL 增长明显。
2026 年 5 月，在使用 PostgreSQL 的组织中，65% 至少有一个云上 PostgreSQL 实例；同时，自建 PostgreSQL 也没有消失，仍然有相当比例存在。换句话说，PostgreSQL 并没有简单地从自建机房迁移到云上就完事了，而是在不同产品形态里继续扩散。
第三，Python 和 Node.js 成了访问 PostgreSQL 最活跃的两类语言生态。
这其实很符合这两年的体感。AI 应用、Agent 应用、快速原型、内部工具、SaaS 后端，很多都绕不开 Python 和 Node.js。而这些应用需要一个数据库时，PostgreSQL 当仁不让。
第四，pgvector 是增长最快的非内置扩展。
Datadog 统计显示，约一半生产 PostgreSQL 实例安装了至少一个非内置扩展。其中 pg_cron、postgis 这类扩展很常见，而 pgvector 在 2025 年 12 月到 2026 年 5 月之间增长了 24%，成为增长最快的非内置扩展。这就不用多解释了，AI 这把火，也烧到了 PostgreSQL 身上。
很多 AI 应用做着做着发现，光有向量检索远远不够，它还需要用户表、权限表、订单表、任务状态、会话上下文、审计日志、JSON 配置、全文检索、事务一致性、备份恢复、权限控制。
这些东西一旦都摊开，PostgreSQL 的优势就出来了。
你当然可以为向量检索单独上一套系统，为全文检索单独上一套系统，为 JSON 文档再上一套系统，然后再搞同步、权限、备份、监控和故障恢复。理论上都能做，问题是你愿不愿意为每一个中小规模 AI 应用都搞这么一套组合拳。
这大概就是 PostgreSQL 在 AI 时代重新被讨论的原因之一：它不是突然变成了所谓的”AI 数据库”、”AI Native”，而是 AI 应用突然发现，自己需要一个足够成熟、足够通用、生态又足够丰富的数据库。巧了，PostgreSQL 正好站在那里。
会用 PostgreSQL，不等于用好 PostgreSQL
Datadog 这篇报告有价值的地方，并不是帮 PostgreSQL 唱赞歌，而是把一些生产环境中的老顽疾也暴露了出来。
比如
statement_timeout。Datadog 统计显示，只有 15% 的生产实例启用了statement_timeout。也就是说，在他们观测到的样本里，大量 PostgreSQL 实例理论上都可能被一条坏 SQL 拖住很久。说实话，看到这个数字，笔者还是有点震惊的。statement_timeout不是什么高深技巧，也不是什么新特性，它就是数据库运维里很朴素的一道保险丝。你可以按业务类型分层配置，可以给批处理留更长窗口，也可以给 OLTP 请求设置较短超时，但完全不设，生产上迟早要交学费。再比如 idle in transaction。Datadog 报告里提到，PostgreSQL 后端有相当多时间耗在 idle in transaction 状态。这个问题 DBA 太熟了，堪称 DB Killer。应用开了事务，然后去等用户输入、调外部接口、卡在网络、或者代码逻辑中途挂住，事务就那么晾着。数据库表面上没在干活，实际上锁、快照、连接、xmin、autovacuum 全可能被它牵着走。你看着 CPU 不高，IO 不高，但表开始膨胀，vacuum 清不动，连接池慢慢被占满，最后事故出现时，大家还一脸无辜：我刚才也没跑大 SQL 啊。
再看索引。Datadog 说，生产环境里 99% 以上的表都有索引，但是有效使用高级索引的比例并不高。Covering Index 只占全部索引的 0.3%，Partial Index 也只有 1.8%。JSONB 更典型，22% 的表有 JSONB 字段，但只有约 2% 的 JSONB 字段带索引。
这说明了什么？**说明很多系统确实在用 PostgreSQL，但用法还是偏”能跑就行”，没有继续深入。**B-tree 建了，主键有了，业务跑起来了，至于是否可以用 INCLUDE 做 Index Only Scan，是否可以用 Partial Index 减少无效索引体积，JSONB 查询是否该配 GIN，就不了了之了。
这也符合很多生产现场的真实情况。
PostgreSQL 越来越流行，不代表 PostgreSQL 运维能力也同步变强。很多团队把 PostgreSQL 当成一个云上服务，点几下就出来一个实例，然后就以为问题解决了，可数据库从来不是创建成功就完事了。生产里真正救命的东西不能忘。
为什么 AI 时代会继续推高 PostgreSQL？
笔者不太喜欢振臂高呼”PostgreSQL 赢麻了”，搞得像饭圈文学一样。但是，从相对客观的角度看，PostgreSQL 在 AI 时代确实占了几个便宜。
第一，它足够通用。
AI 应用表面上很新，其实里面大量东西还是传统应用那一套：用户、权限、租户、账单、任务、状态、历史记录、审计、配置、消息、日志。只不过旁边多了 embedding、prompt、上下文、知识片段和模型调用记录。
这些东西天然需要一个事务型数据库兜住。这也是为什么 Snowflake、Databricks 这类数据平台，最近几年都开始补 PostgreSQL / OLTP 入口。
第二，它扩展性强。
PostgreSQL 的扩展机制，过去支撑了 PostGIS、TimescaleDB、Citus、pg_cron、pg_repack、pg_stat_statements 等一堆生态能力；现在 pgvector 又火了。它的厉害之处不在于内核把所有事情都做完，而在于它给生态留了足够多的入口。
第三，开发者熟。
AI Agent 生成代码时，PostgreSQL、Python、Node.js、SQLAlchemy、Prisma、Django、FastAPI 这些组合非常容易自然出现。你让一个开发者快速做个原型，他大概率也更愿意先拿 PostgreSQL 开干，而不是上来就拆成五六个专用存储系统。
这里还有一个变化，我觉得很容易被低估。
过去数据库选型通常发生在架构设计阶段。大家坐下来评估：用 MySQL 还是 PostgreSQL，要不要上 MongoDB，要不要单独搞搜索、向量、缓存。
但 AI 编程出来以后，一部分选型会提前到应用生成阶段。工具帮你生成后端、表结构、迁移脚本、ORM 代码时，数据库其实已经被顺手选好了。等人再回过头来研究数据库，表已经建了，代码已经连上了，数据也已经写进去了。
这就很微妙了。
未来数据库产品的竞争，可能会提前到开发工具、Agent、模板工程和文档里。谁更容易被工具正确调用，谁更容易让 Agent 少犯低级错误，谁就更容易成为新项目的默认选项。
所以，看到 Supabase 发布面向 Agent 的 Postgres 最佳实践，Neon 也在提供自己的 Agent Skills，我并不觉得这只是写几篇文档那么简单。以后文档当然还要给人看，但也要给工具看。
第四，运维体系成熟。
备份、恢复、监控、高可用、权限、审计、连接池、慢 SQL 分析、参数调优、迁移升级等等，坑当然很多，但资料、工具和经验也很多。对于生产系统来说，”已知的坑”本身就是一种优势，前阵子沸沸扬扬的 Rust PostgreSQL，你敢用吗？
那些还在早期的数据库项目，看看热闹可以，真要替换核心库，还是得掂量。
AI 并没有把 PostgreSQL 变成一个全新的东西，它只是放大了 PostgreSQL 原本就有的优势：通用、可靠、可扩展、生态成熟、开发者容易上手。
未来十年：PostgreSQL 内核要补什么课？
Álvaro Herrera 在 The next ten years of Postgres 里有一个很有意思的切入点：如果回到 2016 年，PostgreSQL 9.6 当时已经很强，但那时候还没有声明式分区、逻辑复制、MERGE、生成列、扩展统计信息、JIT、Table Access Method，也没有今天这些更完整的 SQL/JSON、Temporal SQL 能力。
十年前觉得缺的东西，很多今天已经变成日常了。
所以看未来十年时，不能只拿今天的 PostgreSQL 视角去框死未来。PostgreSQL 不是那种一年换一个故事的项目，它变化慢，但它真的会变。
1. Table AM：存储形态会继续变多
PostgreSQL 现在已经有 Table Access Method 这套接口，但内核里能直接选择的表存储形态还很有限。
未来十年，如果 PostgreSQL 能在内核或近内核生态里更好地支持多种存储形态，比如 zheap、列存、时序存储、Append-only 存储、Temporal 存储，甚至 Index-organized Table，那么 PostgreSQL 的边界会继续变宽。
为什么这个方向重要？
因为 OLTP、OLAP、时序、日志、向量、历史版本数据，对存储的要求并不一样。今天很多问题，本质上不是 SQL 写得不够漂亮，而是行存 Heap 要承担太多不同负载。
Vacuum、膨胀、冷热数据、批量扫描、更新频率、压缩效率，这些问题最终都会落到存储层。
如果未来 PostgreSQL 能在保持上层 SQL、事务和生态兼容的前提下，让不同负载选择更合适的存储形态，那就不是多一个功能那么简单了。
2. 逻辑复制：从”能复制”走向”更像系统能力”
PostgreSQL 的逻辑复制这些年进步很大，但熟悉生产环境的同学都知道，离”省心”还有不少距离。
DDL 怎么办？序列怎么办？冲突怎么办？双向复制怎么办？多主复制怎么办？复制延迟和一致性怎么解释给业务听？
这些问题没有一个是小问题。
演讲中提到的 multi-primary replication、bi-directional replication、better conflict handling、conflict-resistant datatypes、replication of DDL，本质上都是在补这些账。
如果 PostgreSQL 未来要在云原生、跨区域、多活、边缘节点、SaaS 多租户这些场景里继续扩大影响力，逻辑复制还需要再完善一些。
3. Concurrent DDL：别让 DDL 变成事故按钮
很多人吐槽 PostgreSQL DDL 锁重，这个不是一天两天了。
CREATE INDEX CONCURRENTLY 已经解决了一部分问题，社区里也有 pg_migrate、pg_rewrite、pg_osc 等工具在尝试缓解 DDL 变更的影响。但是 VACUUM FULL、表重写、列类型变更、分区调整，这些操作一旦遇到大表，DBA 心里都得咯噔一下。
但方向是清晰的：未来 PostgreSQL 如果想继续承载更大规模、更核心的业务，就必须让更多维护动作变得更”不打扰业务”。
这对 DBA 来说太重要了。很多生产事故并不是查询突然慢，而是一个看似普通的 DDL 把业务挡在门外。
4. 分析能力：PostgreSQL 不会甘心只做 OLTP
演讲中还提到了 batched executor、vectorized execution，再结合 Table AM 和 async I/O，其目的不言而喻：让 PostgreSQL 的分析能力继续增强。
这样一来，PostgreSQL 会把更多中小规模分析、混合查询、实时查询、近业务侧分析留在数据库内部完成，而不是动不动就把数据搬到另一套系统里。
很多业务并不需要一上来就 Spark、Trino、ClickHouse 全家桶。它只是想查最近 7 天订单，按租户、用户、渠道、状态做一点聚合，再和业务表关联一下。
如果 PostgreSQL 在执行器、存储和 I/O 上继续进步，这类场景也会成为 PostgreSQL 自身的舒适区。
5. Sharding / MPP：这块 PostgreSQL 还没有最终答案
Datadog 报告里也提到一个有意思的现象：分区被不少组织使用，但真正通过 Citus 这类方案做数据库级 Sharding 的比例非常低。
这说明 PostgreSQL 的水平扩展问题，并没有一个被绝大多数用户接受的标准答案。
有的团队选择应用层拆库拆表，有的选择云厂商能力，有的选择 Citus，有的选择把大分析负载导出去，有的干脆通过硬件纵向扩容继续扛。
PostgreSQL 社区未来如果要认真回答 Sharding / MPP，就不能只停留在”有扩展可以做”。因为当一个能力变成大规模生产共性需求时，只靠各家扩展和产品各自发挥，用户心智会很分裂。
这也是为什么 Greenplum、WarehousePG、Citus 这类路线仍然值得关注。它们不一定代表社区最终答案，但至少说明 PostgreSQL 生态一直在尝试突破单机边界。
6. AIO 和多线程：老架构也要继续面对新硬件
PostgreSQL 传统进程模型非常经典，也非常稳定。但新硬件、新云环境、新 I/O 栈、新并发模型一直在推进。
PostgreSQL 18 已经引入异步 I/O 的基础能力，后续版本大概率还会沿着这条线继续往前走。演讲里也把 AIO 和 multithread server 放进未来十年讨论范围。
这些东西短期内未必会让普通用户感知特别明显，但它们决定了 PostgreSQL 能不能继续吃到现代硬件红利。
数据库性能从来不只是 SQL 优化。进程模型、调度、I/O、内存利用率、NUMA、锁竞争、缓存管理，每一个地方都可能卡住上限。
PostgreSQL 的未来，未必只发生在 PostgreSQL 内核里
但是我们不要陷入典型的开发者思维：只盯着内核。否则，我们可能会忽视一件重要的演变：PostgreSQL 正在变成很多数据库产品的共同入口。
Neon 便是一个很典型的例子。笔者之前也做过不少分析，感兴趣的读者可以回头翻一下：从 Lakebase 到 LTAP，是旧饭新炒，还是新的技术范式？。
Neon 不是简单托管一个 PostgreSQL，它把 PostgreSQL 的计算和存储拆开，引入可分支、可回溯、可弹性伸缩的存储架构。对开发者来说，这意味着一个数据库可以像代码一样创建分支、回滚、隔离测试环境；对 AI Agent 来说，这意味着它可以快速创建自己的数据库环境，不需要每次都等一个传统数据库实例慢慢拉起来。
Databricks 2025 年宣布收购 Neon，也不是为了图个热闹。Databricks 原来强在 Lakehouse、Spark、SQL、AI、机器学习，但它一直缺一个贴近应用侧的事务数据库入口。AI 应用再怎么酷炫，最后总要落到状态、上下文、权限、任务、账单和审计。没有 OLTP 入口，AI 平台就很难真正贴近应用。
所以 Neon 被 Databricks 看中，本质上说明：PostgreSQL 不再只是数据库厂商自己的事情，它已经成了数据和 AI 平台都想纳入的能力。
再看 DuckDB。2026 年 8 月，AWS 宣布签署收购 DuckLabs 的协议，不过不是 DuckDB 开源项目被 AWS 收购。AWS 官方也明确说了，不会收购 DuckDB 开源项目；DuckDB 仍然由独立的 DuckDB Foundation 管理，并继续以 MIT 许可证开源。DuckLabs 官方也说明，DuckDB、DuckLake、Quack 等开源组件会继续保持开放。
那这件事说明什么？
DuckDB 和 PostgreSQL 不是同一类数据库，一个更贴近嵌入式分析、本地分析、开放数据文件和对象存储生态；一个更贴近事务、状态、业务系统和通用 SQL 生态。
但它们被大厂同时盯上，背后有一个共同趋势：数据库内核能力正在被更大的云平台和 AI 平台吸收。
过去云厂商更多是在卖”数据库服务”；现在它们要的是，把数据库能力嵌进自己的数据平台、AI 平台、开发平台和对象存储生态里。
你看 Neon，讲的是 serverless Postgres、branching、scale-to-zero、AI Agent。
你看 DuckDB，讲的是贴近数据文件、贴近本地计算、贴近 S3 和开放数据栈。
方向不同，但都指向同一件事：数据库不再只是一个独立产品，它正在变成平台能力的一部分。
下一个 Neon 在哪里？
看到这里，假如你问：PostgreSQL 还会不会继续流行？这个问题意义不大。PostgreSQL 肯定还会继续流行，只是可能流行方式会变。
下一个被重新定价的 PostgreSQL 产品，会是什么？
几年前 Neon 刚出来时，不少人对它的印象大概是：一个很酷的 serverless PostgreSQL demo，能分支，能回滚，存储计算分离，开发者体验不错。
传统 DBA 看到这类产品，第一反应往往是：能扛核心交易吗？延迟稳吗？出问题能不能自己接管？但资本市场和云厂商看的，可能是另一件事：数据库的使用单位变了。
过去，一个数据库通常对应一个长期运行的业务系统。你买机器、装库、建主备、配监控、接应用，然后一跑好几年。
但是 AI Agent 和新一代开发工具带来的变化是：数据库可能变成一种短生命周期资源。写一个 demo 要一个库，跑一个测试要一个库，验证一次 schema migration 要一个库，一个 Agent fork 一份状态也要一个库。用完就扔，错了就回滚，互相隔离，最好还不用人工干预。
这个时候，如果数据库还是按”固定规格 + 人工开通 + 长期运行 + 按月付费”的方式来理解，就有点跟不上趟了。
Neon 最值钱的地方，是把数据库从一个笨重实例，变成了可以被程序快速创建、复制、回滚和丢弃的状态资源。
很多技术人容易低估这种变化，因为我们习惯用”能不能替换核心生产库”来评价一个数据库产品。但新产品的第一波爆发，往往不从核心库开始，而是从那些传统数据库体验最别扭的地方开始。
开发测试别扭，分支环境别扭，临时数据库别扭，AI Agent 需要状态隔离也别扭。
Neon 正好切在这里。
所以，下一个 PostgreSQL 产品风口，我觉得不太会是”再做一个托管 PostgreSQL”。RDS 这条路已经很卷了。
也不太会只是再包装一个 pgvector。向量重要，但向量只是 AI 应用数据的一块，不是全部。
更大的机会，可能藏在下面几个方向里。
1. 可分支数据库：数据也要像代码一样被管理
数据库分支过去看起来像一个开发测试功能，挺好用，但好像也没到非有不可的地步。
现在就不一样了。
当 Agent 开始自动写代码、自动改 schema、自动造数据、自动跑测试时，它最需要的不是一个昂贵而神圣的生产库，而是一堆可隔离、可回滚、可审计的小环境。
人写错 SQL，还能开会复盘；Agent 写错 SQL，你总不能天天拉着它开事故会。
更现实的方式是：给它一个分支库，让它在里面折腾。验证结果能接受，再进入正式变更流程；折腾错了，扔掉。
这套逻辑如果做顺，数据库会从”稀缺资源”变成”开发工作流的一部分”。以后创建一个数据库分支，应该像创建一个 Git branch 一样自然。
这也是 Neon 被重新估值的真正原因之一。
它当然没有解决所有 PostgreSQL 生产问题，但它真正推进的是另一件事：让数据库状态进入现代开发工作流。
这句话很关键。
如果再往产品里想一步，分支还只是地基。
真正能收钱的事情，是把数据库变更验证做完整。比如 Agent 准备修改一张大表，不是直接把迁移脚本丢到生产上跑，而是先拉一个经过必要脱敏的分支环境；改完以后，用代表性 SQL 跑一遍，比较执行计划、锁等待、WAL、索引体积、vacuum 压力和资源消耗；确认风险可接受，再生成正式环境的变更步骤，并且上线后继续观察。
这听上去不 sexy，但生产里非常值钱。
因为很多事故并不是数据库不会分支，而是变更前没人知道它到底会锁多久、扫多少数据、写多少 WAL、失败后怎么撤。
数据库不能完全照搬代码分支。代码分支可以慢慢 merge，生产数据却一直在变；schema 变更、业务写入、历史数据回填、索引构建，节奏都不一样。谁能把这些差别处理好，谁就不是在卖一个”酷功能”，而是在替用户少背事故。
2. Postgres everywhere：PG 不一定只跑在服务端
2026 年 8 月，Electric 加入 Databricks，并进入 Neon 团队。这件事我觉得非常值得关注。
Electric 背后有两个东西：PGlite 和同步引擎。
PGlite 是 PostgreSQL 的 WASM 形态，可以跑在浏览器、Node.js、Bun、Deno、沙箱环境里。按照 Neon 的说法，PGlite 在一年里从 100 万增长到 1300 万周下载量；Electric 自己也提到，PGlite 最早来自 Neon 联合创始人 Stas Kelvich 的一个实验性 WASM PostgreSQL 项目。
这又是一个容易被传统 DBA 低估的方向。
很多人会问：在浏览器里跑 PostgreSQL，有啥用？生产核心库能这么搞吗？
还是那个问题，别总拿核心库去卡所有创新。
PGlite 这类东西真正打开的，是另一类场景：本地开发、CI 测试、浏览器 IDE、Agent 沙箱、离线应用、边缘计算、前端近端查询。
未来很可能会出现一种架构：中心是一个云上 PostgreSQL，本地、浏览器、Agent 沙箱里也跑一个轻量 PostgreSQL，数据通过同步引擎保持一致。
这时候 PostgreSQL 的形态就被拉开了：它可以是机房里的数据库服务器，也可以是嵌在工具链、浏览器和 Agent 沙箱里的 SQL 状态层。
当然，这条路也很难。同步、冲突处理、权限边界、schema 演进、离线写入、重连恢复，每一项都能把人折腾得怀疑人生。
但越难，越说明这里可能有机会。如果这些问题很容易，早就没多少空间了。
3. 自动 DBA：别再只给我看图了，告诉我该怎么办
Datadog 报告里那些数字，其实暴露出一个很大的产品机会。
只有 15% 的实例启用了 statement_timeout，大量 JSONB 字段没有索引，Covering Index 和 Partial Index 使用比例很低，idle in transaction 到处都有。
这说明什么？说明 PostgreSQL 用户越来越多，但真正懂 PostgreSQL 的人远远不够。
所以我认为，自动 DBA 会是一个很大的方向。但这里的自动 DBA，不是弄个聊天框，然后问一句”帮我优化一下数据库”。
那玩意儿十有八九会变成玄学。
真正有价值的自动 DBA，不能只靠模型在那里猜。它必须真正地理解，从根儿上理解，然后再给出明确动作：
- 哪个事务正在拖住 vacuum；
- 哪个 JSONB 查询应该建 GIN；
- 哪个索引长期没用可以考虑清理；
- 哪类 SQL 应该单独设置
statement_timeout； - 哪张表的 autovacuum 参数不合理；
- 哪个连接池配置正在把数据库顶爆；
- 哪次版本升级风险最大，应该先验什么。
也就是说，未来好的 PostgreSQL 运维产品，不应该只告诉你”这里红了”。DBA 自己也能看到红。
它要能告诉你：为什么红，先处理谁，怎么处理，处理之后怎么验证。
Supabase 2026 年融资时同时提到 Multigres，我觉得也能看出这个方向。它把 Multigres 描述成面向 PostgreSQL 的可扩展操作系统，目标包括高可用、运维简化，未来还会做水平扩展。你看，连主打开发者体验的平台都开始讲”PostgreSQL 很难规模化运维”了。
这就是现实。PostgreSQL 越流行，自动化运维这块就越有价值。
4. 适度规模的混合负载：别一上来就全家桶
DuckDB 这两年的火，也给 PostgreSQL 生态提了一个醒：数据库产品不一定非要从”最大规模”开始讲故事。
很多业务系统的数据量当然会增长，但在相当长一段时间里，它真实要处理的可能就是几十 GB、几百 GB、几 TB 的事务数据，再加上一些报表、全文检索、JSON 查询、向量检索和近实时分析。
这种规模尴尬就尴尬在这里。
你说它小吧，业务已经很重要，不能拿玩具系统糊弄；你说它大吧，又没必要上来就搞一套非常复杂的湖仓、搜索、向量库、实时链路和调度系统。
如果 PostgreSQL 或 PostgreSQL 生态产品能在这个范围内把事情做简单，价值很实在：少部署几个系统，少同步几份数据，少查半天”哪份数据才是真的”。
当然，简单不是把所有负载硬塞进同一个资源池。在线交易被分析查询拖死，这不叫统一，这叫埋雷。
更合理的方向，是查询入口和数据语义尽量统一，底层资源可以隔离；事务、分析、检索各吃各的资源，但用户不必被迫维护一堆割裂系统。
PG 原生分析能力是一条路，pg_duckdb 这类引擎集成也是一条路。最后哪条路更好，要看实现。但”在明确规模内，把混合需求做简单”，我觉得本身就是一个很强的产品定位。
5. PostgreSQL + Lakehouse：谁能把事务数据自然带到分析侧，谁就有牌
Databricks 买 Neon，Snowflake 买 Crunchy Data，AWS 收 DuckLabs，这几件事放在一起看，背后有一条暗线：事务数据、分析数据、AI 数据不想再各玩各的。
业务系统里的数据，刚写进 PostgreSQL，分析侧就想看；AI 应用刚产生状态，评估、审计、特征、画像就想接着用。
过去这条链路靠 CDC、ETL、同步表、导出文件、数据湖管道硬凑。
能用，但复杂。
复杂到最后经常变成：源库一份，数仓一份，湖里一份，搜索一份，向量库一份，出了问题谁也说不清哪份才是真的。
所以 PostgreSQL + Lakehouse 会继续有机会。
不过这条路，真正的考验是从架构蓝图走向工程现实。把 PostgreSQL 数据”同步到对象存储”不难，难的是把 PostgreSQL 的语义带过去。
MVCC、事务快照、TOAST、排序规则、自定义类型、扩展索引、DDL、跨表一致性、增量合并、错误恢复，哪个都不是省油的灯。
如果未来有产品能把 PostgreSQL 的事务数据，以清晰的一致性语义、较低的数据复制成本、较好的分析性能接到 Iceberg、Delta、Parquet 这类开放生态里，那会非常有想象力。
6. 企业上下文数据服务：上传 PDF 问答只是玩具
再往 AI 方向走远一点，我还会看一个东西：企业上下文数据服务。
“上下文”这个词现在有点被说烂了，一说就是 RAG，一说就是上传 PDF，然后问几个问题。这个当然能演示，但离生产还差得远。
真实业务里，一个销售助手要判断客户能不能享受优惠，可能要同时看合同条款、客户等级、最新订单、审批记录、历史沟通和内部政策。合同是文档，订单是结构化数据，审批有状态和时间，权限还跟组织架构有关。
向量检索只能解决”找相似内容”的一部分问题。
真正麻烦的是：这份合同是不是最新版本？订单状态有没有更新？这个销售有没有权限看？答案引用的依据能不能追溯？权限撤销以后，已经切片和向量化的数据会不会继续被搜出来？
这些问题每个 Agent 团队都自己做一遍，肯定会很痛。
PostgreSQL 适合参与这类产品，不是因为它突然变成知识库神器，而是因为企业上下文离不开关系数据、状态管理、权限控制、事务语义和多种检索方式。PG 正好有机会把这些东西放在一个相对统一的基础上。
不过同库不等于整条链路自动一致。外部文档变了，重新解析、切片、生成 embedding 往往是异步的；权限变了，派生数据能不能及时失效，也需要单独设计。
如果有产品真能把更新、版本、来源、权限和检索结果的可追溯性处理好，它面对的就不是”做一个聊天机器人”的需求，而是企业里长期存在的数据治理和应用集成问题。
这个方向想象空间大，但也更难。短期我更看好数据库变更验证和自动 DBA；长期看，企业上下文数据服务可能会长出新的 PostgreSQL 产品形态。
7. PG 兼容：数据库世界里的流量入口
还有一个容易被忽略的点：PostgreSQL 兼容本身，会越来越值钱。
一个新数据库，如果能走 PostgreSQL 协议、能跑常见 PostgreSQL SQL、能接主流驱动、ORM、BI、迁移工具，那么它获客成本就会低很多。
开发者不用重新学一套东西，应用不用重写一堆适配，运维也不至于从零开始。
所以未来我们会看到越来越多”PostgreSQL compatible”的产品，比如 Babelfish、DocumentDB 等等，五花八门。
有些是真的 PostgreSQL，有些是 PostgreSQL 内核改造，有些只是协议兼容，有些可能只是语法兼容。
这里面水会很深。
对用户来说，不能只看兼容两个字。你要问清楚：事务语义兼容吗？锁行为兼容吗？隔离级别兼容吗？扩展兼容吗？备份恢复兼容吗？系统表兼容吗？执行计划和错误码兼容吗？
兼容是入口，不是免检金牌。
但从产品角度看，PostgreSQL 已经变成一种很强的分发能力。谁能站在 PostgreSQL 生态上做出新体验，谁就有机会吃到这波红利。
对 DBA 来说，这意味着什么？
很多人一看到 PostgreSQL 越来越火，就会问：是不是学 PostgreSQL 更有前途？
我的答案很简单：是，但也更难了。
以前学 PostgreSQL，可能重点是安装部署、备份恢复、流复制、vacuum、索引、执行计划、锁、参数调优。
这些东西当然还重要，而且越来越重要。Datadog 那些数字已经说明了，很多生产系统连基本超时、长事务治理和索引设计都没做好。
但只会这些，未来可能不够。
你还要理解云上 PostgreSQL 的产品形态，理解 serverless、存储计算分离、数据库分支、对象存储、AIO、逻辑复制、多活、向量索引、JSONB、AI 应用状态管理、分析型执行路径。
这不是说每个 DBA 都要变成内核开发者。
而是说，PostgreSQL 的边界变宽以后，DBA 的知识边界也会被迫变宽。过去你只看数据库实例内部就能解决一半问题；未来很多问题会同时发生在应用、连接池、云平台、对象存储、复制链路、扩展和数据库内核之间。
比如一次慢查询，可能不是单纯缺索引，而是应用 idle in transaction 拖住 vacuum，表膨胀后扫描变慢；也可能是 JSONB 存得很爽但没建 GIN；也可能是 AI 应用写入大量 embedding，HNSW 索引构建和维护成本没评估；还可能是 serverless 冷启动、连接风暴、连接池配置和数据库参数一起打架。
这些问题都不是看一眼 shared_buffers 就能解决的。
写在最后
Datadog 的报告告诉我们，PostgreSQL 还在真实生产环境里继续扩张，而且 AI 应用正在把它推到更多新场景里。
Álvaro Herrera 的演讲则提醒我们，PostgreSQL 未来十年还有很多硬骨头要啃：存储、复制、DDL、执行器、AIO、多线程、MPP、可观测性、社区协作。
再结合 Neon、Databricks、DuckDB、AWS 这些生态事件：PostgreSQL 的未来不会只写在某个版本的 release notes 里，也不会只藏在某个扩展里，而是在内核演进、云产品形态、AI 应用需求和整个数据库生态的拉扯里。
PostgreSQL 站在了几条重要趋势的交汇处。它足够老，老到经受过大量生产环境考验；它也足够新，新到还能通过扩展、内核演进和云原生架构继续长出新能力。
如果再说得尖锐一点，我觉得下一轮 PostgreSQL 红利的重点，也许会从”更多公司使用 PostgreSQL”，转向”更多产品把 PostgreSQL 当成默认数据接口和状态资源”。
谁能把 PostgreSQL 做得更轻、更近、更容易被程序调用，谁就有机会。
更轻，是 serverless、scale-to-zero、短生命周期实例；
更近，是 PGlite、本地数据库、边缘数据库、Agent 沙箱；
更容易被程序调用，是分支、回滚、同步、审计、自动诊断、自动修复。
这才像下一轮产品机会。
如果一定要排个先后，我现在更愿意押注三个方向：
第一，数据库变更验证和运行管理。因为需求已经存在，事故也已经存在，付费方也清楚。
第二，适度规模的混合负载产品。别上来就喊取代数仓，先把大量普通业务的事务、分析、检索做简单，就已经很有价值。
第三，企业上下文数据服务。这个更远，但如果 Agent 真要进入企业业务，权限、版本、来源、新鲜度这些问题迟早躲不开。
这就是 PostgreSQL 最有意思的地方。它不是一夜爆红的网红数据库，而是一个近三十年一直在打补丁、填坑、进化、被生产环境反复捶打出来的系统。
热闹是市场的，功夫还是工程的。
对于我们这些学 PostgreSQL、用 PostgreSQL、维护 PostgreSQL 的人来说，别只看见 pgvector 的热闹，也别只盯着 AI 的风口。该补的基本功还得补，该看的新方向也得看。
毕竟未来十年，PostgreSQL 大概率不会变得更简单。
但也正因为不简单，它才值得继续学。
参考资料
- Datadog: The State of Postgres in 2026
- PostgreSQL: Beta Information
- PostgreSQL: PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released
- Databricks: Databricks + Neon
- TechCrunch: Databricks to buy open source database startup Neon for $1B
- Neon: Electric is joining team Neon at Databricks
- Electric: Electric is joining Databricks
- Supabase: Supabase Series F
- Supabase: Postgres Best Practices for AI Agents
- Neon: Agent Skills in 2026
- Snowflake: Delivering the Most Enterprise-Ready Postgres, Built for the Snowflake AI Data Cloud
- AWS: AWS to acquire DuckLabs, the company behind DuckDB
- DuckLabs: DuckLabs to Join AWS, Projects to Remain Open Source
- pg_duckdb: DuckDB-powered Postgres for high performance apps and analytics
- Álvaro Herrera: The next ten years of Postgres, Postgres Conference Germany 2026
评论区按需加载，正文阅读不会被第三方服务拖慢。