作者：Marco / 数智猿

责编：陆易斯 / 数智猿

行走在雅加达的街头，QRIS（印尼统一二维码支付标准）正在把街边摊贩、传统市场与数字金融连接起来，现金之外，数字钱包和移动银行正成为越来越多人的日常选择。随着这场数字化迁移加速，支付也从低频消费走向高频、高并发场景，背后的数据库一旦出现问题，影响的就不只是页面加载速度，而是转账、对账甚至资金安全。

Bank Indonesia数据显示，2025年第四季度，印尼数字支付交易量达到142.6亿笔，同比增长39.21%，其中QRIS交易量同比增长139.99%。在这个市场里，DANA的账户规模已接近2亿，BNC的neobank注册用户也达到2860万。

一个是从移动互联网中长出来的数字钱包，一个是有三十多年历史、正在重做数字核心的传统银行。两家公司路径不同，却都把中国分布式数据库放进了关键系统：DANA采用OceanBase，BNC的新核心系统引入腾讯云TDSQL。它们提供了一个更具体的观察窗口：中国数据库为什么能先在印尼数字金融找到机会？

印尼数字支付已经进入高频增长阶段。数据来源：Bank Indonesia《2025年第四季度货币政策报告》及《2025年印度尼西亚经济报告》；数据猿制图。

市场大不是答案

印尼的机会在于痛点已经发生

印尼当然足够大。人口、移动互联网用户、数字支付渗透率，都让它成为东南亚最受关注的市场之一。但对数据库这样的底层软件而言，“市场大”并不会自动转化为订单。只要原来的系统还能支撑业务，企业很少愿意为了一个更先进的技术概念，主动承担迁移核心数据库的风险。

真正有价值的信号，是业务增长有没有把旧架构逼到临界点。印尼的数字金融正在出现这种变化。QRIS把大量线下小微商户接入统一二维码体系，BI-FAST让零售转账进一步实时化；数字钱包和数字银行也不再只做充值、转账。以BNC为例，其产品已经延伸到储蓄、贷款、支付、现金管理等多类服务；DANA则覆盖转账、充值、银行卡绑定、QRIS支付等高频场景。业务从“完成一笔支付”走向“持续经营一个金融账户”，底层数据结构和交易复杂度随之抬升。

同一个用户可能同时产生账户余额、交易流水、商户结算、营销活动以及其他金融产品数据。交易高峰到来时，系统不仅要扛住并发，还必须保证账务前后一致。对普通互联网业务而言，短时间延迟也许只是体验下降；到了金融场景，数据不一致可能直接变成对账差异、资金风险和客户信任问题。

监管进一步压缩了“先上线、后补课”的空间。OJK针对商业银行的信息技术规则明确，银行原则上应在印尼境内处理基于IT的交易；电子系统、数据中心或交易处理放到境外，需要满足相应审批要求。2026年3月起生效的新规，又把IT治理、第三方技术服务商、境外部署、数据管理和个人数据保护纳入更细的监管框架。

所以，数据库厂商进入当地金融核心系统时，性能只是一张入场券。客户同时会问：能不能本地部署，灾备怎么做，旧系统如何迁移，出现故障谁来响应，长期运维是否可控。只有当这些问题和业务增长叠在一起，数据库升级才会从“技术优化项”变成不得不处理的经营问题。

这也是印尼数字金融给中国基础软件企业的第一层启发：出海不能只沿着“哪个国家市场最大”去找机会，更要沿着业务增长去找那些旧架构瓶颈已经显性化、技术问题开始能用业务损失衡量的客户。

DANA：把“中国复杂场景”翻译成业务价值

DANA是典型的“业务长得太快，底层先承压”。2018年上线后，这家数字钱包迅速扩张。到2024年，DANA披露的账户规模已接近2亿，平台注册的中小微商户约120万。用户和商户增长带来的不只是更多交易，也让数据库从后台工具逐渐变成业务扩张必须正面处理的底座。

根据OceanBase公开的客户案例，DANA早期采用的是一套MySQL兼容数据库架构。随着在线交易和合作商户增加，交易管理、支付、账务、会员、营销等系统在高峰时越来越难弹性扩展，原有集群频繁逼近容量上限；异步复制在高可用切换时，还可能带来数据一致性风险。对于钱包业务而言，这类问题显然比“页面慢几秒”严重得多。

DANA 首席技术官 Norman Sasono在OceanBase 海外技术峰会，来源：Oceanbase社区

OceanBase能够进入这个项目，不是因为它带着“中国数据库”的身份，而是因为产品能力恰好对应了这些具体压力：强一致和多副本架构解决故障切换中的数据正确性，分布式横向扩展承接持续增长的流量，混合云在本地IDC的稳定成本与公有云弹性之间寻找平衡，OMS迁移工具则降低大量存量MySQL实例搬迁的风险。

OceanBase披露，DANA曾把集群从3节点扩展到6节点，过程中不需要中断业务；构建混合云架构时，又通过OMS迁移了数百个MySQL实例。2019年启动混合云部署后，DANA在2020年记录到数据库故障为零、数据丢失为零，整体业务系统可用性超过99.99%。这些数字来自厂商客户案例，不能等同于独立测评，但至少说明，客户讨论的并不是抽象参数，而是扩容、可用性、迁移风险这些可以直接落到业务上的指标。

DANA从MySQL兼容架构向OceanBase迁移的主要脉络。来源：OceanBase DANA客户案例、DANA 2024 Sustainability Report；数据猿整理制图。

这正是中国数据库出海最容易被误读的一层。在国内，基础软件常被放在“自主可控”或本土技术体系的语境里讨论；到了海外，这套身份叙事没有天然溢价。印尼客户不会因为数据库“来自中国”就迁移核心系统。它真正关心的，是系统能不能稳定跑、扩容会不会停、故障切换会不会丢数据、迁移风险能不能控制，以及总体成本最终算不算得过来。

OceanBase能够回答这些问题，与它在中国经历过的复杂支付场景有关。OceanBase官方技术文档显示，2014年“双11”开始承担支付宝交易库部分流量；到2016年，支付宝交易、支付、会员、账务等核心数据库业务流量已经全部运行在OceanBase上。对海外客户而言，这段历史真正可转化的价值，不是“中国大促有多大”，而是这套数据库确实在超高并发支付、强一致、容灾和在线扩展中被反复验证过。

换句话说，国内经验只有从“身份标签”翻译成海外客户能够感知的业务价值，才会成为出海优势。DANA买的不是一套“中国方案”的简单复制，而是一套已经解决过类似问题的方法。

BNC：基础软件出海，卖的是一套交付体系

如果说DANA是互联网钱包长大以后“原有架构开始扩不动”，BNC面对的则是更复杂的任务：一家传统银行要在不停业的前提下，把面向线下和传统存贷业务的核心能力，重新接到数字银行时代。

BNC前身是Bank Yudha Bhakti，有三十多年银行经营历史。2020年前后，BNC开始加速向数字银行转型，随后上线neobank应用。公司投资者资料显示，2023年底neobank注册用户为2560万，到2024年底进一步增至2860万。用户增长的同时，产品也从传统存贷延伸到数字支付、商户服务和企业金融等更多场景。

腾讯云公开的BNC客户案例将当时的挑战概括为海量数据、高频交易，以及原有数据架构不足。BNC随后在新核心系统中引入TDSQL，并采用私有化部署。腾讯云案例目前披露，使用TDSQL后，BNC每天可处理超过500万笔交易和5万笔贷款发放。这组数据同样来自厂商材料，更适合作为项目规模的参考，而不是单独归因于某一项技术的性能结论。

真正值得拆的，也不是“TDSQL卖进了一家印尼银行”这件事本身，而是它如何被交付。腾讯云公开资料提到，TDSQL与长亮科技（Sunline）的数字银行产品iCORE进行了集成；BNC自己的2020年年报也显示，当时银行已经同时使用Alphabits（AS400）和iCore两套核心银行系统。数据库只是数字核心改造中的一层，它必须和核心银行软件、基础设施、迁移实施以及业务系统协同工作。

BNC Bank Neo Commerce线下营业场景，来源：BNC，infobanknews

从BNC的其他公开合作也能看出这一点。长亮科技、华为等企业都曾参与BNC不同阶段的数字化建设。不同厂商披露的项目范围并不完全相同，外部资料也不足以复原一张完整的生产架构图。但这种很难由一家厂商还原完整架构的状态，本身就很接近大型金融IT项目的真实面貌：它很少由一家软件公司从头包到尾，而是多个产品、实施方和本地团队共同拼出一套能运行的系统。

因此，BNC比DANA多推进了一步。DANA证明，中国数据库在复杂场景中积累的经验可以转化为产品价值；BNC进一步说明，产品价值要真正进入银行核心系统，还要被装进一套可落地的交付体系。

对基础软件企业来说，海外销售的最小单元往往并不是一个License。数据库兼容做得再好，如果没人帮助客户梳理核心系统、迁移数据、完成联调、建立灾备、培训运维团队，项目仍然很难落地。反过来，一个熟悉当地金融流程的核心系统厂商、SI或云服务伙伴，有时比多一个功能更能决定项目能不能做成。

DANA后来培养本地OceanBase DBA团队，也是同一逻辑的另一面。软件上线并不是项目终点：当地团队能不能自己维护，故障时谁能迅速响应，版本升级谁来兜底，才决定一套基础软件能不能从“海外成功案例”变成持续业务。基础软件出海真正卖出去的，是产品、迁移、本地服务和生态伙伴共同组成的交付能力。

从两个项目到一个市场

什么能复制，什么仍会卡住？

DANA和BNC很容易被包装成两个“中国数据库出海成功案例”。但如果站在准备进入印尼的厂商视角，更有价值的不是复述成功，而是拆出其中哪些条件可以复制，又有哪些条件会在下一单重新成为门槛。

最先能复制的是客户识别逻辑。数据库是典型的底层基础软件，换一次会牵动大量业务。只要现有系统“还能用”，客户通常就没有足够动力去承担迁移风险。DANA的容量和一致性压力、BNC数字核心的高频交易需求，都不是抽象的数字化愿景，而是增长以后已经出现的现实问题。对出海厂商来说，比“找大客户”更重要的，是找到痛点已经显性化的客户。

再往前一步，是把国内经验变成海外客户能够验证的结果。中国市场确实提供了极端的电商、支付和银行场景，但海外客户不会为一段成功史本身付费。强一致、高可用、在线扩容、迁移工具这些技术词，只有落到停机时间、容量增长、故障恢复、数据丢失风险和总体成本上，才会成为采购理由。

中国数据库从项目落地走向规模化市场，需要同时跨过产品、迁移、生态与监管门槛。来源：OJK规则及DANA、BNC案例；数据猿整理制图。

真正决定项目能否持续复制的，则是本地服务和生态。OJK对银行IT系统、境外处理和第三方服务商有明确要求，金融客户自身又需要长期运维。数据库厂商既要建立当地支持能力，也要和核心银行系统、云平台、SI以及其他服务商形成稳定配合。DANA和BNC两个案例看似在讲产品，最后都落回了“谁来迁、谁来运维、谁来长期兜底”。

与此同时，这个市场的门槛一点也不低。Oracle等传统商业数据库、MySQL和PostgreSQL生态，以及AWS、Azure、Google Cloud等国际云平台，都已经形成成熟的开发习惯、人才储备、托管路径和供应商关系。数据库不像前台应用，客户不会因为一个新产品参数更漂亮就轻易更换底座。

迁移本身还是一项高风险工程。系统越核心，企业越不愿成为第一批“试错者”；金融行业又叠加数据驻留、监管审批、第三方技术服务治理和采购信任等要求。因此，中国数据库即使在某些性能、成本或复杂场景上具备优势，也很难像消费互联网产品那样靠一次爆款迅速复制。

因此，DANA与BNC更适合被理解为两种已经验证的进入方式，而不是市场份额的证明：数字原生企业在业务跑得足够快后重构底层架构，传统金融机构则在数字化转型中升级核心系统。接下来真正要看的，是这些项目能否摆脱对个别工程师和个别伙伴的依赖。

印尼不是捷径，而是一块试金石

DANA和BNC的意义，不在于证明中国数据库已经拿下印尼市场，而在于把“出海机会”变得更具体：当业务增长让旧架构的风险开始可量化，客户才真正有动力迁移底层系统。

下一阶段的分水岭，是这些头部项目能否变成可复制的本地能力。如果同样的产品、迁移方法和服务体系能够进入更多银行、保险、信贷乃至其他高并发行业，案例才会真正转化为市场。

对中国数据库企业而言，印尼因此更像一块试金石——检验在中国复杂业务里磨出来的能力，能不能脱离本土市场的语境，成为海外客户持续愿意付费的产品与服务。