Google Cloud AlloyDB for PostgreSQL

AlloyDB for PostgreSQL is Google Cloud's PostgreSQL-compatible database service: decoupled compute and storage, cross-zone high availability, an optional columnar engine for analytical queries, and in-database machine-learning integrations. It speaks the PostgreSQL protocol and runs PostgreSQL-compatible SQL, but it is not the community binary — storage, replication, release cadence, and parts of query behavior are Google's implementation. For positioning against other enhanced engines, see the cloud service map.

What AlloyDB changes

• Separated compute and storage. Instances in a cluster share disaggregated storage with layered caching, instead of each node owning a local volume.
• Optional columnar engine. Frequently queried data can be held in a columnar format for analytical scans alongside the row store — Google's published figures for transactional and analytical speedups are vendor benchmarks; treat them as hypotheses to test on your data.
• In-database ML. The google_ml_integration extension calls managed model endpoints from SQL, covering embeddings and predictions without an external glue service.
• ScaNN vector indexing. An alternative approximate-nearest-neighbor index alongside pgvector's HNSW and IVFFlat.

In-database embeddings with google_ml.embedding()

With the extension installed and a model endpoint registered, embedding generation is a SQL function call, checked against the official documentation on 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
);

The function returns real[], so store or compare it through a ::vector cast, as above.

Two boundaries to keep in mind: the call leaves the database toward a model endpoint, so region, residency, IAM permissions, and model lifecycle become database concerns; and model IDs change — confirm the current ID in the documentation rather than copying examples, including this one.

ScaNN vector indexes

AlloyDB offers ScaNN indexes through the alloydb_scann extension:

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 is a tree-based quantization index. Per Google's documentation it builds faster and uses less memory than HNSW, with QPS and recall depending on tuning parameters such as num_leaves. Neither property survives contact with real data unexamined: measure recall after your actual tenant and ACL filters, and compare against pgvector HNSW on the same dataset before standardizing on either.

Differences to accept

• Not community-binary-equivalent. Extension availability, parameter surfaces, and some catalog or wait-event behavior differ from community PostgreSQL and from Cloud SQL. Migrate with a compatibility checklist, not an assumption.
• Per-instance-hour pricing. There is no scale-to-zero; idle clusters still bill. Usage-shaped workloads may fit a serverless platform better.
• Google Cloud only. AlloyDB Omni exists for self-managed deployments elsewhere, but it is a separately licensed, separately operated product.
• Vendor performance figures are marketing inputs. Published speedup claims compare against Cloud SQL under Google's benchmark conditions; your schema, concurrency, and data shape decide the real number.

Validate before production

1. Diff required extensions and parameters against AlloyDB's supported list, including exact pgvector and google_ml_integration versions.
2. Rehearse the migration path — Database Migration Service or pg_dump/restore — including rollback.
3. Benchmark representative OLTP and analytical queries; enable the columnar engine only if measured results justify it.
4. Measure vector recall and latency after real filtering, on ScaNN and HNSW, at production data volume.
5. Confirm embedding model region, IAM scope, quota, and lifecycle policy; record what happens to stored embeddings if the model version retires.
6. Export once with native tools and restore into an independent PostgreSQL environment as an exit-path test.

For connection budgeting, backup drills, and monitoring baselines that apply on any provider, see the production stack guide. A development-scale evaluation can start from the options in the free PostgreSQL guide.