AI时代的数据库与DBA将何去何从

前天在 HOW 2025 大会的圆桌上，萧主席问了一些关于 AI，数据库 DBA 有趣的问题，以下是老冯的观点，整理发出。

OLTP / OLAP ，谁先被革命？

问题：OLTP / OLAP 领域，AI 在哪个领域更有可能先带来 “革命性” 的变化，DBA， 数据分析师，架构师又该如何应对这些变化。

老冯：“革命性”的意思说白了就是直接把工作岗位干没了。对于 OLTP 领域，这意味着 AI 干掉 DBA ，对于 OLAP 领域，这意味着干掉数据分析师，数据研发的工作。目前的趋势很显然，OLAP 领域的工作岗位正在被替代中，大量 NL2SQL 的方案正在涌现。

与此同时，Claude Code 正在以惊人的水平替代着中低级程序员，写 SQL 的数据分析师与数据研发作为一种 Coding 工种，也落在替代光谱中。我们可以看到各种各样的 “智能分析” / 表格，数据库 MCP，Text2SQL / NL 2SQL 的方案到处冒泡。

然而不同于 Github 上到处都是语料的编程数据样本，运维/数据库管理经验的公开数据积累是非常少的。SRE，DBA 则因为语料数据缺乏，加上反馈验证回路过长，在短期内还难以被直接替代。因此毫无疑问 AI 带来的 “革命性” 变化会首先发生在 OLAP 领域。

一个鲜活的例子是，OpenAI 创始成员（），Vibe Coding 之父安德烈·卡帕西（Andrej Karpathy）在 YC AI创业学院发表了主题演讲就提到过，他花了一天时间就糊出来一个菜单配图的应用，但是花了整整一周时间才把这个应用给部署上线 —— OPS 部份成了 Vibe Coding 的瓶颈。

尽管如此，Agent 替代 DBA 也只是一个时间早晚的问题。也许三年，也许五年，最终 OLTP 领域的 DBA 工作也会在几年内被 AI 攻克。云计算和本地管控软件会自动化掉 70% - 90% 的工作，而 AI Agent 会处理剩下 9% 的工作，可能留下不到 1% 甚至 千分之一的疑难杂症给顶级 DBA 处理。

一体化还是专业化，如何选型？

问题：数据库领域会走向 ”一体化“ 还是 ”专业化“，企业如何针对自己的需求进行合理选择？

老冯：许多领域都存在一个 “钟摆”，根据力量强弱对比来回摆动。在当下，硬件性能突飞猛进，数据库（PostgreSQL）扩展越来越丰富。现在数据库领域的钟摆显然在向 “一体化” 摆动的，而留给专业化组件的生态位越来越小了。

前些日子，有个朋友问我一个向量 RAG 场景，应该用 PostgreSQL + pgvector 还是 Milvus，我问你有多少数据量 —— 两千万条。我回复说这个数量级您就别折腾了，一百多GB的数据放 PG 洒洒水，十几TB 的PG向量表我都见过照样跑的好好的。你要是数据量再翻个几百倍，，而你现在已经用着PG，这么点规模就开始折腾，那不是给自己找事吗？

同理，我也见过好几次有业务号称自己有超高增长，一上来就要申请一套水平分片库，最后只有 几十GB数据的滑稽故事。如果你的数据连几十TB都没有，那根本用不上什么分布式 NewSQL 数据库 ——，那 99.99% 的业务也可以靠一个 PostgreSQL 解决所有问题。，。

我们可以把 PostgreSQL 这样的数据库比做智能手机，它可以打电话，GPS 导航，照相，干各种各样的事情。确实存在专业的场景 —— 比如航海需要卫星电话，商业摄影可能需要专业单反相机，但这些小众领域相比智能手机的市场规模差了好几个数量级，而绝大多数用户都只需要一款手机就足够解决他们的问题了。

我认为在当下，对象存储还值得有专用数据库产品。其他的数据库细分领域生态位基本已经收敛到上面的状态。而且使用专用组件的门槛也越来越高，越来越远离大部份应用的规模。我们可以期待再将来的某个时间点，（ / Timescale / Promescale ）。

过早优化是万恶之源 —— 为了自己不需要的属性付出复杂度，成本，人力，一致性维护上的代价没有意义。企业在数据库选型的时候一定要擦亮眼睛，不要为了自己并不需要的东西而瞎忙活 —— 而 PostgreSQL 毫无疑问就是数据库领域的默认安全牌。

AI 时代的 DBA，何去何从？

问题：从 DBA 到 DBAA，DBA 如何适应 AI 时代的变化与冲击

，效果非常不错。你可以把 Claude Code 当成一个月薪一百美元的高级工程师（实际上你可以用 20刀套餐，买好几个！），勤勤恳恳的二十四小时给你干活。这意味着什么？这意味一个光杆架构师现在有了一整个待命的高级程序员团队。

AI 是极度利好专家的，在专家手中的 AI 能发挥出普通工程师 10x 的表现 —— 这背后的逻辑是专家能一步到位提出正确的问题，精准的上下文，以及直觉判断，并且有能力对 Code Agent 的方案进行 Verfiy。而普通开发者则往往缺乏答案验证能力与问出正确问题的健全直觉。而架构师可以指挥一堆 Code Agent 替代初级工程师去出活。

这也意味着，IT 领域将很有可能出现阶层固化与分裂 —— 初级工程师的上升路径被 Code Agent 锁死了，被固化为 Code Agent 的传声筒与人肉胶水。而且因为没有那么多场景和故障再给新人打磨练手成长，以后高级的DBA 和架构师可能也就是那么多。

对于金字塔尖的专家来说，这是一个重大利好，这意味着专家的能力可以通过以下两种方式实现高速复制：通过 Coding Agent，；然后在前面的基础上，再通过 DBA Agent，将专家的经验沉淀为 Prompt / 知识库，解决 9% 的常规问题，剩下的 1% （也许是 0.1% ）的活，再由专家人工解决。

这意味着一个 DBA 数据库专家可以通过管控与Agent 实现几百倍到上千倍的杠杆。例如，许多客户咨询我的问题，我是丢给 GPT o3-pro 解决的，我只需要问出正确的问题并验证回答有效性，就可以完成原本需要十几倍时间的工作。而这就是超级个体与一人公司的运作方式，让我在一个人服务十几个客户的情况下依然可以时间自由。我将这种新的模式称为 Service as Software （SaaS）。

实际上这也是云厂商云数据库 RDS 团队的工作模式，像德哥这样的顶级 PG DBA 专家可以通过云管控软件，一二三四线客服与 Agent 服务成千上万的客户。当然，他以前可能要依赖云平台的能力，但现在有了开源的 PG 管控平台 Pigsty，他完全可以出来当一个 PG 顾问，用 Pigsty 交付，用 Agent 辅助，自己负责问问题与兜底，同样成为一个数据库超级个体。

对于普通的 DBA 来说，我认为这里也有很多机会。一个显著的趋势是，数据库的专业知识成为了 Vibe Coding 中不可替代性最强的部份。为什么这么说，让我们看看现在的 AI / SaaS 创业者都是怎么交付，怎么出活儿的。

最佳实践通常是用 Next.js 糊个前端托管到 Vercel 或者 Cloudflare 上，后面对接一个 Supabase 这样的 “BaaS” 数据库 —— 后端被完全省略掉了，而前端用 Vibe Coding 去糊相对容易，唯独对 Supabase 底下的 Postgres 的掌握与理解，是相对稀缺的技能。而自建维护生产级 PostgreSQL / Supabase 集群，则基本上成为了整套 Stack 中的瓶颈卡点。

这对 DBA 是一个非常大的利好 —— 因为 Claude Code 把大家的编程能力拉到了同一个水准，那么比拼的就是通用的整合能力，以及稀缺的数据库 / DBA经验。而 PG DBA 群体恰好已经拥有了后者，那么相对于其他同级别工程师来说就占据了一个先天的优势。

而 PG DBA 应该充分利用好当下这个优势，使用 Code Agent （以及 开源 PostgreSQL 数据库管控 Pigsty）武装自己，把自己改造成新一代的全能架构师 + 管理者，在别人还在吭哧吭哧啃数据库硬骨头的时候抢先出击，占领生态位高地。

老规矩，不打广告，写啥文章？

开源免费企业级 PostgreSQL 发行版：认准 Pigsty

https://pgsty.com ，这是市面上唯二两个可以的开源 PostgreSQL 方案。 让你在虚拟机/物理机/云服务器上一键安装好带有高可用， 备份恢复，监控系统，IaC，连接池，访问控制的企业级 PostgreSQL / Supabase / MinIO / Redis / ... 数据库服务，并一条龙解决好 Nginx，域名，HTTPS，Docker，镜像，软件源翻墙等问题 ……

数据库老司机专栏