Kimi百万用户建站背后：一套数据库架构如何撑住"人手一个库"

八年前，一个开发者想搭个带数据库的网站，得先买服务器、配环境、装MySQL、写ORM代码，折腾两三天是常态。今天你在Kimi K2.6的Agent模式里丢一句话——"帮我搭个读书笔记网站，带登录和搜索，能导出"——五分钟后，一个真实可访问的URL就甩到你面前。前端、后端、独立数据库、用户账号体系全套齐备，朋友注册后存入的数据，稳稳躺在你的专属库里。

这不是Demo，是生产环境。Kimi实际上接管了从开发到托管再到数据库运维的全生命周期。但真正的工程挑战才刚刚开始：100万用户随口提需求，后台就要瞬间承载100万个独立的生产级数据库，被真实用户长期读写。在传统数据库的产品形态下，这种工作负载几乎无法承接。Kimi是怎么做到的？

拆解这个场景的工程约束，三条红线特别刺眼。第一条，数据库实例的粒度是"每终端用户一个"。十万用户就是十万个库，一百万就是一百万个，而且绝大多数长期处于极低活跃状态。按传统云数据库定价，一个最小实例每月十几到二十美元，乘以百万，账单天文数字。问题不是数据库贵，是商业模型无法规模化。

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

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

这三条合在一起，传统路径几乎全死。路径A，单实例+schema隔离：几百个租户还行，几万个直接打爆查询规划器，爆款站连累所有邻居。Kimi工程团队实测过，用一个大型PostgreSQL做多schema隔离，万级规模就开始扛不住，流控、故障半径控制、数据隔离更是无从谈起。路径B，一个用户一个RDS实例：到百万级租户，单是实例存在的基础月费就已不可接受。

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

决策二：统一技术栈，把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时代数据库的演进方向。