libaike111的博客

落地时，NL2SQL 项目做不好，九成不是模型选错了，是库里的表没人写注释。这两年 AI 数据库的发布会我听得挺多，各家都在讲库内推理、向量检索、多模融合，性能数字一个比一个漂亮。但真正落到项目上，最先卡住人的往往不是这些。参与和跟进的 AI 数据库项目加起来七八个，横跨政务、能源、制造几个行业，库有国产的也有开源的，表最多的一千多张，主攻场景基本都是用自然语言查数。POC 阶段的通过率看着都不错，一上生产就掉，业务同事用两周就退回「提需求给数据团队」的老路。最早我也以为是模型不行。

几年前，你在信创投标书里写"基于开源数据库"，评审看到这两个字会点头。现在你再写这两个字，采购和合规会反过来问你一堆问题：代码谁在维护、出了问题谁兜底、许可证会不会传染。这篇文章不站开源，也不站闭源，只把这个标签在信创里身份失位的来龙去脉讲清楚，再说说这件事接下来会往哪走。

先说一个容易误解的点：核心银行系统的英文 CORE Banking，其中的 CORE 并不是"核心"这个单词，而是Centralized Online Real-time Exchange（集中式在线实时交互）的缩写。集中：全行账户与账务集中处理，而非网点各自记账；在线：任何渠道（柜面、网银、手机银行、ATM、开放银行）的交易，后端同步响应；实时：账务即时入账，不延后、不批量。银行核心系统是一台全行级别的"确定性机器"，它保证任何渠道的资金进出，在全行层面都是实时、准确、可追溯的。

把"账务确定性"当第一指标，别被"分布式/云原生"这些先进词带节奏；改造走渐进路径，先外围后核心、先双轨后单轨，给业务连续性留足安全垫；选型看案例密度和运维生态，核心系统是十年尺度的事，别用一年尺度的标准来选。一句话收尾：银行核心系统的每一次"换心"，考的不是技术先进性，而是你对"账不能错"这件事有多敬畏。本文基于公开信息独立撰写，不代表任何厂商立场。李白客，信创行业独立观察者。关注数据库、AI 基础设施与国产化替代。

一篇关于信创数据库「去O之后」的独立分析。不写通稿，只说真话。阅读时间：约 14 分钟 标签：#信创 #去O #国产数据库 #2027 #行业趋势2026 年，信创数据库的新闻里，出现频率最高的两个词是「去O」和「割接」。每隔几天，就有新的迁移案例见诸报道——医疗的、政务的、金融的。每一条都在讲同一个故事：去O，正在冲刺。割接成功只是把数据搬进了新房子，真正的考验在之后的三年——客户过不过得好，运维扛不扛得住，生态跟不跟得上。

信创迁移产业的演进，围绕一个中心节点展开——2027 年。2022 年，要求所有央国企在 2027 年底前完成信息化系统的 100% 信创国产化改造。这不是建议，是硬约束。未达标企业面临的后果包括合规风险、采购成本上升 30% 以上、以及市场竞争力评级降级。这个时间节点确立之后，信创迁移市场进入了一个"倒计时驱动"的确定性增长周期。所有采购计划、预算编制、技术选型、项目实施，都围绕 2027 展开倒排。第一，需求刚性。信创迁移不是"可做可不做"的投资，而是"不做不行"的合规支出。

核心系统替代难的逻辑不仅仅是技术性的。技术问题——兼容性、性能、高可用、容灾——虽然复杂，但都是可以解决的。风险文化：金融机构的风险管理文化天然保守。核心系统不出问题是应该的，出了问题就是事故。在没有"足够多"的成功案例和"足够长"的稳定运行时间之前，更换核心数据库的制度性阻力远超技术性障碍。替代成本的非对称性：核心系统数据库替换的直接成本（软件许可、实施服务、硬件升级）是可以计算的。但间接成本——业务中断风险、运维团队的重新培训、上下游系统的适配——很难精确评估。

数据库集群化不是终点，而是一个起点。当集群部署成为标配，竞争焦点将从"有没有集群能力"转向"集群好不好管、稳不稳定、出了问题多快能恢复"。服务网络的密度和运维体系的成熟度，将成为比产品功能更硬的竞争壁垒。国产数据库如金仓数据库 KingbaseES 在集群方案上的布局——共享存储集群和读写分离集群两套架构——反映了国产数据库在集群化浪潮中的一个务实选择：不追求技术概念的最新，而是把已经在金融、政务生产环境中反复验证过的方案做到可靠。在核心系统的替代场景中，可靠性比先进性更重要。