由 John Doe 九月 3, 2026
Datadog 对许多使用其 APM 和监控代理的客户数据进行分析显示，Postgres 的采用率持续上升，22% 的表有一个（很少建索引的！）JSONB 列，pgvector 是增长最快的非内置扩展，还有更多信息。
目录
PostgreSQL（简称 Postgres）是现代数据栈的基石。2026 年，它正逐渐成为新应用的默认记录系统，也是 AI 开发的首选数据库。“用 Postgres 承载一切” 正日益成为运维现实 —— 越来越多的 Web 与 SaaS 工作负载、多租户微服务架构、分析流水线以及 AI 应用，都依托 Postgres 构建。
Postgres 是开源项目，具备高度可扩展性，其普及离不开活跃社区对技术演进的推动。通过分析 Datadog 客户数万个生产数据库的遥测数据，我们探究了当前企业对 Postgres 的使用方式与未来发展方向，研究也参考了 Postgres 社区提出的问题。研究结果表明，Postgres 的应用规模持续增长，AI 热潮更是进一步推动了这一趋势。同时我们也发现，Postgres 实例存在大量普遍的性能优化空间 —— 包括被忽视的应用侧优化、超时配置以及索引类型优化，这些改进有助于降低系统延迟、提升整体稳定性。
事实 1：大多数企业在生产环境运行 Postgres，采用率持续攀升
Postgres 是生产环境中应用最广泛的事务型数据库，且领先优势还在不断扩大。通过追踪应用数据库连接情况我们发现，2024 年 7 月至 2026 年 5 月间，拥有至少一个生产级 Postgres 实例的企业占比从 54% 升至 60%。
Postgres 在所有事务型数据库中保持显著领先地位。它与最接近的竞品 MySQL、MongoDB 均保持稳定增长，这打破了长期以来 “NoSQL 将取代关系型数据库承载现代工作负载” 的猜测。与之相反，关系型数据库正蓬勃发展，而 Postgres 正是其中的引领者。
Postgres 位居事务型数据库榜首，领先优势持续扩大
Postgres 的增长主要由云部署驱动。截至 2026 年 5 月，在生产环境使用 Postgres 的企业中，65% 拥有至少一个云托管实例，而 2025 年 6 月这一比例为 62%。与此同时，拥有至少一个自托管实例的企业占比从 47.6% 降至 44.6%。
托管型 Postgres 增速超过自托管，但两种部署方式仍被广泛采用
云托管 Postgres 日益普及，很大程度上反映了行业向云原生工作负载转型的大趋势：企业依托托管服务控制成本与复杂度，借助 AI 实现更高体量、更快速度的业务构建。
事实 2：Postgres 跨语言应用持续增长，Python 位居首位
Postgres 在设计上具备语言无关性，但其客户端库、ORM 以及迁移工具构成的生态，折射出它在更广泛软件领域中的定位。我们的数据显示，最显著的变化是 Python 和 Node.js 崛起为生产环境中访问 Postgres 最主流的语言生态，Python 领跑，Node.js 紧随其后，双双超越 Java。
截至 2026 年 5 月，约 20% 的企业使用 Python 访问 Postgres，17% 的企业使用 Node.js。过去两年间，二者的 Postgres 应用规模均实现两位数增长，Python 涨幅 33%，Node.js 涨幅 20%。
Python 登顶榜首，反映出它近年来在后端开发、数据工程和数据科学领域的全面扩张。未来几年，它相对于 Java 的领先优势还将继续扩大 —— 尤其是 AI 编码助手在搭建新应用时绝大多数默认选用 Postgres，这将进一步加速 Python、Node.js 等现代语言的采用。
Python 位列 Postgres 客户端语言榜首
事实 3：pgvector 是增长最快的非内置 Postgres 扩展
Postgres 的持久生命力，很大程度上归功于其可扩展性。它没有试图开箱即用地满足所有场景，而是提供了各类扩展接口（自定义数据类型、索引访问方法、过程语言等），开发者无需分支修改数据库内核就能扩展新能力。单个 Postgres 实例可以根据团队安装的扩展承担全新的角色，这种灵活性得到了广泛应用：约半数生产级 Postgres 实例，都运行了至少一个非内核内置的扩展。这些扩展是观察团队实际使用 Postgres 方式的重要指标。
其中，pg_cron以 17% 的实例占比遥遥领先，它提供数据库内任务调度能力，支持从运维清理任务到应用业务逻辑的各类场景。在领域专属扩展中，PostGIS应用最广，8% 的生产级 Postgres 实例用它支持地理空间查询。其余进入前十的扩展大多偏向运维方向：用于审计日志的pgaudit、用于表与分区管理的pg_repack和pg_partman、用于索引实验的hypopg、用于逻辑复制的pglogical，以及aws_commons、pgaadauth（Azure）等云厂商专属工具扩展。
与此同时，增长最快的非内置扩展是pgvector，它能将 Postgres 转变为可支撑 AI 应用的向量数据库。2025 年 12 月至 2026 年 5 月间，pgvector 的使用量增长了 24%。
pgvector 是增长最快的非内置 Postgres 扩展
虽然最主流的非内置扩展仍反映了任务调度、地理空间查询等长期存在的需求，但 pgvector 位居增速榜首表明：Postgres 的可扩展性正被用于将 AI 工作负载从应用层下沉到数据库内部。这再次证明，Postgres 在现代应用中的角色正在不断拓展，而非收窄。
随着 Postgres 在现代技术栈中的地位愈发重要，其性能的影响也越来越大。但正如我们接下来将看到的，最大的优化空间可能并不在大多数运维人员关注的地方。
事实 4：Postgres 最大的瓶颈不在数据库本身，而在应用端
Postgres 性能调优通常聚焦于查询效率，但延迟的一大来源是后端在两次查询之间等待客户端的时间。事实上，通过汇总等待事件采样数据我们发现，Postgres 后端进程有 56% 的时间处于事务中空闲状态。在这种数据库侧无操作的状态下，客户端逻辑保持事务开启却不发送任何查询请求，这会全面降低 Postgres 性能：拖慢查询速度、占满连接池、阻碍自动真空清理死元组进而导致表膨胀。
后端总耗时中，仅有 37% 真正消耗在 Postgres 内部，用于执行 I/O、查询执行、锁获取等任务。客户端侧延迟也在查询执行时间中占比显著：处于活跃执行状态的查询有 8% 的时间消耗在ClientRead状态 —— 换句话说，就是在等待应用侧响应。
大多数 Postgres 后端时间都消耗在空闲状态
设置idle_in_transaction_session_timeout（事务中空闲会话超时）可以改善这种失衡，它能限制单个事务在不执行有效操作的情况下，持有锁、连接槽位和其他资源的时长。当客户端逻辑（比如慢速 API 调用、暂停的后台任务、无响应的用户会话）导致事务长期开启时，超时机制会强制释放资源，避免问题恶化引发大范围资源争用。
总体而言，我们的研究将应用层与网络层推向了性能优化的聚光灯下。结论很明确：对于绝大多数 Postgres 工作负载，性能调优至少要同等关注应用、网络和连接池层面，而不仅仅是数据库本身。
事实 5：多数 Postgres 实例只差一条坏查询就会引发故障
Postgres 的超时配置是至关重要、却远未被充分利用的可靠性保障机制。长时间运行的查询、事务和会话会推高系统开销、消耗关键资源，甚至拖垮整个实例。
这些严重故障模式其实很容易预防：只需设置statement_timeout（语句超时）、idle_in_transaction_session_timeout（事务中空闲会话超时）和idle_session_timeout（空闲会话超时）即可 —— 可在服务器全局设置以实现整体防护，也可在会话级别设置，以适配批量任务等需要长时查询的场景。
但我们的研究发现，大多数实例都缺少这些基础防护机制，这意味着任何一条异常查询、空闲连接或开启的事务，都可能对性能和开销造成失控的影响：
- 仅有 15% 的生产实例开启了
statement_timeout，也就是说 85% 的实例中，坏查询可以无限期运行，消耗 CPU 与 I/O 资源，甚至阻塞其他查询。 - 仅 9% 的实例开启了
idle_session_timeout，该参数可避免空闲连接累积并耗尽连接池。 - 15% 的实例关闭了
idle_in_transaction_session_timeout，导致开启的事务长期持有锁、阻塞自动真空、拖慢查询性能。
多数 Postgres 实例缺少超时防护机制
更值得注意的是，77% 的实例将max_connections（最大连接数）设为 200 以上，同时statement_timeout设为 0。这些实例处于高风险状态：高最大连接数上限配合长时查询，会引发并发量激增，而很少有实例能够承受这种冲击。
按云厂商拆分idle_in_transaction_session_timeout的使用情况，可以看到更细节的差异：自托管实例中仅有 57% 开启了事务中空闲超时，而 AWS 上这一比例为 99%（默认开启），Azure 为 33%，谷歌云仅为 11%。
这种差异反映了托管基础设施使用模式的普遍规律：托管数据库服务的使用者往往依赖厂商的默认配置，很少主动调整；而自托管数据库的团队会更有针对性地配置这些参数。但使用 AWS 托管 Postgres 的用户也不应默认配置就万事大吉：AWS 将idle_in_transaction_session_timeout默认设为 24 小时，而大多数工作负载更适合根据自身场景设置更短的超时时间。设置更短的超时不会带来明显的性能损耗，因为这些都是轻量级的服务器端计时器，不会给查询执行增加额外开销。
考虑到 Postgres 工作负载有 56% 的时间处于开启事务的空闲状态，普遍缺失合理配置的idle_in_transaction_session_timeout，意味着降低故障模式风险存在巨大的优化空间。
事实 6：索引普及度很高，但高效索引非常少见
索引是提升数据库查询性能最重要的工具，Postgres 支持极其丰富的索引类型 ——B-tree、GIN、GiST、BRIN、hash—— 分别针对不同的访问模式优化。它还支持覆盖索引、部分索引、表达式索引等高级索引技术，能针对特定访问模式大幅提升查询性能。
我们的研究发现，尽管生产实例中超过 99% 的表都使用了某种形式的索引，但 Postgres 所能实现的精细化索引能力，与社区生产环境的实际使用情况之间存在巨大差距。值得注意的是，生产环境中绝大多数表只使用了一种索引类型。不出所料，B-tree 索引是最通用的索引类型，最适配支撑大多数应用工作负载的等值查询和范围查询，因此被广泛使用。
B-tree 在 Postgres 索引使用中占主导地位
相比之下，覆盖索引和部分索引这两种强大的 Postgres 优化工具几乎完全被忽视。它们分别仅占所有索引的 0.3% 和 1.8%，尽管它们能带来显著的性能收益，比如实现仅索引扫描（Index-Only Scan）以及精准缩小查询范围。
继 B-tree 之后，GIN 索引是明确的第二选择，它专门针对全文搜索和 JSONB 查询优化：超过 62.1% 的企业使用 GIN 索引，不过仅有 12.6% 的表建有 GIN 索引。它们的流行反映出 Postgres 作为生产环境中文本搜索和 JSONB 工作负载解决方案的地位，而这一角色通常被认为属于 Elasticsearch 等专用方案。
事实上，JSONB 的使用非常普遍：22% 的表包含至少一个 JSONB 列。然而，这些 JSONB 列中仅有 2% 建立了索引，说明团队在 Postgres 中存储半结构化数据，却没有为高效访问建立索引。
BRIN 索引的普及度不高：9.7% 的企业使用它，但这些企业的使用范围很广，覆盖了 4.8% 的表。最后，向量索引（HNSW 和 IVFFlat）仍然少见：不到 6% 的企业、不足 1% 的表使用向量索引，这与事实 3 中记录的 pgvector 扩展采用率不高的结论一致。
事实 7：Postgres 升级频率比你想象的更高
数据库升级向来被认为是耗时费力、风险极高的操作，团队都会尽可能推迟。尤其是 Postgres 大版本升级，要么需要停机，要么需要围绕逻辑复制做周密规划。与此同时，了解社区实际的升级频率，对于任何需要保持兼容性的工具、扩展或文档开发者来说都至关重要。我们的研究表明，企业升级大版本的速度远快于传统认知。
截至 2026 年 5 月，超过 94% 的 Postgres 实例运行 14 到 18 版本，约半数运行 15 或 16 版本。企业的 Postgres 大版本升级中位数周期为 6.9 个月。2024 年 7 月至 2026 年 5 月间，39% 使用 Postgres 的企业完成了至少一次大版本升级，还有相当一部分企业升级速度更快：17% 的企业至少有一次在新版本发布首月内就完成升级，34% 的企业至少有一次在发布三个月内完成升级。
半数 Postgres 实例现已运行 16 及以上版本
这样的升级节奏部分得益于托管数据库服务：它们简化了大版本升级流程、降低了运维风险，并且会停止对旧版本的支持。托管实例采用 17 及以上版本的比例是自托管实例的两倍。总体而言，10% 的企业平均升级间隔长达 17 个月或更久，这使得它们运行的版本最终会失去社区支持，并累积未修复的安全漏洞（CVE）。
事实 8：Postgres 生态仍缺乏主流的水平扩展方案
分区（Partitioning）是 Postgres 内置的解决方案，它将一张逻辑表拆分为多个物理分段，用于管理超出最优查询性能规模的大表。当数据量或写入吞吐量超过单台机器的容量时，分片（Sharding）—— 将数据分布到多台机器上 —— 就是下一步的解决方案。Postgres 原生不支持分片，因此需要借助扩展或应用层逻辑实现。
我们发现分区是一种常见策略，约 32% 的企业都在使用 —— 不过仅在 9% 的数据库和 0.4% 的表中使用，说明采用该方案的企业使用得比较克制。相比之下，专用分片解决方案极其少见：最流行的 Citus 也仅被 0.32% 的企业使用。
分区应用广泛，但数据库级分片仍属罕见
这些发现表明，企业可能在采用其他策略来实现大型工作负载的水平扩展，比如应用层分片逻辑，或是将单体数据库拆分为面向特定领域的工作负载。
展望
Postgres 是现代应用、AI 工作负载和分析流水线的首选数据库，随着 AI 驱动的开发加速 Python 和 Node.js 生态的采用，它的应用范围还在持续扩大。我们的分析显示，越来越多使用 Postgres 的企业，在性能和可靠性方面都有广泛的提升空间。
令人意外的是，其中一些最大的优化机会其实是基础运维层面的小事：修正应用侧的事务行为、落地超时配置。此外，尽管我们预料到 B-tree 索引会无处不在，但团队对 Postgres 强大索引工具集的忽视程度仍然令人震惊 —— 而索引能力正是 Postgres 区别于其他数据库方案的核心优势之一。
我们的数据清晰表明，很多团队只是把 Postgres 当作一个简单的托管服务来使用，也因此暴露在本可避免的性能与可靠性故障风险中。随着 Postgres 变得愈发普及，将其优化作为一项端到端的系统工程来对待，必将带来越来越大的收益。我们将在后续的系列文章中深入探讨 Postgres 的优化机会。
研究方法
除非另有说明，所有结论均基于 2026 年 5 月 1 日至 5 月 16 日期间收集的匿名化数据。
事实 1
数据库采用率方面，我们分析了 2024 年 7 月至 2026 年 5 月 16 日的 APM 服务依赖数据。我们根据检测到的服务语言及其对应的数据库驱动和客户端库，识别出各类事务型数据库技术。采用率以 “至少有一个服务使用该数据库技术的企业占比” 来衡量。
为分析 Postgres 的部署方式，我们研究了 2025 年 6 月至 2026 年 5 月的数据库实例元数据。我们通过内部基础设施分类模型得出的云厂商归属数据，对企业进行分类。
事实 2
为衡量不同应用技术栈对 Postgres 的访问情况，我们分析了 2024 年 4 月至 2026 年 5 月 16 日的 APM 服务依赖数据。我们根据检测到的服务语言及其已知的 Postgres 驱动和客户端库，将服务归类到不同的技术生态（Python、Java/JVM、Node.js、Go、PHP、Ruby）。该分类反映的是应用层的使用模式，而非基础设施部署情况。
事实 3
为分析生产环境中 Postgres 扩展的使用情况，我们研究了 2025 年 12 月至 2026 年 5 月 16 日 DBM 元数据指标中的扩展安装数据。我们根据 PostgreSQL 官方文档，将扩展分为内置（标准 PostgreSQL 发行版包含）和非内置两类。
事实 4
为分析数据库瓶颈，我们汇总了数据库监控（DBM）采集的 Postgres 后端活动采样数据。我们过滤了数据集，仅包含常见的状态（活跃与事务中空闲）。
在该分析中，我们将数据集限定为每小时前 10 分钟的采样数据；要求等待事件非空，且仅包含等待时长为正的查询。
事实 5
为评估 Postgres 实例对失控查询与连接的防护能力，我们分析了关键超时参数的配置数据，包括statement_timeout、lock_timeout、idle_in_transaction_session_timeout、idle_session_timeout和deadlock_timeout。在统一时间单位后，我们识别出这些参数设为 0 的配置。该分析仅针对美国 1 区数据，云厂商归属由内部基础设施分类模型得出。
事实 6
为了解索引实践情况，我们分析了 Postgres 表与模式元数据，包括列、索引、外键和分区数量。对于每张表，我们采用采样窗口内观测到的最大列数和索引数，避免采样更频繁的表被过度代表。我们排除了系统模式（如pg_catalog和information_schema）和默认主键索引（如pk_%、%_pkey），聚焦于用户自定义的索引策略。无索引的表也纳入统计。
由于一张表可以使用多种索引方式，因此各项占比并非互斥。当元数据未捕获到索引访问方法时，默认判定为 B-tree 索引 —— 这是 Postgres 创建索引时未指定方法的默认类型。
我们还识别了高级索引模式，包括覆盖索引（定义为包含INCLUDE子句）和部分索引（定义为包含WHERE条件）。最后，我们分析了jsonb列的存在情况，以了解团队如何使用 Postgres 存储半结构化数据。
事实 7
为分析 Postgres 版本采用情况与大版本升级速率，我们研究了 2024 年 7 月至 2026 年 5 月间通过 DBM 采集的 Postgres 版本元数据。
为衡量升级节奏，我们识别了每个企业内每个 Postgres 大版本的首次观测日期，当后续出现更新版本时即判定为发生了升级。随后我们计算了每个企业连续两次大版本升级之间的间隔时间。
我们通过内部云厂商归属元数据，将实例分为托管型与自托管型。
事实 8
为了解团队如何扩展 Postgres 数据集，我们同时分析了表级元数据和扩展使用情况。如果一张表报告有至少一个分区，则被认定为使用了分区。我们通过citus扩展的存在来识别分片部署。该分析仅针对美国 1 区数据。