PostgreSQL：从社区提交到云上基石，一个数据库的三十年进化

2026-05-14 27 预计阅读时间：1 分钟
来源：azure.microsoft.com AI 摘要 原文链接

免责声明：本文为 AI 摘要整理，建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件，不作为官方说明。

预计阅读时间：10 分钟

PostgreSQL 不再只是"那个开源数据库"。从初创团队的第一行建表语句，到全球最大规模的生产系统，它已经成了现代应用的基础设施层。微软 Azure 博客最近的一篇文章梳理了这条路径——从一次次社区 commit，到云平台上的托管服务，PostgreSQL 的长寿不是运气，而是几十年工程纪律、社区协作和对"正确性与可扩展性"的偏执追求的结果。

正确性优先：为什么生产系统敢把命交给它

PostgreSQL 的工程哲学有一条底线：数据不能错。这不是口号，而是从 MVCC（多版本并发控制）到 WAL（预写日志）的每一层设计里都能看见的选择。

MVCC 让读写不互锁，WAL 保证崩溃恢复不丢数据。这两件事听起来基础，但做到极致的数据库并不多。很多系统在性能和正确性之间做折中，PostgreSQL 的倾向很明确——先保证正确，再在正确的前提下优化性能。

这种偏执带来了一个副作用：信任。金融、医疗、电信这些对数据一致性要求苛刻的行业，选 PostgreSQL 不是因为它快，而是因为它"不犯错"。这种信任积累了几十年，不是营销能替代的。

可扩展性：从"数据库"变成"平台"

PostgreSQL 另一个被低估的能力是扩展机制。它不只是存数据，而是允许你把逻辑下沉到数据库内部。

扩展（Extension）是核心机制。PostGIS 让它变成地理信息系统，pg_trgm 让它做模糊搜索，pg_stat_statements 让它变成自己的性能监控工具。这些不是外部工具在"用"数据库，而是逻辑直接嵌入数据库的执行引擎。

更激进的是自定义类型和自定义索引。你可以定义一种新的数据类型，配一种专门的索引访问方法，让 PostgreSQL 用你定义的方式存储和检索。这是大多数数据库根本不开放的接口。

下面是一个实际可用的扩展组合示例——用 pg_trgm 做中文模糊搜索，用 pg_stat_statements 定位慢查询：

-- 1. 启用扩展（需要超级用户权限）
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- 2. 创建测试表并插入数据
CREATE TABLE products (
    id    SERIAL PRIMARY KEY,
    name  TEXT NOT NULL,
    desc  TEXT
);

INSERT INTO products (name, desc) VALUES
    ('无线蓝牙耳机', '高音质低延迟'),
    ('蓝牙音箱便携版', '户外防水'),
    ('有线降噪耳机', '主动降噪'),
    ('无线充电器', '15W 快充');

-- 3. 在 name 列上建 trigram 索引，支持模糊匹配
CREATE INDEX idx_products_name_trgm ON products USING gin (name gin_trgm_ops);

-- 4. 模糊搜索：找所有含"蓝牙"的商品（不需要精确匹配）
SELECT id, name
FROM products
WHERE name % '蓝牙'
ORDER BY similarity(name, '蓝牙') DESC;

-- 5. 查看最近执行的慢查询（按总执行时间排序）
SELECT query,
       calls,
       total_exec_time AS total_ms,
       mean_exec_time  AS avg_ms,
       rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

运行前注意：pg_stat_statements 需要在 postgresql.conf 中配置 shared_preload_libraries = 'pg_stat_statements' 并重启 PostgreSQL。pg_trgm 对中文的效果取决于分词粒度，生产环境建议配合 zhparser 等中文分词扩展使用。

云上的 PostgreSQL：从自建到托管

当 PostgreSQL 从单机走向云，问题变了。不再只是"能不能跑"，而是"能不能在规模、可靠性、运维成本之间找到平衡"。

Azure、AWS、GCP 都提供了 PostgreSQL 托管服务。核心价值不是"帮你装了个数据库"，而是把备份、高可用、补丁升级、监控这些运维负担变成平台责任。对于团队来说，这意味着一个选择：你的工程精力应该花在理解业务数据模型上，还是花在管理 pg_basebackup 的 cron 任务上？

以 Azure Database for PostgreSQL Flexible Server 为例，下面是一个用 Azure CLI 快速创建托管 PostgreSQL 实例的命令：

# 1. 设置变量（替换为你的值）
RG_NAME="pg-demo-rg"
SERVER_NAME="pg-demo-server"
LOCATION="eastasia"
ADMIN_USER="pgadmin"
ADMIN_PASS="ChangeMe123!"
SKU="Standard_D2s_v3"
STORAGE_SIZE=32          # GB
PG_VERSION="16"

# 2. 创建资源组
az group create --name $RG_NAME --location $LOCATION

# 3. 创建 Flexible Server（自动配置高可用可选）
az postgres flexible-server create \
    --resource-group $RG_NAME \
    --name $SERVER_NAME \
    --location $LOCATION \
    --admin-user $ADMIN_USER \
    --admin-password $ADMIN_PASS \
    --sku-name $SKU \
    --storage-size $STORAGE_SIZE \
    --version $PG_VERSION \
    --public-access 0.0.0.0

# 4. 获取连接信息
az postgres flexible-server show \
    --resource-group $RG_NAME \
    --name $SERVER_NAME \
    --query "fullyQualifiedDomainName" -o tsv

# 输出类似：pg-demo-server.postgres.database.azure.com
# 用 psql 连接：
# psql -h pg-demo-server.postgres.database.azure.com -U pgadmin -d postgres

安全提醒：--public-access 0.0.0.0 仅用于快速演示。生产环境应限制为特定 IP 范围或使用 VNet 隁私接入。密码也应从环境变量或 Key Vault 读取，不要硬编码在脚本中。

托管服务还带来一个隐性好处：版本升级不再是噩梦。PostgreSQL 大版本升级（比如 15→16）在自建环境下需要规划 pg_upgrade、停机窗口、回滚方案。托管服务通常提供一键升级或最小停机升级，把这件事的工程复杂度从你的团队转移到了平台团队。

选型时的几个现实考量

PostgreSQL 强，但不是万能钥匙。几个需要想清楚的问题：

  • 写入密集场景：PostgreSQL 的单写者架构在高并发写入下会遇到瓶颈。如果你的写入 QPS 远超读 QPS，需要评估分区、连接池（pgbouncer）或是否该考虑其他架构。
  • 扩展生态的维护成本：Extension 让 PostgreSQL 变强，但每个扩展都是额外的依赖。版本升级时扩展兼容性是常见卡点，升级前务必检查 pg_extension 列表和兼容性矩阵。
  • 托管 vs 自建：托管服务省运维，但牺牲了部分控制权。自定义扩展、特定配置参数、超时设置在托管环境可能受限。如果你的业务深度依赖某个冷门扩展，先确认托管服务是否支持。
  • 连接模型：PostgreSQL 是进程模型，每个连接一个进程。高连接数场景下必须用连接池，否则内存和调度开销会吃掉性能。这是架构设计阶段就要决定的事，不是事后补救。

一个简单的连接池配置示例（pgbouncer）：

; /etc/pgbouncer/pgbouncer.ini

[databases]
postgres = host=127.0.0.1 port=5432 dbname=postgres

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction        ; 事务结束即释放连接，适合高并发短事务
max_client_conn = 1000
default_pool_size = 20
reserve_pool_size = 5
reserve_pool_timeout = 3
server_idle_timeout = 300

# 启动 pgbouncer
pgbouncer -d /etc/pgbouncer/pgbouncer.ini

# 客户端连接池端口而非直连 PostgreSQL
psql -h 127.0.0.1 -p 6432 -U pgadmin -d postgres

pool_mode = transaction 是最常用的模式：事务提交后连接归还池中，同一客户端的下一个事务可能拿到不同后端连接。如果你的业务依赖会话级状态（如临时表、SET 变量），需要用 session 模式，但池化效果会大幅降低。

结语

PostgreSQL 从社区的一次次 commit 走到云上的托管服务，靠的不是某个技术突破，而是持续三十年的工程习惯：先做对，再做快；先可扩展，再谈规模。这种习惯让它在每个时代都能被重新发现——从 Web 2.0 的 LAMP 替代品，到今天云原生架构的默认选择。

如果你的团队正在选数据库，或者正在从自建 PostgreSQL 迁移到托管服务，建议做一件事：先列出你用到的所有扩展和所有非默认配置参数。这张清单决定了你能多顺利地走向云，也决定了你在遇到瓶颈时有多少调整空间。

# Azure # PostgreSQL # 云平台

相关推荐