GBASE 正“悄悄”入局 AI 赛道
digoal约 10 分钟刚刚参加完 GBASE 的22周年产品发布会, 之前对南大通用的理解还是太肤浅了, 我觉得这就是一家和 Oracle 一样的老牌关系数据库厂商, 通过三款主力产品 Gbase 8a、Gbase 8s、Gbase8c 主要服务于那些“老掉牙”的行业和金主客户.
真没想到啊, 这家成立了22年的国产数据库厂商, 正在用一个"多模多态"的架构, 悄悄卡住AI智能体时代的记忆层生态位。
今天就让我来掰开说一说，更多信息可阅读官号文章：全栈自研迭代 全域场景落地 | 2026GBASE技术云享会圆满举行
一、引子
2026年6月25日, 天津。
南大通用22周年产品发布会上, 一个观点让我印象深刻——信通院人工智能研究所的姜春宇说了这样一段话:
"以后接下来很多应用的拉起, 可能都不是人, 都是智能体在跟数据库做交互。我们怎么去构建智能体原生的数据库？这是一个必然的趋势。"
这段话看似平常, 但如果把它放在一个更大的背景里去看——全球79%的组织已经启动了AI Agent部署(Gartner 2025-2026数据), 企业级AI Agent市场在2026年已达820亿美元——你会发现一个耐人寻味的事实:
数据库的用户, 正在从"人"变成"智能体" 。
过去40年, 数据库的一切设计——SQL语法、B+树索引、ACID事务——全都是围绕人的认知习惯设计的。人写查询、人等结果、人看报表。但智能体不"看"报表, 它直接读原始数据来推理; 它不等你写SQL, 它通过API毫秒级调用; 它不关心事务隔离级别, 它关心"我能在几毫秒内拿到最相关的20条记忆"。
这个转变, 恰恰是中国数据库产业一个难得的窗口。而南大通用的GBase 8C, 在产品架构上做了一组很有意思的技术选择, 让它在这场变局中占据了一个独特的位置。
二、GBase 8C的"多模多态": 不是蹭概念, 是做了十几年的技术储备
很多人对"多模多态"这个词的第一反应是——又是一个营销词汇。但如果你仔细看GBase 8C的架构, 会发现它的"多模"是在关系型领域的多种存储模式和多种部署形态上沉淀了多年的产物, 并非为了AI临时拼凑。
2.1 三种存储模式: 行存、列存、行列混存
GBase 8C原生支持三种存储模式:
行存用于OLTP的订单实时处理; 列存用于报表和分析场景; 行列混存(HTAP)则是通过分布式的多个副本, 部分副本用行存(高效事务), 部分副本用列存(实时分析), 在同一个数据库中同时支撑TP、AP和HTAP三类场景。
这意味着什么？一个中等规模的企业, 不需要买三套数据库系统, 一套GBase 8C就够了。 这对IT运维能力较弱的中型企业来说, 系统架构简化的价值远大于技术参数本身。
2.2 三种部署形态: 单机、分布式、存算分离
三个关键设计:
第一, 单机到分布式的平滑切换。 系统建设初期用单机, 业务增长后无需数据迁移即可切换到分布式——这是一个被很多企业低估但实际非常有价值的能力, 因为它意味着初期硬件投入可以很低, 随着业务增长再弹性扩容。
第二, 原生的分布式架构。 GBase 8C不是基于中间件的分布式方案, 而是原生分布式——计算节点之间可以直接进行数据交换。对比某些基于中间件的方案(限制单表关联不能超过3个、大表查询不能超过3个、某些查询必须带主键), GBase 8C几乎不需要改造SQL, 用集中式数据库的使用体验来使用分布式数据库。
第三, 存算分离。 这是2024-2025年新增的部署形态, 正是为了应对AI时代的挑战。
三、AI Agent时代对数据库的四重暴击
在发布会上, 张益(南大通用GBase 8C产品线负责人)用了整整40分钟来讲一件事: AI时代给数据库带来了哪些全新的挑战。总结起来是四重暴击:
3.1 数据规模爆炸
训练数据超过PB级已经是常态, 企业的非结构化数据(文档、图片、音视频)增速远超结构化数据。传统数据库的单机容量根本撑不住。
3.2 并发量级暴涨
大量AI Agent和数字员工并发访问数据库。以前一个企业核心系统几百个并发顶天了, 现在数字员工带来的并发可能达到百万级别。传统存算一体的数据库架构, 没有任何一个能撑住这种冲击。
3.3 多模态数据融合
用户不再只查结构化的"订单金额", 而是同时需要——向量搜索(语义相似)、 全文检索(关键词匹配)、 关系查询(精确匹配)、 图遍历(实体关联)。一个SQL要能同时处理这四种检索方式。
3.4 毫秒级推理响应
Agent做决策需要实时数据——T+1的数据分析在AI时代等于无效信息。数据流转延迟必须从小时级降到秒级甚至毫秒级。
针对这四重暴击, GBase 8C给出的答案是存算分离架构。
四、存算分离+向量引擎: GBase 8C为Agent时代做的技术储备
4.1 存算分离: 应对百万级Agent并发
GBase 8C的存算分离架构核心思路是:
存储层: 采用分布式存储(理论上无存储上限), 数据持久化在低成本存储上 计算节点: 完全无状态, 可以秒级拉起和销毁 弹性能力: 支持Scale to Zero, 极端情况下计算成本可以降到零
这对AI Agent场景的价值是什么?
大量的Agent频繁创建和销毁数据库连接, 无状态的计算节点可以在需要时秒级拉起、用完即销毁。这就让百万级并发在理论上变得可行——你不需要为每一个Agent预留一台服务器, 只需要一个足够大的计算节点池按需分配。
4.2 数据分支: Agent间的"沙盒隔离"
这是一个创意十足的设计——参考了Git的版本管理思路。
每个Agent可以在主线数据上拉出自己的数据分支, 在自己的分支上做各种计算和决策。绝大多数情况下, Agent的分析结果可能没有价值, 直接销毁分支即可, 不影响主线; 如果结果有价值, 再commit回主线。
这个设计不仅仅用于AI Agent。金融机构做预跑批时, 传统做法是把主生产库做一个镜像到准生产库, 跑完再删除——数据流转既慢又有安全风险。有了数据分支, 可以直接基于分支跑批, 结果验证后直接在主库生效, 数据不用搬运, 计算不用重复。
4.3 向量+标量融合检索: 一个SQL搞定
GBase 8C的向量引擎是把向量当成一个原生数据类型, 和整数、字符串一样, 可以直接在SQL中使用。
来看一个真实场景——"听歌识曲":
传统的做法:
语音识别 → 生成音频向量 到专用向量数据库检索相似向量 → 拿到歌曲ID 再到关系数据库查歌曲信息(演唱者、专辑等) 业务代码手动合并两个结果
GBase 8C的做法:
SELECT song_name, singer, album
FROM songs
WHERE vector_distance(audio_embedding, :input_vector) < 0.1
AND album LIKE'2025%';
一个SQL, 同时做向量相似度检索和标量精确过滤。 业务不需要写两套代码、管两个数据库、手动合并结果。
南大通用官方宣称支持千亿级向量的毫秒级检索, 并配有GPU加速——实际性能还有待更多生产案例验证, 但这个"统一SQL入口"的设计方向, 对于降低AI应用开发门槛的意义是明确的。
五、Agent记忆基础设施: 一个意外的"四层对四层"
这可能是GBase 8C最被低估的一个能力。
AI智能体需要四种记忆:
传统方案需要 Redis + Pinecone/Qdrant + 关系型数据库 + 图数据库 四套系统。这不仅仅是运维复杂度的线性增加——当故障发生时, 你需要四个不同领域的DBA协同排查。这在实践中基本不可行。
GBase 8C一个集群覆盖了至少三层半, 而且统一SQL入口、统一运维、统一事务。对于正在搭建Agent平台的企业来说, 这意味着一套系统解决了四个问题。
六、从DB for AI到DB for data: 推理引擎的猜想
另一个非常值得关注的消息来自白鳝(徐戟)老师做出的一个大胆预测:
"未来除了我们现在常见的计算引擎、存储引擎之外, 可能还会有一个推理引擎。在这个推理引擎里面, 我可以直接通过select语句去驱动一个智能体, 完成一个复杂的任务流程。"
Oracle 23ai已经有了Select AI, 最新版本甚至支持通过Select AI驱动智能体。GBase 8C也在朝着这个方向演进——虽然目前是通过GBase 8C做"智能大脑", GBase 8A做数据湖, 结合BSBot自动化引擎实现select bot语法驱动智能体, 但终极目标是把这些能力打包进一个数据库。
如果"存储引擎 + 计算引擎 + 推理引擎"成为AI原生数据库的标准架构, 那么数据库就不再只是一个"存数据的地方", 而是一个能理解数据、推理数据、基于数据做决策的认知引擎。
七、湖仓事务分析一体化: 让AI Agent用上实时数据
传统架构下, TP库和AP库之间隔着一个ETL管道。数据从生产库到分析库, 走完抽取、转换、加载一整套流程, 几个小时就过去了——今天只能分析昨天的数据, T+1是这个时代的常态。
但AI Agent做实时决策需要实时数据。如果一个客服Agent正在处理用户投诉, 它需要知道的是"当前订单的实时状态", 而不是"今天凌晨备份的快照"。
GBase 8C的解决方案是: 通过8C的实时镜像能力, 把TP数据用标准接口直接给到GBase 8A湖仓一体访问, TP一更新, AP立即可见, 数据流转延迟趋近于零。
这与前面提到的数据分支和存算分离结合起来, 构成了GBase 8C面向AI时代的完整技术拼图。
八、信创+AI: 一个独特的竞争生态位
如果只看技术架构, 你可能会说"这些能力云厂商也有, Oracle也有"。但GBase 8C有一个云厂商和Oracle都没有的组合:
信创合规 + AI能力覆盖。
这个定位对CIO来说有一个非常实际的价值: 一个采购项目, 同时满足IT部门的信创合规目标和业务部门的AI目标。 这种跨部门需求合并对于预算审批、立项流程的简化, 有时候比任何技术参数都管用。
再看几个真实案例:
泸州银行信贷核心系统: 替换MySQL分库分表方案, 跑批时间从2小时降至30分钟, 数据下发从3-4小时降至分钟级。
某运营商结算系统: 替换Oracle一体机, 每月处理1800亿条实时话单, 硬件成本降了一半以上。GBase 8C单节点热数据容量达10TB, 冷热混合达30TB——这意味着与某些基于MySQL的分布式方案相比, 硬件成本可以降到20%-30%。
这些案例证明的是: GBase 8C在传统交易处理场景已经经过了充分的"压力测试", AI能力是建立在成熟的关系型数据库内核之上的增量能力——而不是从零开始的"AI花瓶"。
九、为什么国产数据库可能靠AI赛道弯道超车
如果把上面的分析拉远一点看, 可以归结为三个判断:
判断一: AI正在重新定义"数据库"这个品类。 当用户从人变成智能体, 当查询从"给我精确结果"变成"帮我找到最相关的上下文", 当存储从"关系型"扩展到"向量+图+时序+关系"——传统的数据库评价体系(TPC-C跑分、ACID严格度)都需要被重新审视。
判断二: 在新的评价体系下, 中国数据库和国外巨头的差距在缩小。 Oracle在关系型领域积累了40年的工程优势, 但在AI原生数据库这个新品类里, Oracle 23ai也才刚刚起步(Select AI是2024年才发布的)。差距没有那么大了。而且中国有全球最大的信创市场作为"基本盘", 为国产AI数据库提供了独一无二的试验场。
判断三: GBase 8C的"多模多态+存算分离+信创合规"组合, 占据了一个结构性的生态位。 GBase 8C是目前唯一一个同时站在两个圈子里的产品——虽然AI原生能力还在路上, 但方向和架构是对的。
十、写在最后: 弯道才刚刚开始
说"国产数据库在AI赛道弯道超车", 并不是说某个产品已经成功了。事实上, 连"AI原生数据库"这个品类都还没有公认的定义, GBase 8C的向量引擎和内存引擎也还需要更多生产案例来验证成熟度。
但让我觉得值得写这篇文章的原因, 是发布会上一个很小的片段:
丁明峰(董事长)在开场时说, "对未来说, 大家都不是神仙。"
张益在介绍完8C的技术架构后说了一句:"AI原生的数据库还在路上, 我们在这条路上不断往前演进, 不断去逼近这个目标。"
白鳝老师在演讲结尾时说:"算法加数据结构等于程序。未来的话, 数据库加业务规则就等于业务系统。 如果真能做到这一点, 那数据库才真正回到了舞台的最中心。"
这些话语里没有"遥遥领先"式的豪言壮语, 而是一种对技术方向有判断、对自身能力有清醒认知的务实态度。
22年前, 南大通用从天津起步, 做国产数据库; 今天它在AI赛道上找到了属于自己的弯道——信创合规为底盘, 多模多态为引擎, Agent记忆为方向。
弯道超车, 靠的不是某个"杀手级功能", 而是在正确的方向上一代一代迭代产品。从这个角度看, GBase 是非常务实的。