Kimi给百万用户各配一个数据库，怎么做到的？

八年前，一个数据库实例每月十几美元是行业常识。现在Kimi K2.6的Agent模式里，你随口说句话，5分钟后就能拿到一个带独立数据库、用户体系、可真实访问的网站——而且这套东西的成本结构，居然能让百万级用户规模跑得通。

这不是魔法。背后是TiDB Cloud的一套多租户架构，把"每个用户一个数据库"这件事，从经济不可能变成了商业可行。

我们先看看Kimi K2.6到底在做什么。当你在Agent模式里说"帮我搭个读书笔记网站，带登录和搜索，能导出"，系统返回的不是代码片段或静态Demo，而是一个完整URL。前端、后端、数据库、账号体系全部就绪，朋友注册后存入的数据，会落在你专属的独立数据库里。相比v0或Lovable这类AI建站工具，Kimi实际上接管了从开发、托管到数据库运维的全生命周期。

但这种体验背后，工程挑战才刚刚开始：100万个用户随口提需求，就意味着后台要瞬间承载100万个独立的生产级数据库，被真实用户长期读写。在传统数据库的产品形态下，这种工作负载量几乎无法承接。

拆解这个场景的工程约束，有三条特别刺眼的要求。

第一条，数据库实例的粒度是"每终端用户一个"。十万用户就是十万个数据库，一百万就是一百万个。而且绝大多数实例会长期处于极低活跃状态——用户建完站可能很久不再打开。按传统云数据库定价，最小实例每月十几到二十美元，乘以百万，账单天文数字。问题不是数据库贵，是商业模型无法规模化。

第二条，数据库的schema由LLM现场生成。过去二十年，schema设计是需要DBA、需要review、需要版本管理的慢决策流程。在Kimi K2.6这里，schema是LLM对用户自然语言的即时翻译："读书笔记需要什么字段？""评分存整数还是文本？"瞬间决定。更棘手的是用户会继续对话——"帮我加个收藏功能"，Agent又要动表结构。此时数据库里已有真实用户数据，schema改错轻则查询失败，重则数据不可恢复。

第三条，负载分布是"零-峰两极"。大多数站建完就闲置，但只要有一个站被小红书推荐或被X平台热转，瞬间并发可以跳到百倍以上。数据库必须同时扛住"绝大多数近乎零、少数瞬间爆量"的极端曲线，且爆款租户不能拖垮其他所有租户。

这三条合在一起，传统数据库几乎无解。

路径A，单实例+schema隔离：几百个租户还行，几万个直接打爆查询规划器，爆款站还会连累邻居。Kimi工程团队实测过这条路——用一个大型PostgreSQL实例做多schema隔离，单实例在万级规模时就开始扛不住，更不用说复杂的流控、故障半径控制、数据隔离等深层问题。

路径B，一个用户一个RDS实例：不管是RDS还是Neon/Supabase这类Serverless PG包装，本质都是为每个用户分配真实PostgreSQL实例。到百万级租户，单是实例存在的基础月费就已不可接受。

Kimi后端最终落在了TiDB Cloud上，做了三个关键决策。

决策一，极致低成本——用Serverless Cluster的多租户能力承接"每个用户一个独立数据库"。既然问题出在"每用户一个真实实例"，TiDB Cloud引入了一层"虚拟数据库界面"。长尾的、绝大多数时间没请求的租户，平台并不真实分配数据库实例；只在Agent或终端用户实际发起请求的瞬间，由常驻的DB Session Gateway维持连接，其他资源全部弹性供给。这让"百万用户的建站后端"在单位经济上跑得通。

决策二，统一技术栈——vector+SQL+JSON把Agent的"写代码"难度压下来。Kimi K2.6建站Agent里，LLM写出的典型查询经常在一条SQL里同时做多件事：按用户过滤、按标签筛选（JSON字段）、按向量相似度排序、按时间倒序。在分离的栈里，同样需求要LLM协调三个client、自己做事务、自己合并结果，错误率指数级叠加。而在TiDB里，这是一条SQL。统一栈的价值不是"性能更好"，而是让Agent有机会把代码写对。

决策三，最小化摩擦——Warm Pool+scale-to-zero让Agent在1秒内拿到完全准备好的数据库实例。数据库创建不能是需等待几分钟的provisioning流程，而应像运行时资源：需要时立刻可用，用完后成本足够低。TiDB Cloud通过Warm Pool预先维护一批已完成底层准备的Starter实例，Kimi需要时直接从预热池分配；叠加Starter scale-to-zero能力，闲置实例计算成本压到很低。这让一用户一实例不仅在隔离和成本上成立，也在体验上成立——Agent可在1秒内拿到fully prepared instance，继续生成schema、写入数据、启动应用，无需把等待、轮询、失败重试写进代码。

这不是Kimi一家的选择。放在更大坐标系里看，这是一条正在形成的行业曲线上的一个点。

一个平台侧数据：今天在TiDB Cloud上新建的集群里，超过90%是由AI Agent直接创建的，而非人类工程师。这个比例一年前还远没这么高。

数字背后是一批AI Agent团队做完基建选型后，不约而同走向同一类架构。去年，某全球知名AI Agent平台选择TiDB作为核心数据层，并在技术博客和开发者社区公开架构细节，当时讲的是"Agent用数据库作为工作台"。更早，Dify这家做LLMOps的低代码平台公司，过去为每个开发者租户分配独立数据库容器，规模到一定程度后扛不住运维，最终把所有租户合并到一套TiDB Cloud上：基础设施成本降80%、运维负担降90%。

今年，Kimi K2.6把TiDB用到了更极致的场景——不是给开发者做工作台，而是给终端用户直接交付生产级应用。这是Agent时代数据库商业化的一个新拐点：当AI开始直接面向C端生成可运行的软件，底层数据基础设施必须重新回答"规模、成本、体验"的不可能三角。

传统数据库的假设是"人类工程师设计schema、长期维护、负载可预测"。Agent时代的假设完全相反：schema由LLM即时生成、无人长期维护、负载零-峰两极。这不是同一套产品的微调，是底层架构的代际切换。

Kimi的选择说明，这个切换已经开始。