1996 年 7 月 8 日，PostgreSQL 社区接过 Postgres95 留下的火种。三十年后，它已经不只是一个“开源数据库选项”，而是很多团队设计后端系统时的默认起点：应用数据库、分析型扩展、队列、全文检索、地理数据、向量检索，越来越多能力都围绕它展开。
这 30 年真正改变了什么
PostgreSQL 的故事有一个很工程化的转折点：它从 Berkeley 的研究项目，变成了由社区长期维护、持续演进的基础设施。研究项目通常证明想法，基础设施则要承受迁移、升级、备份、故障恢复、权限边界和性能退化这些日常压力。
这也是 PostgreSQL 今天重要的原因。它没有只停留在“关系型数据库”的狭窄定义里，而是逐渐变成一个可扩展的数据平台。很多团队选择它，不是因为它能解决所有问题，而是因为它能把大量普通问题解决到足够可靠：事务、索引、约束、SQL、复制、扩展机制，以及成熟的运维工具链。
默认选择的价值：少做一层技术赌博
“默认基础”这个词听起来平淡，但对工程团队很关键。数据库选型一旦进入生产环境，后续成本往往远高于初始接入成本。PostgreSQL 的优势不只是功能列表，而是它在生态里的确定性：云厂商支持、ORM 支持、迁移工具支持、监控系统支持、备份方案支持，招聘市场也更容易找到熟悉它的人。
这并不意味着所有系统都应该只用 PostgreSQL。高吞吐日志、超大规模时序写入、极低延迟 KV、复杂图遍历，都可能需要专门系统。但在产品早期和大多数业务系统里，用 PostgreSQL 作为第一块数据底座，通常可以让团队把注意力放回数据模型和业务边界，而不是过早拆分基础设施。
可以这样实践：用 Docker 跑一个可丢弃的 PostgreSQL 实验环境
下面这个例子不是来自原文的发布说明，而是一个可以直接改造的本地实践：用 Docker 启动 PostgreSQL，创建一张表，写入数据，并验证约束和查询。
运行前需要安装 Docker。端口 5432 如果已经被占用，可以把左侧端口改成 15432:5432。
docker run --name pg30-demo \
-e POSTGRES_USER=app \
-e POSTGRES_PASSWORD=secret \
-e POSTGRES_DB=appdb \
-p 5432:5432 \
-d postgres:16
sleep 3
docker exec -i pg30-demo psql -U app -d appdb <<'SQL'
CREATE TABLE IF NOT EXISTS accounts (
id BIGSERIAL PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
balance_cents BIGINT NOT NULL DEFAULT 0,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
CHECK (balance_cents >= 0)
);
INSERT INTO accounts (email, balance_cents)
VALUES
('ada@example.com', 12000),
('grace@example.com', 5000)
ON CONFLICT (email) DO UPDATE
SET balance_cents = EXCLUDED.balance_cents;
SELECT id, email, balance_cents, created_at
FROM accounts
ORDER BY id;
SQL
如果你想观察约束是否真的在保护数据，可以继续运行：
docker exec -i pg30-demo psql -U app -d appdb <<'SQL'
INSERT INTO accounts (email, balance_cents)
VALUES ('bad@example.com', -1);
SQL
这条写入会失败，因为 CHECK (balance_cents >= 0) 把非法状态挡在了数据库层。这个小例子体现了 PostgreSQL 很值得依赖的一点：不要把所有正确性都压在应用代码里。能用唯一约束、外键、检查约束、事务表达的规则，就让数据库参与防守。
清理环境：
docker rm -f pg30-demo
采用建议：把 PostgreSQL 当成平台，而不是只当存储
如果团队正在重新审视数据架构，可以用下面的清单评估 PostgreSQL 是否适合作为默认底座：
- 数据是否需要强一致事务、约束和可解释的 SQL 查询？适合优先考虑 PostgreSQL。
- 团队是否希望减少早期组件数量？PostgreSQL 可以先承担主库、搜索、简单分析、任务状态存储等多种职责。
- 是否已经遇到单机写入、冷热分层、跨地域延迟等明确瓶颈？这时需要更严肃地评估分片、专用数据库或云托管能力。
- 运维能力是否跟得上？备份恢复、连接池、迁移流程、慢查询分析和版本升级，比“能启动数据库”更重要。
三十岁的 PostgreSQL 并不只是一个长寿项目。它说明了一件更朴素的事：可靠的软件基础设施不是靠一次发布定型的，而是靠社区、用户、工具和生产事故长期打磨出来的。对开发者来说，最好的纪念方式不是怀旧，而是在下一次建表、加索引、写迁移脚本时，把数据边界设计得更清楚一点。