前几天感冒发烧，去医院看了趟病。
本来觉得就是个普通感冒，看看医生，开点退烧药，回家躺着休息几天也就差不多了。结果医生开了不少药，其中还有好几种价格不便宜的中成药。
我平时看过一些医学科普，知道普通感冒大多会自己好，用药主要是缓解症状。不少治感冒的中成药，疗效其实缺少足够可靠的临床证据。
查资料时还看到，有些中西药复方感冒药，能说清楚退热、缓解症状作用的成分，恰恰来自西药。
比如常见的感冒灵，就含有对乙酰氨基酚、马来酸氯苯那敏和咖啡因。2026 年国家药监局还专门修订了感冒灵口服制剂的说明书，要求明确提示这些成分，以及重复用药、肝肾损伤等相关风险。
那其他添加的成分，到底带来了多少额外的治疗收益？有没有足够可靠的临床证据？
我个人对这类药的态度比较直接：拿不出充分的疗效证据，却靠各种宣传卖出不低的价格，那多少有点骗钱的嫌疑。多出来的成分没带来多少额外疗效，用药的风险反倒更复杂了。
看着手里那一堆药，心里有些别扭。一方面是牛马心疼钱；但更重要的是觉得，吃药这么普通的一件事，患者却很难判断自己花的钱到底买来了多少效果。
病人对药的要求也没那么复杂，就是希望它真的有用。疗效确切，贵一些也只能接受。
这让我想起一位亲友的经历。
因为某种疾病，他需要长期用特定药物。期间试过一些仿制药，但实际用下来，还是原研药效果最好、副作用也最少。原研药更贵，最后也只能选它。
这只是一个人的用药体验，不能说明原研药普遍优于仿制药。合格的仿制药本来就应该达到相应的质量和疗效要求。
但对真正受疾病困扰的人来说，药有没有效果是很切身的事。相比价格，能把病情控制住，重要得多。
这两件事放在一起，话题就有点往宏大叙事上走了，我不由得想到药物背后的研发。
如今的医药工业已经非常发达，我们有大量药企，能生产各种各样的药品。但回头看许多重要药物最初是怎么被发现的，背后往往是欧美的基础研究和原创研发成果。
国内这些年的创新药研发也取得了不少进展。不过一种药从发现新的治疗机制，到完成临床试验，再到规模化生产、降低成本、送到患者手里，中间包含了很多类型的技术工作。
它们都在创造价值，解决的问题不一样。
评价一个国家的医药研发水平，除了药企数量、药品产量和市场规模，那些能开辟新治疗路径的研究成果，也许也该算进去。
想来想去，又想到自己身处的数据库行业。
热潮之后，再看国产数据库
前些年信创比较热的时候，国产数据库行业确实热闹。
各种厂商、产品、技术大会、生态适配、国产替代，感觉隔三差五就能看到新的消息。PostgreSQL、MySQL 等成熟开源数据库，也成了许多国产数据库产品的重要技术基础。
有的主打 Oracle 兼容，有的做分布式架构，有的探索存算分离、云原生，还有大量围绕性能、可靠性、运维管理和业务迁移展开的工作。
那几年，整个行业投入了不少资金，也吸引了大量研发人员。
但这两年，至少从我的感受来看，已经没有以前那么热闹了。
信创的热度在退，厂商也开始面对更现实的问题：产品能不能真正满足客户需求，订单能不能持续，交付和维护成本能不能降下来，公司能不能长期盈利。
市场数据倒也没有那么悲观。
根据中国信通院发布的《数据库发展研究报告（2026年）》，2025 年我国数据库市场规模约为 677.96 亿元人民币。国内数据库产品数量在经历 2022 至 2024 年的快速增长后，2025 年显著回落，到 2026 年上半年又企稳回升至 182 款。
至少按这份报告的统计，市场规模仍在增长，但竞争格局也在变。
经历了前些年的快速扩张，现在反而适合重新审视一下这个行业。
这些年，我们到底积累了什么？
首先，当然是大量工程化能力。
能把 PostgreSQL 这样的成熟数据库改造成满足特定客户需求的商业产品，本身就不是一件简单的事。
比如 Oracle 兼容，听上去只是增加一些 SQL 语法和函数，但真正做过的人应该知道，要让不同数据库在复杂业务场景下保持一致的行为，背后可能涉及大量内核修改和边界问题。
再比如高可用、故障恢复、数据库迁移，以及面对不同负载的性能优化，都靠长期的工程经验撑着。
这些工作解决的是真实问题。
工程化本身也可能带来创新。现有架构遇到新的业务需求和硬件环境时，研发人员往往要重新设计某些机制，甚至提出新的技术方案。国内一些数据库产品也确实发展出了有价值的架构和技术成果。
所以，国产数据库在技术价值上，至少比前面那些疗效存疑的感冒药让我乐观得多。
数据库毕竟是一个相当实在的技术领域。性能怎么样、能不能稳定运行、故障后能不能恢复、客户迁移之后到底省了多少成本，这些都能用起来验一验。
如果一个团队真的解决了这些问题，即使底层基于 PostgreSQL，我也觉得完全值得获得相应的商业回报。
开源不等于拿来就能用。能把它改造成满足客户需求的成熟产品，本身就是很大的价值。
但我也有些担心，国产数据库会不会出现某种类似“中成药”的发展倾向。
底层真正发挥作用的是 PostgreSQL、MySQL 等经过长期验证的成熟系统，外面再包装一套自己的概念，添加大量客户未必真正需要的功能，最终依靠市场宣传和采购需求获得订单。
如果这些新增功能确实解决了问题，那当然好。
可如果增加的主要是产品复杂度和维护成本，却没有带来相应的收益，那这些所谓的创新，恐怕和感冒药里那些说不清实际作用的额外成分也没什么两样。
功能越多，不代表产品越好。对数据库这样的基础软件，额外的复杂性甚至可能意味着更多 Bug、更高的维护成本，系统行为也更难预测。
我最不希望看到的，就是客户花了不少钱采购数据库，最后却发现真正值得信任的还是下面那套成熟的开源内核。
迁移完成之后，心里仍然不踏实。遇到关键业务场景不敢用，出了问题还要怀疑那些额外增加的功能是不是又引入了新的风险。
就像病人拿着一大袋药回家，明明花了不少钱，却还是不确定到底哪种药真正有用。
这只是我担心的一种倾向，不是说国产数据库行业已经变成了这样。国内有很多优秀的数据库工程师，也有不少值得研究的技术成果。至于整个行业的原创能力究竟处于什么水平，我还没有足够的资料做出全面评价。
不过对我来说，国产数据库发展到今天，已经值得用比产品数量、市场规模和功能列表更丰富的标准来评价了。
这些年，我们解决了多少过去解决不了的问题，又留下了多少能够被后来者继续使用的技术成果？
客户对数据库的信任，首先来自产品在真实业务中的表现。信任能维持多久，还得看企业有没有持续解决问题、改进产品的能力。
这就绕不开一家商业数据库公司每天都在面对的研发选择。
一家数据库公司，应该把钱花在哪里？
假设你是一家数据库公司的负责人。
现在有一个重要客户提出了 Oracle 兼容需求。只要半年内完成这些功能，就有机会拿下一笔不错的订单。
与此同时，研发团队里有几名工程师发现，当前数据库的某个底层机制可能存在改进空间。如果重新设计，也许能在某些工作负载下显著提升性能，甚至形成一种可以被其他数据库采用的新方案。
前一个项目需求明确、成本相对可控，商业收益也比较容易预期。
后一个项目可能需要一两年时间反复研究、实验和验证，没人能保证最终成功。即使成功了，也未必马上有客户愿意为此付费。
如果公司资源有限，我想大多数企业都会优先考虑前一个项目。
这完全可以理解。
公司要生存，要支付员工工资，要满足客户需求，也要向股东或投资人交代。研发不能只看技术上有没有意思，还得考虑投入产出。
再说，解决复杂的兼容性问题同样需要很高的技术水平，这些经验也能用到其他客户和产品上。
但长期技术研究有另一种价值。
它可能解决一些客户还没提出来的问题，为产品以后留出新的技术选择。就算某项研究没达到预期，过程中积累的设计经验、实验方法和人，也可能在后面用上。
只是这些收益很难提前算清楚。
比如一家公司长期研究存储机制，对硬件特性、数据组织、并发控制有比较深的理解。以后遇到新的工作负载或硬件架构，它更容易找到办法。
这种能力要靠时间堆，短期招一批人补不上。
而在 PostgreSQL 这样的开源生态里，还有一个特殊之处。
假如一家公司投入大量资源研究出某项新的数据库技术，最终把成果贡献给 PostgreSQL 上游，那整个社区都能从中受益。
对这家公司来说，参与上游能积累技术声誉、影响技术方向、吸引人才，也可能减少维护自身分支的长期成本。
但研究成本主要由它承担，收益却由整个行业分享。
一项研究对整个技术领域的价值，可能远大于它最初能给这家公司带来的收益。
这也是我觉得长期技术研究最难的地方。
站在企业自身的角度，优先选择能够带来订单、改善产品竞争力的项目，是理性的商业决策。
但如果整个行业的大多数企业都这样选，那些需要多年投入、短期又没有明确商业收益的研究，就可能始终缺少足够的支持。
商业化做得好的企业，也有机会形成另一种局面。
成熟产品带来稳定收入，支持一部分长期研究。研究积累下来的技术能力，未来又成为产品的竞争优势。
不少重要的技术创新，本来就是在解决实际业务问题的过程中逐渐形成的。
只是这种循环需要一定的条件。
一家公司的发展阶段、现金流、市场竞争，还有管理层对技术的理解，都会影响它愿意承担多大的研发风险。
尤其是信创热潮过去之后，当企业开始更重视盈利能力和经营效率，能够立即带来收入的项目，通常会更容易获得资源。
对企业来说，这很正常。但从整个数据库产业的角度看，我还是希望能有更多资源投入那些尚无成熟答案的问题。
大学、研究机构、开源社区，还有有条件承担长期投入的商业企业，都可以在其中发挥作用。
而对商业数据库公司来说，一个比较现实的方向，可能是从已有工程实践中寻找值得长期研究的问题。
比如某个底层机制在不同客户、不同工作负载下反复暴露出类似的局限。与其一次次局部修补，不如花些时间研究背后是否存在更普遍的设计问题。
先投入少量资源验证，再根据结果决定是否扩大研究规模。
这样既顾上了眼前的业务，运气好的话，还能做出超出单个客户需求的技术成果。
我自己比较认同这种思路。
因为长期技术积累未必总需要一个声势浩大的研究项目，也可能来自许多工程师对某些问题持续多年的深入探索。
但这终究需要企业愿意留下空间。
如果每个研发项目都必须直接对应某个客户需求，每个工程师的工作都要按照短期交付结果考核，那么即使团队里有不少优秀的研发人员，那些值得长期研究的问题也可能始终没有机会被认真对待。
一家技术公司的长期竞争力，靠不断加功能是撑不住的，还得有一些能沉淀下来、以后能解决新问题的能力。
对客户来说，这一点同样重要。选一款数据库，往往意味着后面要用好几年。今天能用是一方面，几年后出了新问题，厂商还解不解决得了，才决定了这份信任能维持多久。
AI 会让这些选择发生变化吗？
前段时间，我在《Contributor 有什么了不起的？》里，讨论过 AI 对 PostgreSQL 内核开发者的影响。
当时关心的是，AI 让代码生产越来越容易之后，一个工程师应该如何建立自己的技术理解和判断能力。
这次想到的是整个研发团队：AI 提高了开发效率，企业会怎样使用由此多出来的研发能力？
现在的 AI Coding Agent 已经能帮我们搜索代码、分析实现、编写功能、补充测试，甚至自动执行编译和测试，再根据结果继续修改。
虽然数据库内核研发中依然存在大量复杂的正确性验证和长期维护工作，但部分工程任务的成本确实有机会显著下降。
对商业公司来说，这首先是效率。
过去半年只能完成五项重要需求，未来同样的团队也许能完成十几二十项。
但竞争对手也在使用 AI。
当所有企业都能更快开发功能，市场的交付预期也可能随之提高。过去半年完成的工作，以后可能两个月就要交付。
于是，AI 带来的效率提升，很可能被进一步转化成更高的交付要求。
企业开发的功能越来越多，产品迭代越来越快，但长期技术研究未必因此获得更多资源。
对于一些正在控制成本的企业来说，AI 还可能推动研发团队规模和组织方式的调整。
这对我们这些从事内部研发的工程师来说，恐怕也是不得不面对的现实。
不过，我对 AI 还有另一层期待。
过去开展一项新的技术研究，往往需要花费大量精力阅读已有代码、实现原型、搭建实验环境，再根据结果反复修改。
现在 AI 有机会承担其中越来越多的工作。
一些过去因为工程成本太高而没有条件尝试的研究，未来也许只需要一个规模不大的团队，就能开展初步探索。
原型做出来并不等于研究成功。数据库这样的复杂系统，方案对不对、性能收益可不可靠、长期维护成本能不能接受，都要反复验证。
但至少，尝试新方案的门槛正在变化。
这让我觉得 AI 对数据库研发的影响，可能远不止开发速度变快这么简单。
它可能让企业以更低的成本完成商业需求。反过来，一些原本做不起来的技术研究，也有了机会。
只是节省出来的资源，不会自动流向长期研究。
企业完全可能用它完成更多客户需求、缩短交付周期，或者直接降低经营成本。这些选择都有商业上的理由。
换个角度看，如果所有公司都在借助 AI 不断增加产品功能，那前面担心的那种“中成药式”研发，可能会变得更加容易。
过去开发一个功能需要投入大量工程师，至少还有成本约束。
未来如果 AI 能快速实现各种功能，产品里也许会出现越来越多看起来很有吸引力、实际使用价值却不明确的东西。
软件复杂度可能因此进一步增加，长期维护和验证的负担也可能更重。
当实现一个功能变得越来越容易，判断它是否值得实现，反而可能变得更加重要。
但 AI 也确实可能降低长期研究的门槛。
所以对这件事，我的期待和担心差不多一样多。
AI 改变的是成本和效率，这些能力最后被用在哪儿，才是决定行业技术积累的东西。
最后，还是回到自己身上
前面聊了这么多行业和公司的事，最后还是会落到自己每天的工作上。
作为一个研发/DBA，大部分时候，我们并不能决定公司的整体研发方向。
公司有产品规划，有客户需求，有经营目标。我们需要按照这些目标完成开发任务，修复 Bug，解决性能问题，保证系统稳定运行。
这些工作本身就有很大的技术价值。
很多值得研究的问题，也确实是在处理实际工程问题时才冒出来的。
只是工作久了，我也会想，除了完成既定任务，自己有没有机会在某些技术方向上影响一点什么。
比如在处理客户问题时，发现某个底层机制反复暴露出类似的局限。如果有机会进一步研究，或许能够找到一种更通用的解决方案。
但在公司内部推动这样的研究，仅仅觉得技术上有意思，显然还不够。
还需要让别人理解：它能解决什么问题，对现有产品有什么价值，要投多少成本，失败了怎么收场。
这也是我以前没有特别认真考虑过的一点。
平时研究 PostgreSQL，更多时候是在思考一个技术方案为什么合理，还有没有更好的设计。但如果希望一项研究能在公司内部真正开展，可能还需要从企业经营和研发投入的角度，解释为什么值得去做。
技术上有价值，不代表公司现在就愿意投。
对个人来说，比较现实的做法，也许是先从日常工作中那些反复出现的问题开始。
有机会时做一些小规模实验，验证自己的想法。如果确实有价值，再尝试争取更多资源，而不是一开始就提出一个投入巨大、回报又很难预测的研究项目。
个人的主动性也有边界。
长期研究需要时间和组织支持，不可能完全依靠工程师的业余兴趣。公司是否愿意给这类工作留下空间，同样非常重要。
尤其随着 AI 开始改变研发工作的成本和分工，这种矛盾可能会变得更加明显。
借助 AI，我们也许能用更低的成本去试以前做不了的研究。但企业同样可能把交付要求再提一档，或者干脆少留几个人。
代码写得快了，不等于我就有更多时间研究自己想研究的东西。
我甚至觉得，对于我们这些从事内部研发的工程师来说，AI 的影响可能比单纯的编码效率提升更加深远。过去需要大量人力完成的工程化工作，可能逐渐改变组织方式，而那些需要长期积累的研究能力，又未必能立刻转化成商业价值。
处在这种变化之中，我们能做的事情或许也没有想象中那么多。
但至少，我还是希望能在完成实际研发任务的同时，多留意那些值得长期研究的问题，并且尝试推动其中一些想法真正落地。
这大概需要技术能力，也少不了对商业和研发投入的理解。
写到这里，再回头看看最初那次感冒，确实没想到会扯出这么多事情。
从一张医院处方，到原研药和医药研发，再到前些年的国产数据库信创热潮，最后又想到自己每天从事的 PostgreSQL 内核开发。
回头想想，我最初对那些感冒药的不满很朴素：花了钱，总希望得到真正有用的东西。
数据库客户又何尝不是如此？
企业选一款数据库，最后关心的还是能不能稳定运行、能不能解决业务问题、出了故障能不能及时恢复、长期用下来成本合不合适。
产品介绍里有多少新概念、功能列表比对手长多少，最后都得让位于这些问题。
再说，数据库这样的基础软件往往承载着重要业务。一旦客户失去信任，后面加多少功能也很难补回来。
我并不觉得国产数据库公司都应该去做原创研究，也不认为商业化和工程化没有长期价值。
但经历了前些年的热潮，我确实希望国内数据库产业能走向一种更可持续的状态。
企业靠真正有竞争力的产品赚钱，也愿意把其中一部分投回长期技术积累。工程师通过实际项目不断解决问题，其中一些有普遍价值的认识，能慢慢长成可以长期使用的东西。
AI 的出现也许会让这件事更容易；也可能让竞争更激烈，企业更倾向于压成本、提效率。
现在还很难知道会走向哪一边。
但有一点我的态度比较明确。
我不希望国产数据库最终变成技术行业里的“中成药”：底层是一套真正有效的外来技术，外面却包裹越来越多说不清价值的东西，最终让客户花了不少钱，仍然对产品缺乏信任。
我更希望有一天，客户选择国产数据库，是因为它真的足够优秀，能够解决那些原有产品解决不了或者解决得不够好的问题。
这种信任得靠一次次实际交付、稳定运行和持续改进慢慢攒出来，背后是企业长期解决技术问题的能力。
甚至有一些技术，能够从国内数据库团队的研究中诞生，再被其他数据库系统学习和采用。
至于这些成果最终来自商业公司、大学、研究机构还是开源社区，我觉得倒没有那么重要。
重要的是，整个产业能够持续产生它们。
对我这样的普通内核开发者来说，或许也应该从眼前的工作开始，尝试在解决实际问题的过程中，寻找那些值得继续深入研究的方向。
毕竟，信创的热潮终究会过去。
等到多年以后回头看，我希望国产数据库留下的，不只是一批曾经卖得不错的产品，还有一些真正推动了数据库技术向前发展的东西。