信创进入深水区：数据库替换的胜负手不在“换”，在“稳”
国产数据库已从外围系统走向核心系统，但真正的难点是兼容性、双轨运行、性能验证和运维能力。行业共识正在从“完成替换”转向“稳定运行”。
信创替代已经从“要不要做”进入“怎么做得稳”的阶段。OA、邮箱等外围系统较早完成替换，ERP、CRM 等业务系统进入高峰，核心交易和生产系统则仍在验证与试点。越往核心走，数据库替换越像一场系统工程，而不是一次软件安装。
共识一：国产数据库已进入主战场，但核心系统仍有硬仗
行业数据显示，国产数据库在本地部署市场的份额已经明显上升，部分国产厂商在关系型数据库本地部署市场取得领先。但在金融核心交易等场景，国产化率仍然不高，不少机构对按时完成全面替代持谨慎态度。
这说明“产品可用”与“核心系统可承载”之间仍有距离。核心系统关注的不只是功能，还包括高并发下的稳定性、故障切换、数据一致性、性能可预测性和长期运维能力。
共识二：兼容性评估决定迁移成本，双轨运行不能省
Oracle 兼容性是迁移成本的关键变量。行业实践中，典型项目可能有相当比例的 PL/SQL 需要改写，个别产品更高。迁移工具可以自动转换一部分存储过程，但很难覆盖所有业务逻辑和性能特征。
行业正在形成的迁移路径是：评估调研、兼容性扫描、POC 验证、双轨运行、灰度切流、正式割接、回退预案。跳过双轨验证直接切流，是核心系统迁移中最危险的动作之一。双轨期不仅是数据同步，更是性能、事务和运维流程的验证期。
共识三：迁移之后的运维、生态和人才才是决胜局
迁移实施成本通常只占总成本的一部分，长期运维、工具链、人才培养和生态适配才是更大的投入。国产数据库的版本迭代快、分布式架构差异大，原有的监控、备份、调优和故障处理经验不能直接照搬。
选型时也不应只看排名或认证数量，而要按负载匹配：交易型、分析型、混合负载和分布式场景对数据库的要求不同。行业更看重的是可持续的生态、可用的工具链和本地服务能力。
对运维与建设团队的启示
- 先做应用与数据库的兼容性盘点，量化 SQL、存储过程和接口改造量。
- 为核心系统设计双轨运行和回退方案，明确切换条件与责任边界。
- 在 POC 中验证真实业务峰值，而不只跑基准测试。
- 提前建设国产数据库的监控、备份、调优和人才培养体系。