Google Cloud AlloyDB for PostgreSQL

AlloyDB for PostgreSQL 是 Google Cloud 的 PostgreSQL 兼容数据库服务：计算与存储解耦、跨可用区高可用、面向分析查询的可选列式引擎，以及库内机器学习集成。它讲 PostgreSQL 协议、运行 PostgreSQL 兼容的 SQL，但不是社区二进制——存储、复制、发布节奏和部分查询行为是 Google 自己的实现。与其他增强型引擎的定位对比见云服务版图。

AlloyDB 改变了什么

• 计算与存储分离。 集群内的实例共享带分层缓存的解耦存储，而不是每个节点持有本地卷。
• 可选列式引擎。 热点数据可以以列式格式驻留，与行存并行服务分析型扫描——Google 公布的事务和分析加速数字是厂商基准，把它们当作待验证的假设，用你自己的数据测试。
• 库内 ML。 google_ml_integration 扩展可以从 SQL 直接调用托管模型端点，覆盖 embedding 生成和预测，省掉外部胶水服务。
• ScaNN 向量索引。 在 pgvector 的 HNSW 和 IVFFlat 之外的另一种近似最近邻索引。

用 google_ml.embedding() 在库内生成 embedding

装好扩展并注册好模型端点后，embedding 生成就是一次 SQL 函数调用。以下按官方文档核对于 2026-08-06：

CREATE EXTENSION IF NOT EXISTS google_ml_integration;
CREATE EXTENSION IF NOT EXISTS vector;

SELECT google_ml.embedding(
  model_id => 'gemini-embedding-001',
  content => 'AlloyDB keeps embedding generation inside the database'
) AS embedding;

INSERT INTO articles (body, embedding)
VALUES (
  'Some article text',
  google_ml.embedding(model_id => 'gemini-embedding-001', content => 'Some article text')::vector
);

该函数返回 real[]，存入 vector 列或参与向量运算前需要像上面一样加 ::vector 显式转换。

两条边界要记清：这个调用会离开数据库访问模型端点，因此区域、数据驻留、IAM 权限和模型生命周期都成了数据库侧的问题；模型 ID 会变化——以文档中的当前 ID 为准，不要照抄任何示例（包括本页）。

ScaNN 向量索引

AlloyDB 通过 alloydb_scann 扩展提供 ScaNN 索引：

CREATE EXTENSION IF NOT EXISTS alloydb_scann CASCADE;

CREATE INDEX articles_embedding_scann ON articles
  USING scann (embedding cosine)
  WITH (mode = 'MANUAL', num_leaves = 100);

ScaNN 是基于树的量化索引。按 Google 文档，它比 HNSW 构建更快、内存占用更低，QPS 和召回率取决于 num_leaves 等调优参数。但这两条性质都不会在真实数据上自动成立：在你实际的 tenant 和 ACL 过滤之后测量召回率，并在同一数据集上与 pgvector HNSW 对比，再决定标准化用哪一个。

需要接受的差异

• 不是社区二进制等价物。 扩展可用性、参数面以及部分系统目录或等待事件行为与社区 PostgreSQL、与 Cloud SQL 都有差异。带着兼容性清单迁移，不要靠假设。
• 按实例小时计费。 没有 scale-to-zero，空闲集群照常计费。用量形态波动大的负载可能更适合 serverless 平台。
• 仅限 Google Cloud。 AlloyDB Omni 可用于其他环境的自管部署，但它是单独授权、单独运维的产品。
• 厂商性能数字是营销输入。 公布的加速比基于 Google 基准条件下与 Cloud SQL 的对比；真实数字由你的 schema、并发和数据形态决定。

生产前验证

1. 把所需扩展和参数与 AlloyDB 支持清单比对，包括 pgvector 和 google_ml_integration 的确切版本。
2. 演练迁移路径——Database Migration Service 或 pg_dump/恢复——包括回滚方案。
3. 用有代表性的 OLTP 和分析查询做基准；只有实测收益成立时才启用列式引擎。
4. 在生产数据量级、真实过滤条件下，分别测量 ScaNN 和 HNSW 的召回率与延迟。
5. 确认 embedding 模型的区域、IAM 范围、配额和生命周期策略；记录模型版本退役时已存 embedding 的处置方案。
6. 用原生工具导出一次，并在独立 PostgreSQL 环境中恢复，作为退出路径验证。

连接预算、备份演练和监控基线等跨厂商内容见生产环境技术栈。开发规模的评估可以从免费 PostgreSQL 选型中的方案开始。