What To Look For in a Serverless Database for AI Applications

为 AI 应用选择无服务器数据库时应关注的要点 | Databricks 博客

跳至主要内容

数据 + AI 基础

为 AI 应用选择无服务器数据库时应关注的要点

作者：Databricks 团队

摘要

• 无服务器数据库是 AI 应用的新基准，但并非所有标有“无服务器”标签的产品都提供了将计算与存储分离的创新功能。

• 对于 AI 工作负载，核心评估标准包括计算与存储分离、兼容开放标准、可扩展至零、连接架构、原生 AI 功能和集成治理。

• 本文是为开发人员、架构师和数据领导者评估用于 AI 应用的无服务器数据库时提供的实用购买指南，包括供应商检查清单。

对于今天构建 AI 应用的团队来说，无服务器数据库是新的基准。AI 团队需要一个能够根据需求即时扩展的数据库，在需求低时几乎不产生成本，并且能够接近企业数据。否则，他们可能会为未使用的基础设施付费，造成治理、安全和合规方面的挑战，并花费宝贵的时间在数据库管理上。

什么是无服务器数据库？

无服务器数据库是一种根据需求自动扩展计算和存储的云数据库，按实际使用情况进行计费，从而减少容量规划和基础设施管理。在无服务器模型中，服务器被使用，但由云服务提供商或供应商完全管理。在最先进的系统中，计算和存储是分离的，因此它们可以独立扩展，你只需为每一层实际使用的资源付费。

将数据库管理视为一个发展过程：

• 自托管数据库提供完全的控制

• 管理的 DBaaS 将操作转移给云提供商

• 无服务器数据库增加了自动扩展和基于使用情况的定价，且管理最小化。

并非所有标有“无服务器”标签的产品在架构上都是无服务器的，或者将计算与存储分离。有些只是带有基于使用情况计费的自动扩展集群。在评估选项时，理解这些区别非常重要。

无服务器数据库的工作原理

无服务器数据库按需分配计算资源，对共享存储层执行查询，并根据使用情况进行计费。无服务器平台会监控工作负载所需的资源，并在需要时自动扩展计算资源，在需求减少时再缩减回来。扩展可能是垂直的（每个节点更多的 vCores）、水平的（更多的节点）或两者都有，这取决于工作负载。

在现代无服务器架构中，存储通常与计算分离，通常在一个共享池中，无论计算是否运行，数据、副本、备份和时间点恢复都始终可用。

效率提升可以非常显著。根据2025年发表在《欧洲计算机科学与信息技术杂志》上的一项研究，研究人员发现，使用无服务器数据库的企业，与传统预配置数据库相比，平均成本降低了38%。此外，无服务器平台在间歇性推理工作负载（AI应用中常见的模式）上，可实现40-65%的潜在节省。

同一项研究还指出，采用无服务器数据库的组织在基础设施管理任务上减少了65%，而88%的组织报告称与传统数据库系统相比，运营效率有所提高。

为AI应用选择无服务器数据库时应关注的要点

这些标准应是任何在选择无服务器数据库时的买家的检查清单。对于AI使用场景，连接模型、延迟和AI集成是最重要的评估领域。

计算与存储的分离

并非所有被称为“无服务器”的数据库在架构层面都实现了计算与存储的分离。有些只是在传统耦合系统之上添加了自动扩展和基于使用量计费的功能，这限制了它们在最低使用量和峰值需求时的扩展能力、各层独立增长的能力以及成本效率。

请向供应商询问计算和存储是否在架构上解耦，以及当计算扩展到零时，存储是否可以独立持久化。

开放标准与可移植性

专有数据库API可以提供简化连接、专用软件开发工具包（SDK）和紧密平台集成的便利性。然而，随着时间的推移，它们可能会使应用和数据更难迁移，成本更高。

应寻找支持开放标准和常用接口的解决方案，例如广泛采用并由大量驱动程序、库、ORM和工具组成的生态系统支持的PostgreSQL。当无服务器数据库基于PostgreSQL构建时，团队可以利用现有的技能、工作流程和代码，而无需重新构建，从而在采用新技术、更换供应商或演进架构时拥有更大的灵活性，而无需从头开始重新构建应用。

请向供应商询问数据库是否通过标准的线缆协议进行通信，还是通过专有API。

真正的缩至零规模和弹性扩展

AI工作负载在其生命周期的大部分时间都处于空闲状态。具有真正缩至零能力的数据库可以在这些期间将计算消耗降至零，从而消除未使用容量的费用。并非所有被称为“无服务器”的产品都提供这种能力。

在评估无服务器数据库产品时，请询问最低计费计算单元以及系统在面对需求突然激增时能多快进行扩展。

可预测的冷启动和预热行为

尽管缩至零可以带来显著的成本节省，但由此产生的启动延迟可能会影响应用的响应速度。当计算从暂停状态恢复时增加的延迟称为冷启动。对于对延迟敏感的AI工作负载，保持一个非零容量下限通常是权衡响应速度和成本的有意取舍。

在评估过程中，请要求提供针对实际工作负载的预热时间数据。

AI代理和无服务器函数的连接模型

你的应用程序处理数据库连接的方式可能会成为 AI 工作负载的主要瓶颈。AI 代理和无服务器函数可以同时打开数千个数据库连接，使传统的连接模型不堪重负。主要的三种模型如下：

• 每个请求一个连接：这种遗留模型为每个请求打开和关闭一个数据库连接。它易于构建，但在大规模使用时效率低下，因为每个请求都必须建立新的连接。

• 原生传输控制协议（TCP）配合连接池：使用由连接池管理的持久连接，该连接池将少量数据库连接共享给多个客户端。这是高并发应用和传统后端服务的标准方法。

• HTTP / 数据 API：通过 HTTP 而不是持久的 TCP 连接访问数据库。由于它几乎不需要连接管理，因此非常适合无服务器函数、边缘环境和其他无状态工作负载。

对于 AI 应用，应确认连接池是否已内置在平台中，而不是作为单独的服务提供。管理外部连接池会增加操作复杂性，并在大规模使用时可能引入另一个潜在瓶颈。

定价模型与成本可预测性

无服务器定价听起来很简单：按使用情况付费。但实际上，计费可能比表面上更细致。许多提供商对计算、存储、I/O 操作和数据传输等使用情况进行收费，而有些还对连接、请求或其他使用指标进行收费。应同时考虑低利用率和高利用率场景，以了解工作负载的真实成本。需要留意的隐藏成本包括预热保留容量、只读副本费用、备份保留费用和跨区域数据传输费用。

要求提供详细的计费和使用情况报告，以避免出现意外费用。

延迟与性能上限

延迟直接影响应用程序的响应速度和用户体验，即使是很小的延迟也会造成影响。除了平均响应时间外，还应评估 p95 和 p99 延迟——分别表示最慢 5% 和 1% 的请求所经历的响应时间——以了解数据库在真实条件下的性能表现。这些指标通常会揭示平均响应时间可能隐藏的冷启动、扩展延迟和连接瓶颈。

向供应商索取在真实负载下的性能基准，而不是理想条件下的数据，并注意扩展事件期间发生的情况。自动扩展可能会导致延迟的临时增加、连接的频繁切换或请求排队，这可能对事务性 AI 工作流产生负面影响。

安全性、加密和客户管理密钥

数据库安全性功能可以保护敏感数据、限制访问并提供所需的可见性以满足安全和合规要求。静态和传输中的加密、通过虚拟私有云（VPC）或私有端点实现的网络隔离、身份和访问管理（IAM）集成以及审计日志等功能对于 AI 工作负载至关重要。

在无服务器架构中，加密密钥管理也非常重要。一些组织要求客户管理的加密密钥（CMK），以便他们控制对数据的访问，而不是由供应商控制。当无服务器数据库自动暂停时，该密钥关系必须保持不变，因为配置错误或被撤销的密钥可能在计算恢复时使数据库无法访问。

如果你的组织处理受监管的数据，请确认支持自带密钥（BYOK），并在承诺使用某个供应商之前，测试密钥轮换在暂停周期中的行为表现。

治理与更广泛数据栈的集成

随着AI代理承担更多自主性，治理变得越来越重要。一个与更广泛数据栈隔离的无服务器数据库会带来治理盲点。与你的分析和AI基础设施集成的数据库可以确保从端到端的策略、审计和治理控制保持一致。

寻找能够帮助在存储、处理和分析企业数据的系统中一致应用策略的功能，例如统一目录集成、行级和列级访问控制，以及在操作数据和分析数据之间追踪数据血缘的功能。

原生AI功能

你的数据库应原生支持AI工作负载，而不是需要单独的系统和操作开销。寻找能够区分AI就绪数据库与传统OLTP系统的功能，包括原生向量搜索、支持将嵌入向量与结构化数据一起存储、与特征存储集成，以及与模型服务基础设施紧密对齐。

确认向量数据和关系型数据是否存在于同一个数据库中，还是需要单独的向量存储，并寻找可以同时作为操作系统的记录系统和AI查询层的数据库。

基于数据库分支的安全实验

除了读取数据，AI代理还会写入数据，例如更新客户记录、执行模式迁移或在生产数据上测试新工作流。然而，这种能力会引入风险，即一次错误的写入可能会破坏所有其他工作流依赖的数据集。传统的预发布环境有所帮助，但完整的数据库副本创建缓慢、维护成本高，并且一旦创建就会立即过时。

数据库分支可以创建一个与原数据库具有相同模式和数据的即时、隔离的副本，但无需复制数据的开销。分支不会复制底层数据，而是与主数据库共享存储，并且仅在发生更改时写入新数据。这意味着代理可以快速获得一个生产级的环境，可以自由地在真实数据上进行实验，并在任务完成后丢弃分支，而不会对生产环境造成任何影响。对于AI团队来说，这消除了在大规模安全运行代理时的一个最大的操作障碍。

可靠性、副本与灾难恢复

数据库停机会影响AI工作负载，因此可靠性和灾难恢复是核心评估标准。验证是否支持多可用区复制、时间点恢复、自动故障转移以及已记录的恢复点目标（RPO）和恢复时间目标（RTO）承诺。确认数据库使用与主数据库共享存储的副本（以减少延迟和降低成本），而不是维护完整的独立副本。

报告

企业的智能代理AI行动指南

立即阅读

实用评估检查清单

使用此检查清单来指导你向供应商提出所有正确的问题。

• 计算与存储分离：确认计算和存储在架构上是解耦的

• 开放标准：优先选择Postgres或其他标准的线协议，而不是专有API

• 缩放至零：确认最小计费单位确实可以真正达到零

• 预热时间：获取已发布的冷启动延迟范围，而不是口头估计

• 连接模型：验证内置的连接池或 HTTP API 以应对高扇出工作负载

• 定价透明性：获取一个可以区分计算、存储和 I/O 的计费仪表板

• 收支平衡建模：根据实际负载情况比较无服务器和预配置的成本

• 治理适配性：确认访问控制和数据血缘关系可以覆盖整个数据栈

• AI 就绪性：验证向量搜索、嵌入存储和特征库的集成情况

• 安全态势：验证 BYOK 行为在自动暂停周期中的表现

• 恢复承诺：获取具体的 RPO/RTO 数字和副本架构细节

适用于 AI 时代数据库的正确架构

团队今天对数据库所做的决策将决定其 AI 应用程序的扩展性、性能和演进方式。越来越多地，这始于一个无服务器的基础架构，它能够快速扩展并收缩到零，处理 AI 代理创建的连接模式，并支持原生 AI 功能，如向量搜索。

随着 AI 代理承担越来越多的应用逻辑，需求变得更加动态，数据库必须更加弹性以跟上节奏。将计算与存储分离的平台能够提供现代 AI 工作负载所要求的灵活性、效率和弹性。

投资于正确基础设施的组织可以更快地前进，更迅速地响应客户需求，并将资源集中在创新上，而不是运营上。

Databricks 如何为 AI 构建无服务器数据库

Databricks 提供 Lakebase，这是一个为 AI 应用程序和代理构建的全托管、无服务器 Postgres 数据库。Lakebase 将计算与存储分离，用于事务数据，这种架构上的差异使真正的弹性扩展成为可能，消除了空闲计算成本，并确保无论计算是否运行，数据都能保持一致可用。

Lakebase 位于与数据湖仓相同的存储和治理层上，因此运营数据、分析和 AI 工作负载可以共享一个平台，无需 ETL 管道在系统之间移动数据。Postgres 兼容性使团队能够从第一天起继续使用熟悉的工具、驱动程序、库和开发实践。

治理通过 Unity Catalog 进行管理，有助于确保访问控制、数据血缘和审计在平台的每一层保持一致。作为 Databricks 更广泛的无服务器基础设施的一部分，Lakebase 设计为可以快速启动，根据需求自动扩展，并通过托管基础设施和内置的弹性功能减少运营开销。

由 AI 驱动的电子邮件平台 Superhuman 将这种架构付诸实践。该公司将 Lakebase 作为内部应用程序和生产服务的事务骨干。通过这一改变，以前需要数月的特性上线和反向 ETL 项目被压缩到几周甚至几小时，而工程团队的值班负载则大幅下降。

了解 Lakebase 如何在一个平台上将无服务器 Postgres、治理和 AI 结合在一起。

常见问题

无服务器数据库真的无服务器吗？

所有数据库都使用服务器，但先进的无服务器系统会将计算与存储分离，并在空闲时将计算扩展到零。其他被称为“无服务器”的产品则会保持一定水平的可计费计算。

无服务器数据库会有冷启动吗？

是的。冷启动是指从暂停状态恢复计算时增加的延迟。对于对延迟敏感的工作负载，可以通过设置非零的计算下限或安排预热来缓解冷启动问题。预热时间因供应商而异。

无服务器数据库如何处理来自 AI 代理的连接？

许多无服务器数据库提供内置的连接池器或 HTTP/数据 API，以处理大量短暂的连接。这对于 AI 代理、无服务器函数和其他高并发工作负载尤其重要，这些工作负载可能会产生连接高峰。

无服务器数据库是否比预配置的数据库更便宜？

对于不可预测或空闲时间较长的工作负载，无服务器数据库可能显著更便宜，因为您只需为消耗的资源付费。对于持续运行且吞吐量持续较高的工作负载，预配置的部署通常更具成本效益。

我可以将现有数据库迁移到无服务器层级吗？

可以。无服务器 PostgreSQL 数据库使用标准的线协议，允许现有应用程序、工具和代码在不进行修改的情况下连接到新的无服务器层级。

适用于 AI 应用的正确无服务器数据库

本指南中涵盖的标准——零扩展、快速扩展、对代理友好的连接处理、受控的数据集成以及原生的 AI 功能（如向量搜索）——也是一把过滤器。并非所有以“无服务器”命名的数据库都能通过所有标准。一些数据库在架构解耦方面会失败，另一些则可能在连接模型或治理集成方面失败。在承诺任何平台之前，请对工作负载的两个极端进行建模：空闲时的成本和峰值时的成本。这种练习将比任何供应商的简报更快地揭示标签背后的架构现实。

此外，更广泛的趋势也值得关注。随着 AI 代理承担越来越多的应用逻辑，数据库行为将变得像基础设施行为一样。固定预配置的资产无法适应一个会不可预测地扩展查询、闲置数小时后再次激增的代理。您 AI 应用程序下的数据库需要像您的 AI 一样行为——具有弹性、响应迅速，并在关键时刻始终保持运行。

在您的邮箱中获取最新文章

订阅我们的博客，获取最新文章发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"