划重点
01数据库技术在未来几年将朝着更高效、更灵活的方向发展，如向量索引、一站式多模态数据库解决方案等。
02RAG(检索增强生成)技术将成为数据库技术的重要发展方向，提高数据检索的准确率和效率。
03数据库云化趋势将推动数据库技术在基础设施上的应用，降低使用成本和提高可扩展性。
04与此同时，数据库开发者需要关注多租户管理、资源控制、可观测性等方面的优化，以满足下一代扩展性需求。
05最后，开发者们将越来越倾向于使用简单、高效的工具，如Python、ORM和开发框架，以提高开发效率和降低上手成本。
以上内容由腾讯混元大模型生成，仅供参考
【CSDN 编者按】数据库是一项长青的技术，大模型席卷这两年，向量数据库与 RAG（检索增强生成）先后崛起，成为了言大模型开发必提之用之的技术栈。CSDN 年终盘点系列特别邀请了老朋友——PingCAP 联合创始人兼 CTO 黄东旭撰文分享他对于 Data+AI 的思考，展望 2025 年数据库技术发展趋势。同时，1 月 8 日（星期三）晚 19:30-21:00，黄东旭将做客 CSDN 直播间，欢迎大家点击下方视频号预约按钮一起相会。
又到了一年一度的数据库行业总结的时间，2024 年其实并不算数据库技术的大年，倒反而是 AI + 数据相关的应用开始蓬勃发展，但数据库内核技术也并不是没有进步，在对云基础设施的使用已经开始变成行业的共识，下面就集中写一下我今年的一些观察。
Data + AI, forget the debate let’s build something useful!
当然了，这两年 IT 世界最大的变化一定是 GenAI 带来的。
距离 ChatGPT 惊艳的发布已经过去 2 年，现在开发者社区对于 GenAI 的态度大概分两派：
一派是 Scaling Law 的忠实信徒，在朝着更强的模型和 AGI 的目标前进。
另一派是实用主义者，接受现在 LLM 的现状，思考如何利用数据和 Agent 做一些有用的东西。
我个人是属于后者，在这个方向上今年大热的方案自然是 RAG，其实这个选择也很自然，目前的 LLM 有以下的限制：
LLM 的 Context Window（上下文窗口） 有限，不可能回答每个问题都将完整的知识库放到 LLM 的 Context Window 中。
Transformer 的注意力机制本身有产生幻觉的可能性，需要一些机制对 LLM 的回答进行校验。
去年和更早的时期，大家对于制作特定领域服务的 LLM App 通常的方案是对模型进行 Finetune（微调），但是 Finetune 的问题是，就像合金一样，你很难精确地控制配方，而且为了 Finetune 准备的数据到底多少才能精准影响某个问题的回答？这个并没有标准答案。并且 Finetune 通常也需要价值不菲的硬件和以天为单位的等待时间，这很不利于迭代。
不过万幸的是，过去这一年，基础模型（尤其是开源模型）的能力进步很快，例如 Llama3、Qwen、Mistral 等开源模型的能力已经基本超越 GPT-3.5，接近 GPT-4 的能力，另外开源模型的 Context Window 也越来越大，已经出现 32k 甚至更大的上下文空间，这些进步让 RAG 变成越来越合理的选择。
另一方面，RAG 也在发展，从最朴素的向量索引+LLM，到现在的 GraphRAG/LlamaParse[1]。其实核心的思想就是：对于给定的问题，能够在数据库中尽可能召回与这个问题最相关的上下文。
这个召回出来的上下文直接决定了 RAG 回答这个问题的质量，其实 LLM 在其中只是起到一个阅读理解的作用，关键还是数据的质量，以及召回的精度。这就意味着：RAG 事实上是一个更接近数据处理/数据库的生意，而不是一个 AI 的生意。
RAG 给数据基础设施带来哪些新的需求呢？有几个东西是必须的：
向量索引，2025 年，主流的数据库都会支持向量索引类型，单独的向量数据库的市场增长会停滞。
一站式，多模态的数据库解决方案会越发流行。
为什么？我从去年开始就一直强调：向量数据库是个很奇怪的东西。从数据库开发者的角度来看，向量只是一种索引类型，你真正需要的是根据向量索引检索你的数据，过去传统的数据库没有向量索引是因为没有足够需求，于是在 AI 的 workload 开始爆发，向量搜索变成强需求的时候，就有了“向量数据库”这个 workaround，但是随着这个需求被确认，主流数据库跟进的速度是很快的，毕竟更高的门槛是“做好一个数据库”。
一站式的数据方案会流行是因为：只有向量搜索并不够，随着业界对 RAG 的实践越来越深，大家发现朴素的只检索 Embedding 的召回率和准确率都不够，需要其它的检索方式进行补充。例如我们自己的例子：tidb.ai，同时使用了全文检索+Graph+向量，对这些检索结果再进行 Rerank 找到最相关的再送给 LLM。这里的挑战是多种数据技术栈带来的易用性和数据同步的挑战，如果能在一个数据库完成这些查询，为什么我要请求多个数据库？
说完 AI 对数据库的新需求，来说说数据库内核技术的一些趋势。
数据库内核技术趋势
S3 正在变成新的磁盘
从 3 年前开始构建 TiDB Serverless 开始，我就开始惊艳于 S3 简洁和扩展性，并对 S3 在未来成为新一代数据库的基石深信不疑，如果说 3 年前“S3 is the new disk”是个猜想，那么现在看来已经成为了行业共识。今年 re:Invent 上 AWS CEO Matt Garman 分享了一些关于 S3 的数字：
充分说明了 S3 已经不是仅仅是 AWS 的一条产品线，更是成为整个社会的重要基础设施，而且 Too big to fail，这对于基础设施来说是一个好消息，意味着可以被依赖。这两年新出现的数据库基本都是基于 S3 的：NeonDB、RockSet、Supabase、Databend、TiDB Serverless……S3 也是目前各种 Data lake（数据湖）实现的存储组件；很多基础设施的头部公司在开始收购各自领域中尝试用 S3 作为新基座的创业公司，例如 Confluent 收购 WarpStream[2] 就是一个很好的例子。
S3 用来构建数据库有几个好处：
真正的弹性和 Serverless 的存储；
极低的成本；
可以线性扩展的吞吐（上限极其高）；
11 个 9 的数据可靠性，基本不用的担心数据丢失。
今年 AWS S3 也有一些新的能力：
S3 Metadata
Conditional writes (Compare and Swap)
尤其是第二个，这意味着 S3 现在可以实现安全的并发写入，这对构建数据库来说是一个重要的能力。类似事情还有很多，这些能力让构建复杂的分布式数据库变得简单很多，毕竟分布式数据库大量的代码其实是在处理底层存储的状态，尤其是异常情况的状态（例如分布、数据复制、异常恢复等），将 S3 作为一个 always-on 且可扩展的基础服务，会让上层的逻辑简化很多。
而且新的架构解锁的还不仅仅是弹性和吞吐，我预期还会带来一些额外的收益，这里由于数据和篇幅问题就不展开，后续有更多数据后再开专题和大家分享。
“数据库”正在变成”数据库服务”，而分布式数据库会是其重要的底座
从 TiDB 自己在海内外客户的使用观察来看，最近这几年 TiDB Cloud 的使用量增速惊人，尤其在海外，除了一些银行或者金融机构出于合规的需求的暂时没有办法使用云以外，其他的用户更加接受云的使用，下面这张图是 TiDB Cloud 这两年的集群数的增长情况，相比两年前有了 10 倍的惊人增长。
TiDB Cloud 在过去两年的使用量趋势
数据库和数据库服务的区别？从用户角度看简单了很多，运维交给平台，自己可以专注在应用开发。
对于厂商来说，可能事情就没有那么简单了，构建一个云服务的复杂性不亚于做一个数据库内核。例如下面这张图其实是 TiDB Cloud 的一个系统架构的概览，很多做数据库内核不用考虑的工作在构建云平台的时候都需要考虑：比如计费，管理租户的管理，各种各样的元信息、可观测性，而且注意，所有上面这些都要考虑多租户。
TiDB Cloud 系统架构图
虽然这类工作可能繁琐，但有云平台之后相比私有化部署也有明显的优势。首先，环境相对标准化，便于统一管理和维护。其次，我们能够基于这一标准化环境，构建多种自动化运维手段，例如在故障分析、故障处理以及可观测性等方面，通过自动化工具显著提高工作效率。与 OP 部署的客户环境下相比，在标准化环境下进行这些工作要更加高效，也更易于持续改进和规模化落地，我们也正在尝试使用 GenAI 来进一步提升效率，这会进一步提升利润的同时提供更好的用户体验。
还有一个挑战是，适配多个云平台。虽然我们已经尽量减少对基础云平台的依赖，但各家云服务商在 API 层面依旧存在诸多差异。此外，即使是看着相似的能力（例如对象存储和分布式块设备），在不同云平台和不同机型上的表现也并不完全相同，而且不同云厂商对于安全的能力也不尽相同（例如 VPC 的抽象或者密钥管理），也进一步增加了适配的难度。然而，我认为正是这类工作体现了独立数据库厂商的竞争力所在。
即便在云普及度相对有限的国内市场，我们依然在越来越大的大客户的环境中看到类似的需求：他们希望借助统一的数据库管理平台，尽可能隐藏数据库底层的复杂细节，从而让业务层专注于核心功能的开发与迭代。
除此之外，背后隐藏的另一个重要原因是成本，这几年国内轰轰烈烈的数据库国产替代已经进入收敛阶段，其实大家发现替换成国产数据库并不省钱，而且靠谱的国产数据库厂商大多选择了分布式的路线，但是如果按照以前『一个应用一个库』的方式进行替代是不现实的，因为很多应用本身不大，分配一个完整的分布式数据库集群肯定是过犹不及，当然你可以说也可以用国产的单机数据库，但事实上很多业务的数据库分配给它 1 个 CPU 都算多余，但是又不能停，即使通过容器做资源切分，积少成多也会造成大量的浪费，更不用说为每个单机数据库都需要配置主备高可用的成本。
在我看来，解决之道是：数据库多租户的实现不仅要关注物理层面的隔离，更需要在逻辑层面引入一套完善的 Flow Control（流控）机制。具体而言，让高优先级的用户、表、库的访问优先获得资源；但是同时对低优先级的应用可以贡献资源并设置上限以保证硬件资源冲突的时候优先保证高优先级应用。
这种思路与传统的“单一实例 - 单一应用”模式存在本质差异，后者通常会为不同应用分别分配数据库实例，以求最大化地避免竞争。然而，随着数据库规模和需求场景的不断扩张，单纯依靠物理隔离不仅资源利用率不高，而且极易造成分布碎片化。通过在逻辑层面引入流控策略，数据库就可以在多租户环境下实现更精细化的资源管理。高优先级任务不会被低优先级任务“抢占”，而低优先级任务则依旧能够在空闲资源下正常运转，从而在总体上提高资源利用率并保障关键业务的连续性与高可用。
这也是 TiDB 在 v7 引入的 Resource Control 机制的核心思想，也是 TiDB 强调的“真正的”多租户的技术基础，而且这个能力只有分布式数据库才能够提供，毕竟只有分布式数据库才能对大量的硬件资源有全局视角以及调度能力。
但是与做公共的 DBaaS 不一样，企业客户强调的不是租户的概念，更多的是多应用或者多集群的概念，更加强调多集群运维能力以及的与具体应用关联的数据库可观测性。在 2025 年，我们会发布新一代的可视化 TiDB Management Tool：TEM，不同于已有的 Dashboard，这个工具面向的是企业级多集群管理的场景设计，目前已经在一些超大规模的 TiDB 客户中得到了初步的验证，也收获了不少好评，大家可以期待一下。
不只是数据量，而是下一代的扩展性
另外，这种集中化的趋势也对分布式数据库的扩展性和稳定性提出了更高的要求，我想起今年 TiDB 好几个大客户都提出了：TiDB 是否能支持创建百万甚至上千万表、库？当时听到这个需求我还是挺诧异的，后来仔细了解了一下，发现确实是个真需求：因为对于很多 SaaS 应用来说，最简单自然的开发方式就是针对每一个租户创建自己应用的表、库，只访问自己租户内部的数据，这样对于新来的客户，只需要简单的复制粘贴就可以了，这样做的好处不必赘述，但是对数据库就有了更多的挑战。
通常我们说的扩展性只关注数据量和吞吐，但是经过那么多客户真实场景的教育，我渐渐理解到当我们谈论扩展性时，实际会有很多维度，例如：能保持的连接数，支持的表库数量，后台任务（例如 DDL）的扩展性，导入导出和 CDC 任务的速度和吞吐，多租户下的可观测性和运维性等等。这些都与扩展性相关但是又常常被数据库内核开发者忽略，但是真实世界的扩展性又是满足木桶效应：你的能力取决于你最短的那一块。于是从 TiDB v7 到 v8，我们在扩展性的这些不容易被人看见，但是又实实在在大家都会遇到的问题做了很多工作[3]，例如：支持超过百万的表库数量、支持 PB 以上的数据规模、针对多集群的管理工具等。
这些工作看起来不 Fancy，但我相信这是 TiDB 要支撑下一个量级规模必须打下的基础，相信 TiDB 老用户们一定有感觉：TiDB 越来越稳定了，其实这种感觉正是一个个这些不起眼的优化带来的质变。
从开发者的角度，有什么新的变化？
一句话来说，根据我的观察，今天的开发者是越来越「傻瓜」了。今年随着 Cursor 的普及，我感觉我又能重新写代码了！作为一个前系统工程师，我曾经对这种无脑上 Python 的趋势是嗤之以鼻的，但是真的动手做了几个项目以后，发现确实真香。尤其在一些对于性能要求不高的场景（毕竟 AI 一个个吐字的才是性能瓶颈），Python 完全够用，AI 生态的亲缘性加上完善的第三方库，整体的开发体验很流畅。另外当代 Python 的类型标注（虽然是假的）和越来越完善的第三方包管理工具，让开发中型应用也不至于代码腐化得太快。
而且对于数据库的访问也被各种 ORM 和开发框架层层封装，就小型应用而言，直接写 SQL 的场合其实已经不多，Pydantic 已经有点一统江湖的趋势。尤其是 AI 应用开发更关注的是数据本身，而非数据的存储和管理方式，大家希望直接通过简单的 API 访问所需的数据，而不是处理繁琐的数据库连接、查询优化或索引管理。例如，向量搜索 API 或 RAG 服务已经逐渐成为演变成开发者可以直接通过 RESTful API 或 GraphQL 获取上下文数据，而不需要理解底层的数据库逻辑，这个和上面的数据库云化的趋势是不谋而合的。
未来的数据库平台对于用户的数据可能在 SQL 之外，也会提供 API 形式的访问（公开或非公开的），其实现在已经开始出现一些标准化趋势，尤其是针对 AI 应用的数据需求：
场景化 API：开发者可以通过一个 API 获取特定场景下的数据集。例如，某些平台提供“针对法律问题优化的检索 API”或“为医疗领域定制的诊断数据 API”。
智能化 API：Data API 不再仅仅是简单的查询接口，还可以提供实时增强、推荐等功能。例如，通过查询 API，可以直接返回优化后的上下文，甚至包含初步的模型推理结果。
从开发者的角度来看，这种转变意味着：
更低的上手成本：开发者可以直接调用服务完成复杂的数据检索，而无需学习复杂的数据库系统。
更快的开发周期：数据服务将大幅简化数据处理流程，开发者可以将更多精力集中在应用逻辑和模型优化上。
生态系统的协同效应：数据服务通过标准化的 API 和 SDK，可以轻松接入各种 AI 工具链（如 LLM、RAG 引擎、AutoML 框架）。
其实今年在 TiDB Serverless 的产品线中，我们也提供了 Data API 的能力，让数据库访问通过 RESTful API 进行，也是顺应这个潮流做的特性。
结语
写了那么多，还是有很多没有覆盖的，但是那么多工作也不可能和大家一一分享，但是也想代表所有的 TiDB 用户对这些工作背后的同事道一声感谢。回看一下，2025 年是我们创业的第十个年头，也是距离写下 TiDB 的第一行代码的第十年。我也从一个二十来岁的愣头青变成了一个中年大叔，要说这两年的变化，大约就是更有耐心也更沉默，开始习惯用做的事情和成绩来回应这个世界，同时对越来越多的人和事情发自内心的感激。
随着对于基础软件这个生意的理解越来越深，也越觉得这是一个长期的工作，我们也就才刚刚上路。就像一场马拉松，很多事情着急也没用，很多弯路必然要走，很多学费也必然要交，这就是我们这代人的责任。尤其在这个浮躁内卷的大环境下，如果用一个百米冲刺的姿态来看待竞争和产品，反而不是最优解。如果从更长期的视角来看，我始终相信：新技术打败旧技术，简单的产品打败复杂的产品，先进的商业模式打败陈旧的商业模式，美的打败丑的。最后分享一句我很喜欢的道德经中的话，作为本文的结语给大家共勉：
曲则全，枉则直，洼则盈，敝则新，少则得，多则惑。是以圣人抱一为天下式。不自见，故明；不自是，故彰，不自伐，故有功；不自矜，故长。夫唯不争，故天下莫能与之争。
新年快乐。
相关资料：
【直播预告】
2024 是大模型技术惊心动魄的一年，技术上，Scaling Law 撞墙、预训练终结、真开源 vs 假开源之声不绝于耳，向量数据库、RAG 不约而同地直指数据，大干多模态之时，推理迎来突破。但我们依然困惑良多，比如 GenAI 应用爆发何时到来？Agent 是 AGI 应用的突破口吗？1 月 8 日（星期三）晚 19:30-21:00，CSDN 视频号直播间，欢迎深度交流共同迎接 2025。