如果你是一名数据库工程师、架构师，或者正在为技术选型而纠结，那么最近几年一定被一个现象级问题反复拷问：为什么几乎所有国产数据库，都绕不开 PostgreSQL？

从华为的 openGauss、GaussDB，到阿里的 PolarDB for PostgreSQL，再到腾讯的 TDSQL-C PostgreSQL 版，以及众多新兴的国产数据库产品，它们的底层技术栈或兼容协议，都指向了同一个名字：PostgreSQL。这不禁让人产生疑问：我们引以为傲的“自主可控”数据库，究竟是站在巨人肩膀上的创新，还是仅仅换了个名字的“套壳”？

这个问题背后，远不止是技术路线的争论，它折射出的是中国基础软件产业在“拿来主义”与“自主创新”之间的艰难平衡。今天，我们就从 PostgreSQL 这个“巨人”出发，深入探讨一下，在它诞生近三十年后，中国数据库产业究竟走到了哪一步，以及我们该如何看待“基于开源”与“自主可控”之间的关系。

1. 从“三国演义”到“一超多强”：PostgreSQL 的崛起之路

要理解中国数据库的现状，必须先看懂全球数据库的格局。长期以来，关系型数据库领域上演着一场“三国演义”：Oracle、MySQL、PostgreSQL 三足鼎立。然而，根据 StackOverflow 2023 年的开发者调查报告，这场戏的剧本已经改写。

PostgreSQL 在 流行度 （45.6%）、 喜爱度 （约70%）、 需求度 （42.3%）三项核心指标上全面领先，首次在总使用率上超越 MySQL（41.1%），成为事实上的“全能冠军”。尤其是在专业开发者群体中，PostgreSQL 的使用率已达 MySQL 的 1.2 倍。一个更形象的比喻是： PostgreSQL 正在成为数据库界的 Linux 。

为什么是 PostgreSQL？我们可以借用网络材料中的一个精辟总结：“Oracle 有才无德，MySQL 才浅德薄，PGSQL 德才兼备”。

• Oracle（有才无德） ：功能强大、稳定可靠，是商业数据库的标杆。但其高昂的授权费用（一个CPU核年费可达十几万）和激进的商业策略，让众多企业望而却步，催生了轰轰烈烈的“去IOE”运动。其“才”毋庸置疑，但其“德”（商业友好性）备受诟病。
• MySQL（才浅德薄） ：凭借 LAMP 栈的东风和互联网早期的“糙猛快”需求，一度成为最流行的开源数据库。但其在事务一致性、复杂查询、功能完整性上长期被诟病。被 Oracle 收购后，其开源协议的“纯洁性”和未来发展也蒙上阴影，可谓“才”有不足，“德”受质疑。
• PostgreSQL（德才兼备） ：
  • 德在开源 ：采用宽松的 PostgreSQL License（类似 BSD），允许自由使用、修改和分发，甚至用于商业闭源产品。这为二次开发和技术演进提供了最肥沃的土壤。
  • 才在先进 ：它不仅仅是一个 OLTP 数据库。通过强大的扩展系统（如 PostGIS、TimescaleDB、Citus、pgvector），它已经演变成一个覆盖 时序、空间、向量、图、文档、流处理 的“多模数据库”平台。其 SQL 标准的遵循度和功能完整性，是最接近 Oracle 的开源数据库。

正是这种“德才兼备”的特质，让 PostgreSQL 在开源浪潮和技术演进的交汇点上，成为了那个“唯一能真正威胁到 Oracle 的数据库”，也成为了全球开发者用脚投票的结果。

2. “PG系”国产数据库：是“套壳”还是“必然选择”？

理解了 PostgreSQL 的强势地位，再来看国产数据库的“PG依赖症”，就变得清晰起来。根据行业报告，有超过三分之一的所谓“国产数据库”直接基于 PostgreSQL 进行二次开发。这背后是多重因素共同作用的结果：

1. 技术门槛与后发劣势 ：从头研发一个成熟、稳定、功能完备的数据库内核，需要巨大的时间、人力和资金投入，且失败风险极高。数据库是典型的“硬核”基础软件，其复杂性体现在事务处理、查询优化、存储引擎、高可用等每一个细节。站在 PostgreSQL 这个经过近30年全球顶尖开发者锤炼的巨人肩膀上，是规避风险、快速追赶的最理性选择。

2. 生态兼容性的现实考量 ：数据库的价值一半在软件，一半在生态。一个没有应用、没有工具链、没有开发者社区的数据库是毫无竞争力的。PostgreSQL 拥有庞大的生态：无数的客户端驱动、管理工具（如 pgAdmin, DBeaver）、监控方案、以及海量的既有应用。基于 PostgreSQL 开发，可以天然继承整个 PG 生态，极大降低了用户的迁移成本和开发者的学习成本。这对于追求“平滑替代”Oracle/MySQL 的国产数据库来说，是致命的吸引力。

3. 开源协议的“馈赠” ：PostgreSQL License 的极度宽松是关键。它允许企业几乎无限制地使用、修改和分发代码，甚至可以闭源商业化，而无需像 GPL 协议那样强制开源修改后的代码。这为商业公司基于 PG 打造自有品牌数据库提供了完美的法律基础。相比之下，基于 MySQL（GPL）进行深度闭源改造则会面临复杂的协议风险。

4. 功能先进性的高起点 ：如前所述，PostgreSQL 本身就是一个功能极其强大的“多模”平台。国产数据库厂商可以在其基础上，针对特定场景（如金融级高可用、分布式、HTAP、AI向量检索）进行深度优化和增强，快速推出有竞争力的产品，而不需要从零开始实现所有基础功能。

因此，从商业和技术角度看，基于 PostgreSQL 进行创新，并非简单的“套壳”，而是一种 基于成熟开源内核的“发行版”模式 。这类似于基于 Linux 内核打造 Red Hat Enterprise Linux、Ubuntu、CentOS。你能说 Ubuntu 是 Linux 的“套壳”吗？显然不能。关键在于，你在内核之上贡献了什么独特的价值。

3. 超越“套壳”：国产数据库的差异化之路

那么，基于 PostgreSQL 的国产数据库，如何证明自己不是“换皮”，而是真正的创新？关键在于看它们在 PostgreSQL 内核之上，解决了哪些 PostgreSQL 社区版本身不擅长或没有解决的问题。主要集中在以下几个层面：

3.1 分布式与云原生架构

这是国产数据库发力的主战场。原生 PostgreSQL 是单机架构，虽然可以通过 Citus 等扩展实现分片，但并非原生分布式。

• PolarDB for PostgreSQL ：阿里云基于共享存储（Storage）和计算存储分离架构，实现了“一写多读”的云原生数据库，计算节点可快速弹性扩缩容，存储容量近乎无限，并保持对 PostgreSQL 的完全兼容。
• TDSQL-C（PostgreSQL版） ：腾讯云类似，同样采用计算、存储、日志分离的架构，实现秒级扩缩容和快速故障恢复。
• openGauss ：华为开源的单机数据库，虽然内核源自 PostgreSQL，但进行了大量的深度优化，特别是在 ARM 架构、线程化模型、安全特性等方面，并围绕其构建了分布式版本 GaussDB。

这些产品的核心价值，是将 PostgreSQL 强大的单机能力与云计算的弹性、分布式的高可用与扩展性结合起来。

3.2 金融级高可用与容灾

对于银行、证券等核心系统，RPO（恢复点目标）=0、RTO（恢复时间目标）< 30秒是硬性要求。

• 基于共识协议的高可用 ：许多国产数据库集成了 Raft、Paxos 等共识算法，实现自动选主、数据强一致、故障秒级切换，远超 PostgreSQL 原生基于流复制和 pg_rewind 的方案。
• 同城双活/异地多活 ：在架构层面设计数据同步和流量调度策略，实现机房级甚至城市级的故障无损切换。这需要在内核、复制、代理等各个层面进行深度定制。

3.3 性能优化与硬件协同

• ARM 架构优化 ：随着国产化替代推进，对 ARM 服务器（如鲲鹏）的深度优化成为关键。包括指令集优化、NUMA 感知的内存管理、与昇腾 AI 芯片的协同等。
• 存储引擎创新 ：虽然仍多基于堆表，但有些产品开始尝试集成或自研新的存储引擎，如列存引擎用于 AP 场景，或对 ZHeap、ZEDB 等下一代存储引擎的探索。
• 查询优化器增强 ：针对复杂查询、多表关联、分布式查询计划进行优化，甚至引入 AI 进行代价估算。

3.4 安全与合规特性

为满足国内等保、密评以及金融行业监管要求，增加了诸多安全特性：

• 全密态计算
• 动态数据脱敏
• 更加细粒度的权限控制和审计
• 国密算法支持

3.5 运维与可观测性

提供企业级图形化管理平台，集成监控、告警、备份恢复、SQL 审核、慢查询分析、容量规划等一站式能力，降低运维门槛。例如 Pigsty 这样的开源项目，就是旨在提供开箱即用的 PostgreSQL 发行版和 RDS 替代。

一个简单的判断标准 ：如果一个“国产数据库”只是改了改配置文件名、换了连接端口、重新打了个安装包，那无疑是“套壳”。但如果它提供了 原生 PostgreSQL 不具备的、且对业务有核心价值的分布式能力、云原生架构、更强的 SLA 保障或独特的硬件优化 ，那么它就是在做有价值的“发行版”工作。

4. 实操对比：从连接到体验“PG系”数据库

理论说了很多，我们通过一个简单的连接示例，来感受一下“PG系”数据库的兼容性与差异。

场景 ：使用 Python 的 psycopg2 驱动，连接不同的 PostgreSQL 兼容数据库，执行一个简单的查询。

4.1 连接原生 PostgreSQL

假设我们有一个本地安装的 PostgreSQL 14。

# 文件：connect_pg.py
import psycopg2
from psycopg2 import sql

# 连接参数
conn_params = {
    "host": "localhost",
    "port": 5432,
    "database": "postgres",
    "user": "postgres",
    "password": "your_password"
}

try:
    # 建立连接
    conn = psycopg2.connect(**conn_params)
    cursor = conn.cursor()
    
    # 执行查询
    cursor.execute("SELECT version();")
    version = cursor.fetchone()
    print(f"PostgreSQL 版本: {version[0]}")
    
    # 创建一个测试表并插入数据
    cursor.execute("""
        DROP TABLE IF EXISTS test_table;
        CREATE TABLE test_table (id SERIAL PRIMARY KEY, name VARCHAR(50), value INT);
        INSERT INTO test_table (name, value) VALUES ('test', 100);
    """)
    conn.commit()
    
    # 查询数据
    cursor.execute("SELECT * FROM test_table;")
    rows = cursor.fetchall()
    for row in rows:
        print(f"ID: {row[0]}, Name: {row[1]}, Value: {row[2]}")
        
except Exception as e:
    print(f"连接或查询出错: {e}")
finally:
    if 'cursor' in locals():
        cursor.close()
    if 'conn' in locals():
        conn.close()

4.2 连接阿里云 PolarDB PostgreSQL 版

连接云上的 PolarDB，最大的变化通常是 host （连接地址）和可能的额外参数（如 SSL 模式）。驱动和 SQL 语法完全兼容。

# 文件：connect_polardb.py
import psycopg2

# PolarDB 连接参数 (示例)
conn_params_polardb = {
    "host": "your-polardb-instance.polardb.rds.aliyuncs.com", # 集群连接地址
    "port": 5432,
    "database": "postgres",
    "user": "your_username",
    "password": "your_password",
    "sslmode": "require"  # 云数据库通常强制SSL
}

# 后续代码与 connect_pg.py 完全一致，只需替换 conn_params
# ...

4.3 连接华为云 GaussDB(for openGauss)

GaussDB 兼容 PostgreSQL 协议，但驱动略有不同。虽然 psycopg2 可能也能连接，但官方推荐使用 opengauss 驱动（它是 psycopg2 的一个分支，进行了适配和优化）。

# 首先安装 opengauss 驱动
pip install psycopg2-binary opengauss

# 文件：connect_gaussdb.py
# 可以使用 psycopg2，但更推荐 opengauss
import opengauss  # 或者 import psycopg2

conn_params_gaussdb = {
    "host": "your-gaussdb-instance.rds.myhuaweicloud.com",
    "port": 5432,
    "database": "postgres",
    "user": "your_username",
    "password": "your_password",
    "sslmode": "verify-ca", # 可能需要的SSL模式
    "sslrootcert": "/path/to/root.crt" # 可能需要CA证书
}

# 连接和查询代码与之前几乎完全一致
# 注意：某些高级特性或系统视图可能与原生 PostgreSQL 有细微差别

关键洞察 ：从代码层面看，迁移到大多数“PG系”国产数据库，对于应用层来说 改动极小 ，通常只需修改连接字符串。这正是兼容 PostgreSQL 生态的巨大优势。真正的差异隐藏在架构内部：分布式事务如何协调、数据如何分片、备份恢复如何实现、监控指标有何不同。

5. 深入内核：一个简单的扩展验证“血统”

如何初步判断一个数据库是否基于 PostgreSQL？除了查看官方文档，我们还可以通过查询一些 PostgreSQL 特有的系统视图和函数来窥探。

连接到数据库后，执行以下 SQL：

-- 1. 查看版本信息，很多基于PG的数据库会保留‘PostgreSQL’字样或自己的标识
SELECT version();

-- 2. 查询 pg_settings 系统视图，这是PG配置的核心表
-- 观察参数名和结构，与原生PG进行对比
SELECT name, setting, unit, context FROM pg_settings WHERE name LIKE '%server_version%' LIMIT 5;

-- 3. 查询 pg_available_extensions，看扩展管理机制是否一致
SELECT name, default_version, comment FROM pg_available_extensions ORDER BY name LIMIT 10;

-- 4. 尝试创建一个 PostgreSQL 特有的扩展（如 pgcrypto），看是否支持
CREATE EXTENSION IF NOT EXISTS pgcrypto;
SELECT encode(digest('test', 'sha256'), 'hex');

-- 5. 查看进程和锁视图，结构是否相同
SELECT pid, usename, application_name, client_addr, state FROM pg_stat_activity LIMIT 5;
SELECT locktype, database, relation::regclass, mode, granted FROM pg_locks LIMIT 5;

如果这些查询都能成功执行，且返回的数据结构、视图名称与 PostgreSQL 高度一致，那么其“PG 血统”就相当纯正。真正的“自主可控”并非要抛弃这些接口，而是要确保自己能完全理解、掌控和演进这套机制。

6. “自主可控”的真正含义与挑战

当我们谈论数据库的“自主可控”时，究竟在谈论什么？它至少包含三个层次：

1. 代码可控 ：拥有源代码，可以阅读、修改、编译。基于开源 PostgreSQL，这一点在大多数情况下是满足的。
2. 能力可控 ：具备对数据库内核的深度理解和修改能力。当遇到 Bug、需要性能优化、或适配新硬件时，团队能自己动手解决，而不是等待上游社区或商业公司。这是许多“基于开源”的厂商需要补的课。
3. 发展可控 ：能够主导该数据库技术路线的发展，至少能跟上主流社区的发展，并能将自身需求反馈甚至贡献到上游，不被上游的技术决策“卡脖子”。

对于“PG系”国产数据库，挑战正在于后两者：

• 能力挑战 ：PostgreSQL 内核极其复杂。有多少团队真正吃透了其查询优化器、执行器、存储引擎、事务并发控制的每一行代码？当社区发布新版本（如 PostgreSQL 17）时，自己的分支能否快速、平滑地合并上游更新，而不是形成越来越难以维护的技术孤岛？
• 生态挑战 ：虽然继承了 PG 的应用生态，但工具链（监控、备份、迁移）和开发者心智的生态，仍然需要长期建设。如何让开发者觉得“这是一个更好的 PostgreSQL”，而不是“一个有点不一样的 PostgreSQL”，是市场推广的关键。
• 创新挑战 ：在分布式、云原生等“上层建筑”做出差异化后，最终还是会触及内核的深度修改。如何确保这些修改是优雅的、可维护的，并能反哺或至少不偏离社区主线，是一个长期课题。

7. 给开发者和架构师的建议

面对纷繁复杂的国产数据库市场，如何做出选择？

1. 明确需求，避免跟风 ：不要为了“国产化”而国产化。首先评估你的业务到底需要什么：是极高的单机性能，还是弹性扩展？是强一致分布式事务，还是多模数据分析？PostgreSQL 社区版或许已经满足你 80% 的需求。
2. 优先考虑兼容性 ：如果你的应用已经基于 PostgreSQL 开发，那么选择一款高度兼容的“PG系”数据库，迁移成本最低，风险最小。务必进行完整的兼容性测试（SQL语法、数据类型、驱动、事务行为等）。
3. 重点考察“增值能力” ：对于“PG系”数据库，重点考察其在 PostgreSQL 基础之上提供的 独有价值 。例如：
   • 云服务商产品 ：考察其弹性伸缩、Serverless、跨可用区容灾、与云其他服务集成的能力。
   • 独立厂商产品 ：考察其分布式架构的成熟度、金融级高可用方案、混合负载（HTAP）能力、以及本地化部署和运维的支持力度。
4. 验证“可控”程度 ：询问厂商：内核是开源的吗？遇到深层次 Bug 你们能多快修复？版本升级策略是什么？是否建立了活跃的开源社区？能否看到核心开发者的贡献？
5. 从小处着手，进行 PoC 验证 ：选择 1-2 个候选产品，用真实的业务场景和数据量进行概念验证（Proof of Concept）。测试性能、稳定性、功能兼容性和运维工具链。

8. 总结：站在巨人肩膀上，然后成为新的巨人

回到最初的问题：“套壳”还是“自主”？答案并非二元对立。

在基础软件领域，站在巨人的肩膀上起步，是务实且明智的选择。Linux、Android、Chromium 的成功都证明了这一点。PostgreSQL 以其“德才兼备”的特质，成为了数据库领域那个最坚实的肩膀。

中国的数据库厂商，大部分选择了 PostgreSQL 这条技术路线，这是市场和技术规律共同作用的结果，无可厚非。关键在于，站在这个肩膀上之后，你做了什么？是仅仅刷了一层新漆，还是建造了更高的楼层？

真正的“自主可控”，不是从零开始造轮子的闭门造车，而是 在充分吸收和理解开源巨人的核心思想与工程精华后，针对真实的、迫切的产业需求（如超大规模分布式、软硬协同、金融级可靠、智能化运维），进行深度的、创新的、并最终能反哺或平行于开源生态的再创造 。

这条路注定漫长。它需要厂商摒弃短期的“换壳”功利心态，进行长期的技术投入和生态建设；也需要开发者社区和用户给予更多的耐心、反馈和共同成长的空间。

三十年 PostgreSQL，中国数据库走过了一条从“拿来就用”到“借鉴创新”的路。下一步，是走向“引领共进”。当基于 PostgreSQL 的国产数据库，不仅能解决中国市场的特殊问题，更能将其中具有普适性的优秀改进贡献回全球社区，甚至孵化出全新的、有影响力的分支时，我们才能说，中国数据库产业，真正找到了自己的位置。

对于每一位开发者而言，无论底层是哪个“巨人”，掌握扎实的数据库原理、SQL 优化、架构设计能力，才是应对万变的不变之法。毕竟，工具会演进，但处理数据的智慧永存。