慕尼黑工业大学孵化的数据库团队 CedarDB，把仅有 14 人的团队带上了 TechCrunch Disrupt 的赛场，宣布推出 CedarDB Cloud 的有限可用版本。这个脱胎于著名学术项目 Umbra 的初创团队，试图用一套引擎同时通吃事务处理与重度分析，并把当前最大的卖点押注在 AI Agent 上。
数据架构师们被传统的两套体系折磨了太久：一边是处理订单和扣款的操作型主库，另一边是拉取报表的数据仓库，中间横亘着脆弱易断的同步管道。当自主运行的软件代理需要在几毫秒内既记录对话状态，又去翻检海量历史账目时，单引擎混合处理的设想显得极为诱人。然而学术跑分与生产高可用之间，从来隔着一道鸿沟。
单引擎收拢，还是存算解耦
CedarDB 的核心杀手锏是其自研的 Colibri 存储架构。它在同一个进程内部切分冷热：新写入的活跃记录走针对点查点写的行式存储，随着时间推移变冷的数据则在后台自动压成列式，依靠多版本并发控制提供默认的快照隔离。在官方给出的测试里，基于 AMD EPYC 7713 处理器的 1 TiB 内存顶配物理机上跑 TPC-C 测试，其事务吞吐量达到了原生 PostgreSQL 的 3 倍，混合测试下的吞吐提升更标称达到 18 倍，连带将模型生成 SQL 的查询成本拉低了 61%。
巨头 Databricks 也在盯着同样的问题，但走了一条完全相反的道路。Databricks 提出的 LTAP 架构，核心是让湖仓共享单份底层存储，把事务写入与重度分析剥离给不同的计算集群。
单引擎省去了跨系统的数据搬运，代价则是算力调度的走钢丝。一旦复杂的报表分析瞬间吃满 CPU，线上正在排队的事务写入便面临延迟失控的危险。
协议仿真的代价与残缺的护城河
对外宣传时，团队强调对开源数据库标准的兼容，借此降低客户代码改造门槛。但细究技术实现，整个软件内部没有一行原生代码，它只是在网络协议层和部分语法层面做了一层高度定制的仿真壳。
兼容协议只解决了连得上的问题，留不住生态才是工程落地的真正关隘。
这层外壳目前依然相当薄弱。它完全无法运行过程语言、不支持触发器、没有严格的串行化隔离级别，且无法直接加载外部生态插件。即便对于大模型应用最依赖的高维向量检索，也无法随意挂载社区成熟方案。
| 评估维度 | 原生主流数据库集群 | CedarDB 生产现状 |
|---|---|---|
| 灾难恢复 | 具备成熟 PITR（时间点恢复）与热备 | 仅支持实验性备份与简单保存点 |
| 高可用性 | 成熟的跨可用区自动故障转移 | 自动漂移与读副本仍在规划中 |
| 插件生态 | 支持任意社区动态编译扩展 | 无法直接加载外部扩展 |
| 编程能力 | 完整存储过程与触发器机制 | 完全不支持内置过程语言 |
- 风险.生产系统最怕的不是慢，而是无法挽回的账目损坏；该项目在过去一段时间内仍持续修补异常关机导致的数据损坏与快照不一致缺陷，目前远未达到核心账本系统的可靠标准。
云上账单与商业化的真正考验
资本市场对其技术底蕴寄予厚望。公司在 2025 年 5 月拿到了 Amplify Partners 领投的 530 万欧元种子轮融资。本次云服务首发支持 AWS 欧美区域，官网上给出的入门规格预估定价为 306 美元/月（包含 300 美元计算实例与 6 美元基础存储）。
虽然在展会上高调亮出云版本，但其控制台页面仍挂着等候名单，实际处于极小范围的白名单测试状态。面对 Databricks 这样手握完备数据生态的对手，14 人的初创编制显得十分吃紧。更现实的阻碍在于硬件边界：那些令人咋舌的性能倍数，全是在堆满内存的高规格裸金属服务器上跑出来的理想数字。一旦扔进资源争抢严重的公有云多租户环境，能否守住吞吐优势仍待验证。
- 建议.对于正在研发混合智能体业务的工程团队，眼下将其作为挂载在主库旁路的高性能只读分析加速层是合理的尝试，但切忌在具备完整的灾难恢复机制之前，贸然迁移主写入节点。