AlloyDB 是 Google Cloud 的全托管 PostgreSQL 兼容数据库服务，面向高并发事务、实时分析、海量数据与企业级应用。它结合了 Google 自研数据库引擎 + 分布式存储架构，在性能、扩展性和可用性上远超传统 PostgreSQL，在生态上与PG完全兼容，并随着PG内核不断升级。AlloyDB关注的是未来及当下数据库用户的最大的关注点：高可扩展性、高性能、高可用性、易于管理、运维可观测性、AL/ML能力。

谷歌AlloyDB架构图(改编自谷歌官网)

如所示，通过Intelligent Database Storage Engine，AlloyDB消除了数据库BLOCK的回写，只剩下日志写入器WAL WRITE。计算引擎只需要把WAL写入低延时日志存储层，那么事务提交就完成了。数据文件的落盘是异步的，使用LPS服务通过WAL来合成。这种设计参考了分布式消息中间件等的设计思路，以往采用此类实现的都是一些简单的系统，而谷歌把这种设计用到了十分复杂的数据库上。消除数据块的写入操作，是充分利用现代硬件和云平台的高可扩展性和性能特点的一种设计。

如上图，AlloyDB是一种日志即数据库概念下的共享块存储的读写分离架构的数据库。主库负责写入与部分读操作。备库无需复制，通过LPS服务直接使用Buffer Cache的数据实现只读操作，其一致性是很强的。通过并行的LPS可以并发处理大量的WAL写入和BLOCK落盘，通过低延时的LOG STORE，可以快速完成WAL落盘，避免引起数据库事务提交的性能问题。这也是AlloyDB的部署不支持跨数据中心的主要原因(跨数据中心需要通过复制)。AlloyDB的只读节点提供接近实时(Near Real‑Time)的复制延时，其延时为WAL flush → 读节点接收 → 内存缓存更新的链路延时。

为了解决AlloyDB的读取路径较长的问题，降低OLTP的延时，如图所示，谷歌设计了一种多层缓冲机制的读取架构。如果LPS还没有完成某个BLOCK的持久化写入，那么这个BLOCK相关的数据是在LPS BUFFER CACHE里缓存的，可以直接从LPS BUFFER CACHE里命中该数据(哪怕写入完成，如果该BLOCK还没有老化，那么在BUFFER CACHE中也可能命中)，如果在此层命中，则访问效率会更高，因为LPS所在的设备的IO性能更好。

AlloyDB的一个目标是解决HTAP场景的需求，因此也包含了对列存储引擎的支持。AlloyDB的HTAP是通过实例内的列引擎实现的。行数据在内存中生成了列缓冲副本，这个实现方式十分类似于Oracle的in-memory db。

如图所示，AlloyDB通过AI/ML引擎自动推荐列缓冲建议，用户可以使用自动或者手动方式来建立列缓冲。实际上，HTAP中的AP不仅仅是列缓冲就能解决的，列缓冲只能解决一部分问题，OLAP数据库产品有着更为复杂的索引与执行器优化机制。

AlloyDB 在 AI 方向的发展非常有野心，它的目标已经不再是“一个更快的 PostgreSQL”，而是在向 AI 原生数据库(AI‑Native Database) 演化。实际上，当我们还在卷信创替代的时候，国外的很多数据库产品都在大力发展AI能力，谷歌也不例外。Google 推出了 AlloyDB Omni(可在本地、K8s、混合云运行)，并与其自身的 Vertex AI 深度集成：在数据库内直接调用 LLM、使用 SQL 调用 AI 推理、数据库内嵌向量化能力、支持 RAG、支持 AI Agent与应用直接访问数据库，以上的能力让 AlloyDB 成为 AI 应用的后端数据库，而不是传统意义上的“数据源”。

在AI4DB方面，AlloyDB提供了AI 驱动的自动调优(Auto‑Tuning)：自动索引(Auto Indexing)、自动执行计划优化、自动资源调度、自动存储扩展、自动热点检测，这些能力让 DBA 的工作量显著降低。