🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Claude 随心用，限时 5 折。 👉 点击领海量免费额度
最近几年，国内数据库市场有个现象挺有意思：一边是各种“自主可控”、“国产化”的声浪越来越高，另一边，很多技术选型的讨论里，PostgreSQL（简称PG）这个名字出现的频率也越来越高。如果你去翻看一些头部云厂商的数据库产品线，或者研究一下那些宣称“自主研发”的数据库内核，会发现一个绕不开的影子——PG。
这引出了一个很多人心里有，但未必会公开讨论的问题：我们看到的很多“国产数据库”，到底是在PG这个成熟引擎上“套壳”，还是真的从零开始，走出了自己的路？更进一步，在PG诞生三十年后，中国数据库产业究竟走到了哪一步？是站在巨人的肩膀上眺望远方，还是仍在巨人的影子里寻找自己的形状？
要回答这个问题，不能只看宣传口号，得回到技术、生态、商业和工程的真实土壤里去看。这篇文章，我们就抛开那些宏大的叙事，从一个一线开发者和技术决策者的视角，聊聊PG的“德”与“才”，以及它如何深刻地塑造了今天中国数据库的格局。
1. 理解PG的“成功”：不止是流行，更是生态位的确立
当我们谈论一个数据库“成功”时，往往首先想到的是市场占有率。根据StackOverflow等开发者社区的连续多年调研，PostgreSQL在“流行度”、“喜爱度”和“需求度”三项核心指标上，已经全面领先，成为了开发者心中那个“最成功的数据库”。但它的成功，远不止于数字。
1.1 “开源”之德：不仅仅是免费，更是一种生产关系的胜利
PG的“德”，首先在于其彻底的开源精神。它采用类似BSD的PostgreSQL许可证，这是一种极为宽松的协议。简单说，你可以用它，修改它，甚至基于它开发商业闭源产品，只要不冒用PostgreSQL的商标即可。这种开放性，与某些采用GPL等“传染性”协议的开源项目形成了鲜明对比。
这种“德”带来了什么？
- 零成本启动与技术民主化：它彻底降低了数据库技术的使用门槛。从创业公司到大型企业，无需担忧天价的授权费用（如Oracle按核计费的模式），就能获得一个企业级的关系型数据库。这直接催生了互联网时代海量信息服务的繁荣。
- 避免供应商锁定（Vendor Lock-in）：使用商业数据库，意味着你的核心数据资产与一家公司的技术栈深度绑定。PG的开源特性，给了用户“用脚投票”的权利和底气。你不会因为商业策略变更而陷入被动。
- 成为“去O”的天然扛旗者：在国内“去IOE”（IBM、Oracle、EMC）的浪潮中，PG因其功能强大、与Oracle兼容性高（部分发行版宣称兼容度超96%），且完全免费，成为了替代Oracle最理想的开源选择。它不是一个“廉价平替”，而是一个在功能、稳定性和成本上综合竞争力极强的选项。
更重要的是，PG的开源模式，构建了一个真正的“社区主义”开发范式。全球顶尖的开发者共同贡献智慧，其成果被所有人共享。一个开发者使用PG，背后站着的可能是数万社区成员的集体智慧。这种生产关系的效率，是封闭开发难以比拟的。
1.2 “先进”之才：从关系型内核到“多模”数据平台
PG的“才”，则体现在其惊人的技术先进性与扩展性上。它早已超越了“一个关系型数据库”的范畴，进化成了一个多模态数据库平台。
它的核心优势在于其稳定、可靠的内核和强大的可扩展架构：
- 插件化架构（Extension）：这是PG设计的精髓。用户可以通过加载扩展，为数据库增加前所未有的能力，而无需修改内核。这就像给你的汽车发动机（内核）加装涡轮增压器（时序扩展）、四驱系统（分布式扩展）和自动驾驶芯片（向量扩展）。
- 一专多长，覆盖全栈：
- OLTP：这是老本行，ACID事务支持完善。
- OLAP：通过Citus等扩展支持分布式分析。
- 时序数据：TimescaleDB插件已成为该领域的标杆。
- 地理空间：PostGIS是GIS事实上的标准，功能强大到让很多专用GIS数据库汗颜。
- 全文检索：内置的全文检索功能足够应对很多场景。
- 文档存储：对JSON/JSONB的原生支持，让它可以无缝处理半结构化数据。
- 图数据：通过AGE扩展支持属性图查询。
- 向量计算：pgvector扩展让其轻松踏入AI时代，成为处理嵌入向量的热门选择。
- 联邦查询：通过FDW（外部数据包装器），可以用SQL直接查询其他数据库（如MySQL、MongoDB）甚至文件中的数据。
这意味着，对于一个中小型项目或企业，单一PG组件就能扮演缓存、事务库、分析库、地理信息库等多重角色。这种“全栈”能力极大地降低了系统复杂度和运维成本。正如一个经典的案例所示，探探在达到千万日活、数百TB数据量之前，其核心业务几乎完全由PostgreSQL支撑，兼任了多项职责。
这种“先进”，是PG在与老对手MySQL竞争中的核心杀手锏。MySQL以其“糙、猛、快”的特点，吃透了互联网早期快速迭代、重CRUD的红利。但时过境迁，PG在性能上已不逊色，而在数据一致性、功能丰富度、扩展性上则形成了代差。当业务复杂度提升，对数据正确性、分析能力、多数据类型支持有更高要求时，PG的优势就凸显出来。
2. PG的生态位：为什么它是国产数据库的“根”？
理解了PG的“德”与“才”，我们就能看清它在全球乃至中国数据库生态中的独特位置：它已经成为关系型数据库领域，类似Linux在操作系统领域的“根”。
2.1 三国演义与“根”的价值
在关系型数据库的世界里，长期呈现“三足鼎立”的格局：
- Oracle：商业闭源的王者，功能强大但昂贵，生态封闭。
- MySQL：最流行的开源数据库，但被Oracle收购后，其开源策略存在不确定性，且内核能力相对单一。
- PostgreSQL：功能先进且彻底开源。
这三者中，谁能成为“根”？“根”意味着拥有最广泛的下游衍生生态。Oracle是闭源的，不可能成为“根”。MySQL虽开源，但GPL协议的“传染性”和Oracle的控制，让基于其深度分叉并独立发展变得有法律和商业风险。
唯有PG，凭借其BSD-like协议和开放的架构，成为了那个理想的“根”。你可以基于PG内核，进行深度定制、优化、封装，打造一个全新的数据库产品，并冠以自己的品牌进行商业化。这在协议上是完全被允许的。
2.2 “PG系”国产数据库的繁荣
这正是中国数据库市场正在发生的现实。根据行业统计，有相当高比例（有说法超过三分之一）的所谓“国产数据库”，其内核都直接或间接基于PostgreSQL。它们大致可以分为几类：
- 开源发行版：如openGauss（华为开源）。它基于PG 9.2.4版本进行深度内核优化，增加了诸多企业级特性，并开源出来，旨在打造一个“开源根社区”。你可以将其理解为数据库领域的“RedHat Enterprise Linux”的开源版本。
- 商业发行版/云服务：如GaussDB（华为云）、PolarDB（阿里云，其PG兼容版本）、TDSQL-C（腾讯云，PG引擎）等。这些产品在云上提供完全托管的PG兼容数据库服务，通常在内核、存储、计算分离架构上做了大量增强。
- 独立商业数据库：一些创业公司或厂商，基于PG进行深度定制，面向特定场景（如HTAP、分布式）推出独立产品。
这种现象，常被外界调侃为“套壳”。但“套壳”这个词过于简单和负面，它掩盖了其中巨大的技术价值和商业逻辑。
3. “套壳”还是“自主”？一场需要重新定义的讨论
指责“套壳”很容易，但我们需要更深入地思考：在基础软件领域，什么才是真正的“自主”？
3.1 “套壳”背后的工程现实
从零开始写一个成熟、稳定、功能完备的数据库内核，是一个史诗级的工程挑战。它涉及：
- 复杂的存储引擎：B-Tree, LSM-Tree，事务日志（WAL），缓冲池管理，崩溃恢复。
- 完整的SQL解析与优化器：支持复杂的查询改写、代价估算、执行计划生成。
- 严谨的事务处理：MVCC（多版本并发控制）、隔离级别、锁管理。
- 高可用与分布式：主从复制、集群管理、数据分片、一致性协议。
这些模块的任何一个，都需要顶尖团队数年甚至十数年的持续打磨和真实场景的锤炼。PG社区经过三十年的发展，已经将这些模块打磨得异常成熟和稳定。
在这种情况下，基于一个经过验证的、优秀的开源内核进行开发，是最务实、最经济、风险最低的技术路径。这就像造车，很少有厂商会从冶炼钢铁、制造螺丝钉开始。大家都会采购成熟的发动机（如宝马、丰田的引擎）、变速箱、底盘技术，然后在此基础上进行调校、集成、创新外观和内饰，打造自己的品牌。
3.2 “自主”的真正含义：内核掌控力与上层创新
因此，判断一个数据库是否“自主”，关键不应看它是否从零开始，而应看：
- 对内核的掌控深度：是只能调用API，还是能深入理解其每一行代码，能进行深度的性能优化、功能增强和问题修复？当遇到一个深层次的Bug时，团队是只能等社区修复，还是能自己定位并解决？
- 在上层创造的独特价值：基于这个强大的“发动机”，你在存储计算分离架构、云原生部署、智能化运维、混合负载处理、多模数据融合、安全合规等方面，做出了哪些超越原版的、解决实际痛点的创新？
- 是否反哺生态：是只索取，还是也积极向开源上游社区贡献代码、修复漏洞、提出改进？这体现了团队的技术能力和开放心态。
以华为的openGauss/GaussDB为例，它在PG内核基础上，重点攻坚了：
- 高性能：针对多核CPU的NUMA架构优化、鲲鹏硬件指令集优化。
- 高可用：更精细的并行回放、极致RTO。
- 安全合规：满足国内金融等行业严苛的安全标准。
- AI融合：尝试将AI能力用于数据库自调优、索引推荐等。
这些工作，绝非简单的“换皮”所能概括。它需要深厚的内功和对数据库原理的深刻理解。
3.3 商业成功的闭环：生态、服务与信任
数据库，尤其是企业级数据库，从来不只是技术竞赛，更是生态、服务和信任的竞争。
- 生态：是否有丰富的工具链（监控、迁移、备份）、ORM框架支持、开发者社区？
- 服务：能否提供及时、专业的技术支持、容灾方案、性能优化服务？
- 信任：在金融、政务等关键领域，是否有大规模的成功案例？是否符合国产化政策要求？
国内数据库厂商基于PG发展，恰恰是在利用PG成熟的技术生态，快速构建自己的商业生态和服务能力。他们节省了重复造轮子的时间，将精力投入到更贴近中国市场需求的服务、合规、集成和解决方案上。这对于在短时间内建立市场信任，至关重要。
4. 中国数据库的当下与未来：站在PG的肩膀上，然后呢？
那么，中国数据库产业到底走到了哪一步？我的判断是：我们正处在“基于开源，超越服务，迈向核心”的过渡阶段。
4.1 当前阶段：开源内核 + 云服务与解决方案
这是目前的主流模式，也是被验证成功的模式。
- 优势：快速推出稳定可靠的产品，满足市场对“国产替代”和云服务的迫切需求。厂商可以聚焦于云原生架构、运维自动化、安全性增强和行业解决方案。
- 挑战：同质化竞争开始出现。如果大家都基于相似的PG内核，那么比拼的往往是云资源整合能力、销售渠道和价格，技术差异化壁垒不够高。
这个阶段，厂商的核心能力是“用好PG”和“服务好客户”。
4.2 下一阶段：内核深水区创新与全新赛道
要真正走向引领，必须在两个方向取得突破：
- 深入内核“深水区”：在存储引擎、查询优化器、事务处理等核心模块上进行突破性创新。例如，为适应海量数据和实时分析，研发下一代混合存储引擎；为拥抱AI，打造原生智能优化器。这需要长期、巨大的研发投入和顶尖人才。
- 开辟全新赛道：不完全拘泥于兼容PG或MySQL。在云原生分布式数据库、HTAP、流批一体、AI原生数据库、Serverless数据库等新兴范式上，中国厂商与国外巨头几乎站在同一起跑线。这里有重新定义规则的机会。例如，利用云的基础设施优势，重新设计存算分离架构；为AI工作负载设计全新的数据结构和查询语言。
4.3 给开发者和技术决策者的建议
面对纷繁的数据库市场，该如何选择？
- 理解需求本质：不要被“国产”、“自主”等标签迷惑。首先问清楚你的业务：需要的是OLTP还是OLAP？数据一致性要求多高？未来是否会涉及GIS、时序、向量等特殊场景？预算是多少？
- 将PG作为基准线：无论是否最终选择“PG系”产品，都应该将PostgreSQL社区版作为一个重要的评估基准。它的能力、性能和稳定性，代表了当前开源关系型数据库的先进水平。任何宣称“自主”的产品，至少应该在某些方面明显优于这个基准。
- 考察厂商的“附加价值”：如果考虑国产商业数据库或云服务，重点考察：
- 内核掌控力：询问他们针对内核做了哪些关键优化？有没有向PG上游贡献过核心代码？
- 独特功能：除了PG社区版的功能，他们提供了哪些独有的、解决你痛点的高级特性？（如更强的分布式能力、更好的监控工具、更便捷的迁移服务）
- 服务与生态：技术支持响应如何？是否有针对你所在行业的成功案例和解决方案？工具链是否完善？
- 拥抱开源生态：无论选择哪家厂商的产品，尽量保持对标准SQL和开源生态组件的兼容。这能为未来可能的技术迁移留下余地，避免被过度绑定。
5. 结论：一场关于“自主”的重新定义
回到最初的问题：“套壳”还是“自主”？我认为，在基础软件领域，这是一个需要被重新定义的伪命题。
在PG诞生三十年后，它已经从一个数据库项目，演进为一个强大的、开放的、可扩展的数据平台内核。中国数据库产业选择站在这个巨人的肩膀上，是一个明智且必然的选择。这并非“套壳”，而是参与全球开源协作，并在应用层和工程化层面进行深度创新和增值。
真正的“自主”，不在于是否从零开始写每一行代码，而在于：
- 是否具备对核心技术的深度理解和掌控能力（能修发动机，而不仅仅是开车）。
- 是否能在巨人的肩膀上，解决独特的、实际的、规模化的产业问题。
- 是否能从技术的使用者、集成者，逐渐成长为规则的共同制定者和生态的贡献者。
今天，我们看到很多中国数据库产品，在PG提供的优秀“发动机”基础上，正在努力打造更好的“变速箱”、“底盘”和“智能驾驶系统”，并致力于提供全生命周期的“汽车服务”。这条路走得务实且有效。
未来，期待有更多中国团队，不仅能用好这台“发动机”，更能参与到下一代“发动机”的设计与制造中，甚至发明全新的“交通工具”。那时，关于“自主”的讨论，将拥有全新的、更坚实的底气。
对于每一位开发者而言，理解PG，就是理解现代数据库技术的基石。无论你使用的是哪一家厂商的数据库，深入PG的世界，都能让你更清晰地看到技术的来路与去向。
🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Claude 随心用，限时 5 折。 👉 点击领海量免费额度