上个月帮一个做Agent平台的朋友过了遍数据库选型发现网上能看到的对比内容绝大部分还在聊TPC-C分数和P99延迟。但AI/Agent场景的负载和传统Web后端完全不是一回事几十个并发用户能把一个小库的连接数打满同一张表里既有JSON半结构化字段又有embedding向量列业务上线三个月Schema改了快二十回。拿老一套基准测试往这个场景硬套方向就错了。这篇我想把PolarDB、Aurora、TDSQL-C、TiDB四款数据库放在Agent应用的坐标系里做一次四维对比。重点不是数据跑多快而是协议生态、弹性连接、向量检索、运维成本这四个和智能体工程真正强相关的能力。适合正在做Agent应用选型、又不想一上来就分库分表的外包团队、初创团队和个人开发者。1. 先想清楚Agent应用的数据需求到底变形在哪选库之前得先说清楚Agent应用让数据库承受了什么“非典型压力”。我接触过不少团队上来就用以前做电商、做SaaS那套思维去建表、定连接数结果压测一跑就露馅。1.1 连接密集会话与工具编排让连接数成了第一瓶颈传统Web应用是“用户请求 → API网关 → 业务逻辑 → 数据库”连接基本集中在后端服务这一层用一个连接池就能压得住。Agent应用不一样一个任务进来编排器要调度多个子Agent每个子Agent又要调用若干工具工具里只要有一步要查库就会产生数据库连接。更麻烦的是多租户SaaS模式下每个租户的工作区都可能有独立的数据库连接诉求。我见过一个内测只有二十人并发的Agent服务因为部署了多个Agent实例、每个实例连接池默认又开了十几条连接直接把一个默认max_connections只有151的小库打满应用层全是“Too many connections”。这跟QPS没关系纯粹是连接模型变了。所以这次选型对比里连接数的上限、连接池的支持、以及是否自带Proxy都是优先项。1.2 半结构化和向量数据表结构不再是“列对齐”的传统形态Agent应用的核心数据大致逃不出四类会话/状态数据Agent的上下文、工具执行状态、当前步骤天然适合JSON或JSONB用户/租户数据经典关系型结构靠主键关联知识库切片正文内容、embedding向量、标题、来源、权限标签向量列和标量字段混在一张表里任务/执行日志Agent名、状态、Token消耗、耗时写入量大且有分析需求。这四类数据往往要在同一个库里共存。以前做业务系统可以把日志扔ES、把关系数据放MySQL、把状态放Redis。但Agent应用刚起步时团队根本不想维护那么多组件于是“一个库扛多模”成了刚需。这就对数据库的JSON处理能力和向量存储能力提出了硬要求。1.3 读写混合事务、分析、检索在同一份数据上发生Agent系统的读路径很重恢复会话要读状态、RAG要读知识库向量、拼上下文要读历史记忆。写路径也不轻每次对话要写执行日志、每轮Agent决策可能要落记忆、知识库更新要批量写入向量。更麻烦的是产品经理随时会提需求“帮我统计一下最近七天各Agent工具的成功率”这就是典型的分析型需求。这种混合负载让数据库不能只偏OLTP也不能只偏OLAP最好有点HTAP的意思。Aurora、PolarDB、TDSQL-C、TiDB的架构差异在这里会放大成完全不同的使用体验。2. 四款数据库的架构血缘先看清各自底牌选型之前先把四款产品的架构底牌摸清楚后面说差异就不容易糊涂。2.1 Aurora、PolarDB、TDSQL-C同一套云原生共享存储路线2014年AWS推出Aurora时核心思路是“日志即数据库”计算节点不落数据文件只把日志持续传给分布式存储存储层自动完成多副本复制和故障恢复。这样有几个直接好处网络传输量大幅下降增加只读节点不再需要拷贝数据存储层天然具备跨可用区容灾能力。PolarDB和TDSQL-C虽然在具体实现上有大量自研但整体走的都是同一个路线计算存储分离、一写多读、存储层多副本。区别在于Aurora兼容MySQL和PostgreSQL一个写节点加最多15个只读节点AWS生态内集成度高PolarDB兼容MySQL和PostgreSQL还做了多主多写特性阿里云生态内和DMS、DTS这些工具的磨合更顺TDSQL-C兼容MySQL和PostgreSQL腾讯云主打同城双可用区部署和自动故障切换和CVM、TKE这些基础设施配合自然。这条路线本质上是把单机数据库搬上云分布式存储让单实例的可用性和弹性上了个台阶但SQL层仍然是“单写多读”的逻辑写入扩展能力有天花板。2.2 TiDB真正的无共享水平扩展路线TiDB和上面三款是两套物种。TiDB本身不存数据它由三层组成TiDB Server负责SQL解析和优化TiKV负责分布式键值存储PD负责集群调度TiFlash则提供列存副本。数据会自动按Region分片打散到多个TiKV节点上通过Raft协议保证强一致。这意味着TiDB可以同时增加SQL节点和存储节点写入能力是水平扩展的读取也可以分散到多个副本上。加上TiFlash列存之后一条SQL可以根据代价选择走行存还是列存是这一代里最接近“原生HTAP”的架构。TiDB还有一点很特别Apache 2.0开源可以自己部署也有TiDB Cloud的Serverless形态。2.3 一张表读懂四者定位差异维度AuroraPolarDBTDSQL-CTiDB产品方AWS阿里云腾讯云PingCAP开源情况商业商业PG开源版不完全等价商业Apache 2.0开源协议兼容MySQL / PostgreSQLMySQL / PostgreSQLMySQL / PostgreSQLMySQL协议核心架构共享存储一写多读共享存储一写多读/多主多写共享存储一写多读无共享水平扩展分析能力依赖只读节点只读节点部分内核优化只读节点TiFlash列存MPP最典型的场景AWS生态内Agent应用阿里云生态内业务库腾讯云生态内业务库超大规模数据、高并发写入3. 维度一协议兼容与生态接入决定团队开发效率第一个对比维度也是最容易被忽略的你的Agent代码、中间件和团队技能树能不能顺畅地接到这个数据库上。3.1 MySQL协议与PG协议在Agent工程里的实际差异四款数据库里TiDB只兼容MySQL协议而Aurora、PolarDB、TDSQL-C都同时提供MySQL和PostgreSQL两个方言版本。所以真正的选择不是“选哪个产品”而是“你的团队要站在哪种方言之上”。MySQL体系的优势是普及率DBA好招、驱动遍地都是、云厂商的监控和慢日志体系最成熟LangChain、LlamaIndex、Spring AI这些框架的SQL工具对MySQL的支持都是默认顶点。PG体系对Agent应用更友好JSONB处理半结构化状态数据比MySQL顺手pgvector做向量检索基本是AI应用的事实标准tsvector全文检索能力也扎实。你可以用一条SQL同时完成向量相似度检索和关键词召回这种能力在MySQL生态里通常要靠外挂方案补齐。所以我的建议很直接如果团队已经有明确的MySQL/PG技能栈尊重技能栈如果是从零起步做AgentPG方言版本在数据建模和检索上的优势值得优先考虑。3.2 从LangChain、Spring AI到MCP中间层接入要注意的细节现在开发Agent应用几乎没有团队完全绕开LangChain、Spring AI或者LangGraph这类编排框架底层工具访问越来越多人走MCP协议。数据库通常不会直接暴露给大模型而是被封装成工具。我在接MCP数据库工具时踩过的坑直接暴露连接串让LLM生成SQL并执行结果是模型偶尔会生成不带WHERE条件的删除语句。这不是数据库的问题而是中间层设计的问题。正确做法是做一个数据库工具服务把操作白名单化例如只允许执行SELECT、只允许访问指定视图、自动加LIMIT、强制查询超时。选型时要评估数据库对“这种中间层接入”的配合程度——MySQL和PG系产品都有成熟的JDBC/驱动支持TiDB则在LangChain生态里有官方Loader和VectorStore集成。4. 维度二弹性扩展与连接模型决定系统能撑多大流量Agent应用的真实瓶颈往往不是数据量大而是连接数和流量的突发性。这一维度直接决定你压测、上线时会不会半夜被报警叫醒。4.1 Serverless形态的弹性响应速度四款都有Serverless形态。Aurora Serverless v2按ACU计费最小0.5 ACU起步伸缩粒度已经到秒级PolarDB Serverless按PCU计费支持秒级弹性TDSQL-C Serverless支持自动启停和按CCU计费TiDB Serverless则按RU弹性计费理论上完全按需付费。Serverless对Agent应用的最大价值不是省钱而是扛“突发”白天有人调Agent时流量忽高忽低夜间批量任务又可能把配置顶上去。这个场景里Serverless基本是标准答案。但要提醒一句不少Serverless实例缩容到0之后第一个请求要经历几秒到几十秒的冷启动对实时对话类Agent体验是灾难。我的做法是设定最小容量不缩到0或者用连接保活机制钉住实例。4.2 连接数上限和读写扩容的真实差距连接数这块MySQL和PG系产品的默认max_connections通常不高Agent应用多实例部署后连接被占满是家常便饭。应对手段有三层应用层连接池HikariCP、DBCP必须配好数据库侧如果有Proxy就开ProxyAurora有RDS ProxyPolarDB自带集群连接地址TDSQL-C也有Proxy最后才是调大max_connections但这会消耗CPU和内存不能无脑拉高。TiDB的模型不同前端可以挂多个TiDB Server节点连接分散上去天然适合高并发短连接。但每个TiDB节点也有连接上限中间依然建议加一层负载均衡。读写扩展上Aurora、PolarDB、TDSQL-C加只读节点很快但写入口始终是主节点TiDB则可以从容增加TiKV节点提升整体吞吐。Agent应用绝大多数场景是读多写少前三者够用如果Agent业务要记录海量决策日志、操作轨迹写入量大TiDB的扩展性优势会凸显出来。4.3 一个容易被忽略的点故障切换与连接重连Agent执行链路通常很长一个编排任务可能要串好几轮工具调用中间数据库如果主备切换应用层没有正确的重试机制整个任务就断了而且可能重复扣费、重复执行。从数据库侧看Aurora、PolarDB、TDSQL-C的主备切换都在秒级TiDB通过Raft自动选主也能快速恢复。但关键是应用侧必须做到事务要有重试连接池要配置探活调用方要设计幂等。这一点和选哪家数据库关系不大但很多Agent框架本身不处理这个问题项目里一定要有人专门负责。5. 维度三向量检索与AI原生能力决定Agent记忆和RAG的上限这个维度是Agent选型区别于传统业务选型的核心分水岭。但我要先打破一个迷信不是“能跑向量”就等于适合做Agent知识库。5.1 四款数据库的向量能力盘点Aurora、PolarDB、TDSQL-C三者都有PostgreSQL版本因此都能用pgvector扩展支持HNSW索引和余弦、欧氏、内积等距离函数。Aurora PostgreSQL pgvector基本是海外AI Demo的标配PolarDB for PostgreSQL和TDSQL-C for PostgreSQL在PG生态内同样能用国内云厂商还会做一层SQL化封装。MySQL版本这边三款都没有原生向量能力Aurora MySQL、PolarDB MySQL、TDSQL-C MySQL要做向量检索基本只能外挂独立向量库。TiDB比较特殊它兼容MySQL协议但从8.x版本开始提供内置向量类型、向量索引和距离函数不需要额外扩展还支持向量与普通标量字段在同一个SQL里组合过滤。这对MySQL技能的团队相当友好。5.2 纯向量检索不够用混合检索才是知识库的核心向量检索对语义相似很有效但对精确关键词、专有名词、型号代码这类内容经常“翻车”因为embedding对罕见词不敏感。生产级RAG知识库基本都要走混合检索向量召回候选集 全文检索/关键词匹配 重排。PG生态在混合检索上优势明显pgvector做语义召回tsvector或pg_bigm做全文检索再加一个普通WHERE做元数据过滤三者在同一条SQL里就能完成开发量很小。MySQL生态的全文索引能凑合用但向量那块必须外挂链路就复杂了。TiDB内置向量后语义召回和标量过滤很顺但全文检索能力相对有限如果业务重度依赖BM25这类关键词召回还是要评估。5.3 向量规模不同选型完全不同向量检索方案还要看数据量级百万级以内、维度768以下pgvector的HNSW完全能扛不用外挂任何独立向量库千万级Pgvector需要仔细调参和配置内存TiDB内置向量或独立向量库更稳过亿基本要上专门向量数据库。另外embedding维度别无脑选1536甚至3072维度高一个量级表空间和内存开销可能翻四五倍。我的经验先用768或1024维的模型把第一版跑起来等业务稳定了再评估要不要换高维度模型。否则建索引慢、查询延迟高、存储成本还涨得飞快。6. 维度四运维成本与长期开销决定方案能不能活到收益期选型很容易上头看参数但真正决定一个方案能走多远的往往是运维复杂度和账单数字。Agent应用迭代节奏快这块更需要提前想清楚。6.1 托管形态下的备份、升级、容灾差异Aurora、PolarDB、TDSQL-C都是云厂商全托管自动备份、跨可用区容灾、内核小版本升级基本都是标配。PolarDB有多地域的GDN方案Aurora有Global DatabaseTDSQL-C有同城双可用区集群跨地域灾备能力都在线。TiDB如果自建运维复杂度会明显高出一截——TiDB Server、TiKV、PD、TiFlash四个组件都要盯但TiDB Cloud托管形态也把这块简化了。对Agent应用来说比灾备更实际的是Schema变更。Agent业务迭代快加字段、改索引、调整JSON结构非常频繁。PG系和MySQL系云产品在Online DDL上有优化但大表加字段还是要留意锁和复制延迟TiDB借助分布式架构在线变更对业务影响更小。如果你们的Agent应用预期数据量增长很快这一条值得重点加权。6.2 账单里的三个常见成本陷阱第一Serverless最小容量。为了方便突发流量很多人把最小容量设得偏高结果低峰期也一直在计费月底账单远超预期。建议根据真实流量监控逐步下调。第二跨AZ流量和只读副本费用。上只读节点做读写分离后主备之间跨可用区数据同步会产生流量费低峰期也不便宜。不要把只读副本当一个“备用节点”挂在那儿如果确定用不上尽早释放。第三向量表的存储膨胀。一张带1536维向量列的表单行可能超过6KB比普通关系表大一个数量级。云数据库按存储容量计费这部分的月度开销很容易被低估。7. Agent场景落地姿势库表设计、连接池与SQL层面的实战注意选好库只是第一步怎么用才是真正拉开差距的地方。这里分享一些Agent项目里被反复验证过的落地细节。7.1 四类核心数据的建表思路会话状态表核心是支撑“断点续聊”和“多轮工具调用”。主键用UUID状态字段用JSON/JSONB更新时间加索引查询时按user_id加updated_at排序取最新会话。PG的JSONB在这里比普通关系列更灵活因为不同Agent工具链产生的状态结构差别很大用列存储会不断改表。Agent记忆表是向量检索的主战场。核心字段是user_id、content、embedding向量、记忆类型、创建时间。这里要注意索引顺序先用user_id过滤再走向量索引避免全库扫描。SQL大致是SELECT content, embedding :query_embedding AS distance FROM agent_memories WHERE user_id :user_id ORDER BY distance LIMIT 5;千万别把user_id过滤放到向量检索之后否则数据量一大就卡死。任务日志表最容易被忽略却是Agent应用里增长最快的表。执行状态、Token消耗、延迟、Agent名这些字段都要有按时间分区几乎是必须的。如果未来要做链路分析TiDB的TiFlash列存会自动帮你把分析查询加速PG/MySQL系则要考虑定期归档。知识库文档表混合检索的核心场景。chunk_id、content、向量、来源、权限范围、embedding模型版本都要存。知识库更新时embedding模型如果换了版本向量空间直接失效必须重新生成——这个坑我踩过不止一次所以embedding_model字段一定不要省。7.2 连接池、超时和查询约束稳定性的三个基本盘连接池参数上Agent服务的连接池不建议把maximum-pool-size设得过高20左右足够关键是minimum-idle要合理否则频繁建连反而拖慢冷启动。SQL超时一定要配。PG用的是statement_timeoutMySQL系用max_execution_time。一旦LLM生成的SQL里出现笛卡尔积或全表扫描超时是最后的救命稻草。工具暴露给Agent的SQL接口权限必须收口。给Agent只读账号连接串不落LLMSQL白名单视图只暴露业务需要的字段。这一步不做再贵的数据库也救不了“一条DELETE不带WHERE”的Agent事故。批量写入向量时分批加指数退避重试。一次性插入几万条1536维向量很容易触发内存压力或写入超时。我的经验是每批500到1000条间隔几毫秒稳定性最好。TiDB那边还可以打开rewriteBatchedStatements参数批量写性能提升非常明显。7.3 从实践看这几款库的适配表现坦白说在写多读少、知识库型Agent场景里PG方言产品加上pgvector是上手最快的组合一个库把事务、状态、向量、全文检索都覆盖了很少需要引入第二个存储组件。在强事务、高一致性的交易型Agent场景MySQL方言产品更稳团队对主从、备份的运维经验也更成熟。如果Agent应用一开始就注定要承载海量级记忆和日志并且要做在线分析TiDB的HTAP属性会给你省掉一套数仓的维护成本。8. 最终建议规模和阶段决定答案别把选型做成信仰之争每次写这类对比评论区总有人为“某库天下第一”吵起来。我的意见是选型本质上是拿团队现状、业务阶段和预期规模去套一个最舒服的组合。8.1 不同团队状态的参考路径如果你是单人开发者或小团队正在做Agent应用MVP优先看你手上云厂商的PG兼容产品Aurora PostgreSQL、PolarDB PostgreSQL或TDSQL-C PostgreSQL配合pgvector把知识库和会话状态放在同一个库里。这套组合能让你把精力全放在Agent逻辑上而不是运维上。如果团队已经有大流量业务经验Agent应用马上要对接真实客户建议保留单库架构开Serverless弹性配好连接池和只读节点。这一阶段不要急着分库分表数据库大概率不是你的瓶颈。如果业务注定是“大数据量级”的Agent应用比如面向百万用户长期沉淀记忆、行为轨迹、会话日志并且要实时分析把TiDB或TiDB Cloud放进架构用MySQL兼容协议降低迁移成本用TiFlash承载分析查询。这套选择能让你在数据量上天之后依然不用通宵做分库分表。8.2 我个人的倾向与理由从零搭建一套Agent应用我会首选PG兼容的云原生数据库当主力一段SQL同时搞定向量检索、全文检索和JSON状态处理开发效率最高团队不用维护多个存储组件。等业务证明需要更高写入并发和更大的数据规模再把存储层平滑演进到TiDB这一类分布式架构。有一点我想反复强调不要为了“更先进”就同时引入四五个存储组件。数据库选型是在给未来两三年的自己减少麻烦不是给简历添一行字。一个库加几张表就能跑通的MVP远比一套完美但复杂的多存储架构有价值。我自己换项目时每次选型花的时间都在缩短不是因为记住了Benchmark数字而是越来越清楚先看业务负载模型再看团队技能树最后才轮得到数据库本身。四款库都是好产品但适合你的那款一定是让你把精力花在Agent业务本身的那款。
Agent应用数据库选型：PolarDB、Aurora、TDSQL-C、TiDB四维对比
上个月帮一个做Agent平台的朋友过了遍数据库选型发现网上能看到的对比内容绝大部分还在聊TPC-C分数和P99延迟。但AI/Agent场景的负载和传统Web后端完全不是一回事几十个并发用户能把一个小库的连接数打满同一张表里既有JSON半结构化字段又有embedding向量列业务上线三个月Schema改了快二十回。拿老一套基准测试往这个场景硬套方向就错了。这篇我想把PolarDB、Aurora、TDSQL-C、TiDB四款数据库放在Agent应用的坐标系里做一次四维对比。重点不是数据跑多快而是协议生态、弹性连接、向量检索、运维成本这四个和智能体工程真正强相关的能力。适合正在做Agent应用选型、又不想一上来就分库分表的外包团队、初创团队和个人开发者。1. 先想清楚Agent应用的数据需求到底变形在哪选库之前得先说清楚Agent应用让数据库承受了什么“非典型压力”。我接触过不少团队上来就用以前做电商、做SaaS那套思维去建表、定连接数结果压测一跑就露馅。1.1 连接密集会话与工具编排让连接数成了第一瓶颈传统Web应用是“用户请求 → API网关 → 业务逻辑 → 数据库”连接基本集中在后端服务这一层用一个连接池就能压得住。Agent应用不一样一个任务进来编排器要调度多个子Agent每个子Agent又要调用若干工具工具里只要有一步要查库就会产生数据库连接。更麻烦的是多租户SaaS模式下每个租户的工作区都可能有独立的数据库连接诉求。我见过一个内测只有二十人并发的Agent服务因为部署了多个Agent实例、每个实例连接池默认又开了十几条连接直接把一个默认max_connections只有151的小库打满应用层全是“Too many connections”。这跟QPS没关系纯粹是连接模型变了。所以这次选型对比里连接数的上限、连接池的支持、以及是否自带Proxy都是优先项。1.2 半结构化和向量数据表结构不再是“列对齐”的传统形态Agent应用的核心数据大致逃不出四类会话/状态数据Agent的上下文、工具执行状态、当前步骤天然适合JSON或JSONB用户/租户数据经典关系型结构靠主键关联知识库切片正文内容、embedding向量、标题、来源、权限标签向量列和标量字段混在一张表里任务/执行日志Agent名、状态、Token消耗、耗时写入量大且有分析需求。这四类数据往往要在同一个库里共存。以前做业务系统可以把日志扔ES、把关系数据放MySQL、把状态放Redis。但Agent应用刚起步时团队根本不想维护那么多组件于是“一个库扛多模”成了刚需。这就对数据库的JSON处理能力和向量存储能力提出了硬要求。1.3 读写混合事务、分析、检索在同一份数据上发生Agent系统的读路径很重恢复会话要读状态、RAG要读知识库向量、拼上下文要读历史记忆。写路径也不轻每次对话要写执行日志、每轮Agent决策可能要落记忆、知识库更新要批量写入向量。更麻烦的是产品经理随时会提需求“帮我统计一下最近七天各Agent工具的成功率”这就是典型的分析型需求。这种混合负载让数据库不能只偏OLTP也不能只偏OLAP最好有点HTAP的意思。Aurora、PolarDB、TDSQL-C、TiDB的架构差异在这里会放大成完全不同的使用体验。2. 四款数据库的架构血缘先看清各自底牌选型之前先把四款产品的架构底牌摸清楚后面说差异就不容易糊涂。2.1 Aurora、PolarDB、TDSQL-C同一套云原生共享存储路线2014年AWS推出Aurora时核心思路是“日志即数据库”计算节点不落数据文件只把日志持续传给分布式存储存储层自动完成多副本复制和故障恢复。这样有几个直接好处网络传输量大幅下降增加只读节点不再需要拷贝数据存储层天然具备跨可用区容灾能力。PolarDB和TDSQL-C虽然在具体实现上有大量自研但整体走的都是同一个路线计算存储分离、一写多读、存储层多副本。区别在于Aurora兼容MySQL和PostgreSQL一个写节点加最多15个只读节点AWS生态内集成度高PolarDB兼容MySQL和PostgreSQL还做了多主多写特性阿里云生态内和DMS、DTS这些工具的磨合更顺TDSQL-C兼容MySQL和PostgreSQL腾讯云主打同城双可用区部署和自动故障切换和CVM、TKE这些基础设施配合自然。这条路线本质上是把单机数据库搬上云分布式存储让单实例的可用性和弹性上了个台阶但SQL层仍然是“单写多读”的逻辑写入扩展能力有天花板。2.2 TiDB真正的无共享水平扩展路线TiDB和上面三款是两套物种。TiDB本身不存数据它由三层组成TiDB Server负责SQL解析和优化TiKV负责分布式键值存储PD负责集群调度TiFlash则提供列存副本。数据会自动按Region分片打散到多个TiKV节点上通过Raft协议保证强一致。这意味着TiDB可以同时增加SQL节点和存储节点写入能力是水平扩展的读取也可以分散到多个副本上。加上TiFlash列存之后一条SQL可以根据代价选择走行存还是列存是这一代里最接近“原生HTAP”的架构。TiDB还有一点很特别Apache 2.0开源可以自己部署也有TiDB Cloud的Serverless形态。2.3 一张表读懂四者定位差异维度AuroraPolarDBTDSQL-CTiDB产品方AWS阿里云腾讯云PingCAP开源情况商业商业PG开源版不完全等价商业Apache 2.0开源协议兼容MySQL / PostgreSQLMySQL / PostgreSQLMySQL / PostgreSQLMySQL协议核心架构共享存储一写多读共享存储一写多读/多主多写共享存储一写多读无共享水平扩展分析能力依赖只读节点只读节点部分内核优化只读节点TiFlash列存MPP最典型的场景AWS生态内Agent应用阿里云生态内业务库腾讯云生态内业务库超大规模数据、高并发写入3. 维度一协议兼容与生态接入决定团队开发效率第一个对比维度也是最容易被忽略的你的Agent代码、中间件和团队技能树能不能顺畅地接到这个数据库上。3.1 MySQL协议与PG协议在Agent工程里的实际差异四款数据库里TiDB只兼容MySQL协议而Aurora、PolarDB、TDSQL-C都同时提供MySQL和PostgreSQL两个方言版本。所以真正的选择不是“选哪个产品”而是“你的团队要站在哪种方言之上”。MySQL体系的优势是普及率DBA好招、驱动遍地都是、云厂商的监控和慢日志体系最成熟LangChain、LlamaIndex、Spring AI这些框架的SQL工具对MySQL的支持都是默认顶点。PG体系对Agent应用更友好JSONB处理半结构化状态数据比MySQL顺手pgvector做向量检索基本是AI应用的事实标准tsvector全文检索能力也扎实。你可以用一条SQL同时完成向量相似度检索和关键词召回这种能力在MySQL生态里通常要靠外挂方案补齐。所以我的建议很直接如果团队已经有明确的MySQL/PG技能栈尊重技能栈如果是从零起步做AgentPG方言版本在数据建模和检索上的优势值得优先考虑。3.2 从LangChain、Spring AI到MCP中间层接入要注意的细节现在开发Agent应用几乎没有团队完全绕开LangChain、Spring AI或者LangGraph这类编排框架底层工具访问越来越多人走MCP协议。数据库通常不会直接暴露给大模型而是被封装成工具。我在接MCP数据库工具时踩过的坑直接暴露连接串让LLM生成SQL并执行结果是模型偶尔会生成不带WHERE条件的删除语句。这不是数据库的问题而是中间层设计的问题。正确做法是做一个数据库工具服务把操作白名单化例如只允许执行SELECT、只允许访问指定视图、自动加LIMIT、强制查询超时。选型时要评估数据库对“这种中间层接入”的配合程度——MySQL和PG系产品都有成熟的JDBC/驱动支持TiDB则在LangChain生态里有官方Loader和VectorStore集成。4. 维度二弹性扩展与连接模型决定系统能撑多大流量Agent应用的真实瓶颈往往不是数据量大而是连接数和流量的突发性。这一维度直接决定你压测、上线时会不会半夜被报警叫醒。4.1 Serverless形态的弹性响应速度四款都有Serverless形态。Aurora Serverless v2按ACU计费最小0.5 ACU起步伸缩粒度已经到秒级PolarDB Serverless按PCU计费支持秒级弹性TDSQL-C Serverless支持自动启停和按CCU计费TiDB Serverless则按RU弹性计费理论上完全按需付费。Serverless对Agent应用的最大价值不是省钱而是扛“突发”白天有人调Agent时流量忽高忽低夜间批量任务又可能把配置顶上去。这个场景里Serverless基本是标准答案。但要提醒一句不少Serverless实例缩容到0之后第一个请求要经历几秒到几十秒的冷启动对实时对话类Agent体验是灾难。我的做法是设定最小容量不缩到0或者用连接保活机制钉住实例。4.2 连接数上限和读写扩容的真实差距连接数这块MySQL和PG系产品的默认max_connections通常不高Agent应用多实例部署后连接被占满是家常便饭。应对手段有三层应用层连接池HikariCP、DBCP必须配好数据库侧如果有Proxy就开ProxyAurora有RDS ProxyPolarDB自带集群连接地址TDSQL-C也有Proxy最后才是调大max_connections但这会消耗CPU和内存不能无脑拉高。TiDB的模型不同前端可以挂多个TiDB Server节点连接分散上去天然适合高并发短连接。但每个TiDB节点也有连接上限中间依然建议加一层负载均衡。读写扩展上Aurora、PolarDB、TDSQL-C加只读节点很快但写入口始终是主节点TiDB则可以从容增加TiKV节点提升整体吞吐。Agent应用绝大多数场景是读多写少前三者够用如果Agent业务要记录海量决策日志、操作轨迹写入量大TiDB的扩展性优势会凸显出来。4.3 一个容易被忽略的点故障切换与连接重连Agent执行链路通常很长一个编排任务可能要串好几轮工具调用中间数据库如果主备切换应用层没有正确的重试机制整个任务就断了而且可能重复扣费、重复执行。从数据库侧看Aurora、PolarDB、TDSQL-C的主备切换都在秒级TiDB通过Raft自动选主也能快速恢复。但关键是应用侧必须做到事务要有重试连接池要配置探活调用方要设计幂等。这一点和选哪家数据库关系不大但很多Agent框架本身不处理这个问题项目里一定要有人专门负责。5. 维度三向量检索与AI原生能力决定Agent记忆和RAG的上限这个维度是Agent选型区别于传统业务选型的核心分水岭。但我要先打破一个迷信不是“能跑向量”就等于适合做Agent知识库。5.1 四款数据库的向量能力盘点Aurora、PolarDB、TDSQL-C三者都有PostgreSQL版本因此都能用pgvector扩展支持HNSW索引和余弦、欧氏、内积等距离函数。Aurora PostgreSQL pgvector基本是海外AI Demo的标配PolarDB for PostgreSQL和TDSQL-C for PostgreSQL在PG生态内同样能用国内云厂商还会做一层SQL化封装。MySQL版本这边三款都没有原生向量能力Aurora MySQL、PolarDB MySQL、TDSQL-C MySQL要做向量检索基本只能外挂独立向量库。TiDB比较特殊它兼容MySQL协议但从8.x版本开始提供内置向量类型、向量索引和距离函数不需要额外扩展还支持向量与普通标量字段在同一个SQL里组合过滤。这对MySQL技能的团队相当友好。5.2 纯向量检索不够用混合检索才是知识库的核心向量检索对语义相似很有效但对精确关键词、专有名词、型号代码这类内容经常“翻车”因为embedding对罕见词不敏感。生产级RAG知识库基本都要走混合检索向量召回候选集 全文检索/关键词匹配 重排。PG生态在混合检索上优势明显pgvector做语义召回tsvector或pg_bigm做全文检索再加一个普通WHERE做元数据过滤三者在同一条SQL里就能完成开发量很小。MySQL生态的全文索引能凑合用但向量那块必须外挂链路就复杂了。TiDB内置向量后语义召回和标量过滤很顺但全文检索能力相对有限如果业务重度依赖BM25这类关键词召回还是要评估。5.3 向量规模不同选型完全不同向量检索方案还要看数据量级百万级以内、维度768以下pgvector的HNSW完全能扛不用外挂任何独立向量库千万级Pgvector需要仔细调参和配置内存TiDB内置向量或独立向量库更稳过亿基本要上专门向量数据库。另外embedding维度别无脑选1536甚至3072维度高一个量级表空间和内存开销可能翻四五倍。我的经验先用768或1024维的模型把第一版跑起来等业务稳定了再评估要不要换高维度模型。否则建索引慢、查询延迟高、存储成本还涨得飞快。6. 维度四运维成本与长期开销决定方案能不能活到收益期选型很容易上头看参数但真正决定一个方案能走多远的往往是运维复杂度和账单数字。Agent应用迭代节奏快这块更需要提前想清楚。6.1 托管形态下的备份、升级、容灾差异Aurora、PolarDB、TDSQL-C都是云厂商全托管自动备份、跨可用区容灾、内核小版本升级基本都是标配。PolarDB有多地域的GDN方案Aurora有Global DatabaseTDSQL-C有同城双可用区集群跨地域灾备能力都在线。TiDB如果自建运维复杂度会明显高出一截——TiDB Server、TiKV、PD、TiFlash四个组件都要盯但TiDB Cloud托管形态也把这块简化了。对Agent应用来说比灾备更实际的是Schema变更。Agent业务迭代快加字段、改索引、调整JSON结构非常频繁。PG系和MySQL系云产品在Online DDL上有优化但大表加字段还是要留意锁和复制延迟TiDB借助分布式架构在线变更对业务影响更小。如果你们的Agent应用预期数据量增长很快这一条值得重点加权。6.2 账单里的三个常见成本陷阱第一Serverless最小容量。为了方便突发流量很多人把最小容量设得偏高结果低峰期也一直在计费月底账单远超预期。建议根据真实流量监控逐步下调。第二跨AZ流量和只读副本费用。上只读节点做读写分离后主备之间跨可用区数据同步会产生流量费低峰期也不便宜。不要把只读副本当一个“备用节点”挂在那儿如果确定用不上尽早释放。第三向量表的存储膨胀。一张带1536维向量列的表单行可能超过6KB比普通关系表大一个数量级。云数据库按存储容量计费这部分的月度开销很容易被低估。7. Agent场景落地姿势库表设计、连接池与SQL层面的实战注意选好库只是第一步怎么用才是真正拉开差距的地方。这里分享一些Agent项目里被反复验证过的落地细节。7.1 四类核心数据的建表思路会话状态表核心是支撑“断点续聊”和“多轮工具调用”。主键用UUID状态字段用JSON/JSONB更新时间加索引查询时按user_id加updated_at排序取最新会话。PG的JSONB在这里比普通关系列更灵活因为不同Agent工具链产生的状态结构差别很大用列存储会不断改表。Agent记忆表是向量检索的主战场。核心字段是user_id、content、embedding向量、记忆类型、创建时间。这里要注意索引顺序先用user_id过滤再走向量索引避免全库扫描。SQL大致是SELECT content, embedding :query_embedding AS distance FROM agent_memories WHERE user_id :user_id ORDER BY distance LIMIT 5;千万别把user_id过滤放到向量检索之后否则数据量一大就卡死。任务日志表最容易被忽略却是Agent应用里增长最快的表。执行状态、Token消耗、延迟、Agent名这些字段都要有按时间分区几乎是必须的。如果未来要做链路分析TiDB的TiFlash列存会自动帮你把分析查询加速PG/MySQL系则要考虑定期归档。知识库文档表混合检索的核心场景。chunk_id、content、向量、来源、权限范围、embedding模型版本都要存。知识库更新时embedding模型如果换了版本向量空间直接失效必须重新生成——这个坑我踩过不止一次所以embedding_model字段一定不要省。7.2 连接池、超时和查询约束稳定性的三个基本盘连接池参数上Agent服务的连接池不建议把maximum-pool-size设得过高20左右足够关键是minimum-idle要合理否则频繁建连反而拖慢冷启动。SQL超时一定要配。PG用的是statement_timeoutMySQL系用max_execution_time。一旦LLM生成的SQL里出现笛卡尔积或全表扫描超时是最后的救命稻草。工具暴露给Agent的SQL接口权限必须收口。给Agent只读账号连接串不落LLMSQL白名单视图只暴露业务需要的字段。这一步不做再贵的数据库也救不了“一条DELETE不带WHERE”的Agent事故。批量写入向量时分批加指数退避重试。一次性插入几万条1536维向量很容易触发内存压力或写入超时。我的经验是每批500到1000条间隔几毫秒稳定性最好。TiDB那边还可以打开rewriteBatchedStatements参数批量写性能提升非常明显。7.3 从实践看这几款库的适配表现坦白说在写多读少、知识库型Agent场景里PG方言产品加上pgvector是上手最快的组合一个库把事务、状态、向量、全文检索都覆盖了很少需要引入第二个存储组件。在强事务、高一致性的交易型Agent场景MySQL方言产品更稳团队对主从、备份的运维经验也更成熟。如果Agent应用一开始就注定要承载海量级记忆和日志并且要做在线分析TiDB的HTAP属性会给你省掉一套数仓的维护成本。8. 最终建议规模和阶段决定答案别把选型做成信仰之争每次写这类对比评论区总有人为“某库天下第一”吵起来。我的意见是选型本质上是拿团队现状、业务阶段和预期规模去套一个最舒服的组合。8.1 不同团队状态的参考路径如果你是单人开发者或小团队正在做Agent应用MVP优先看你手上云厂商的PG兼容产品Aurora PostgreSQL、PolarDB PostgreSQL或TDSQL-C PostgreSQL配合pgvector把知识库和会话状态放在同一个库里。这套组合能让你把精力全放在Agent逻辑上而不是运维上。如果团队已经有大流量业务经验Agent应用马上要对接真实客户建议保留单库架构开Serverless弹性配好连接池和只读节点。这一阶段不要急着分库分表数据库大概率不是你的瓶颈。如果业务注定是“大数据量级”的Agent应用比如面向百万用户长期沉淀记忆、行为轨迹、会话日志并且要实时分析把TiDB或TiDB Cloud放进架构用MySQL兼容协议降低迁移成本用TiFlash承载分析查询。这套选择能让你在数据量上天之后依然不用通宵做分库分表。8.2 我个人的倾向与理由从零搭建一套Agent应用我会首选PG兼容的云原生数据库当主力一段SQL同时搞定向量检索、全文检索和JSON状态处理开发效率最高团队不用维护多个存储组件。等业务证明需要更高写入并发和更大的数据规模再把存储层平滑演进到TiDB这一类分布式架构。有一点我想反复强调不要为了“更先进”就同时引入四五个存储组件。数据库选型是在给未来两三年的自己减少麻烦不是给简历添一行字。一个库加几张表就能跑通的MVP远比一套完美但复杂的多存储架构有价值。我自己换项目时每次选型花的时间都在缩短不是因为记住了Benchmark数字而是越来越清楚先看业务负载模型再看团队技能树最后才轮得到数据库本身。四款库都是好产品但适合你的那款一定是让你把精力花在Agent业务本身的那款。
