Managed Databases on Google Cloud

Pick the data model and access pattern before looking at Google Cloud product names. That decision is engine-neutral and is covered in Choosing the Right Database, which compares relational, document, search, vector, graph and other categories. Only once the engine family is fixed does the Google Cloud question arise: which of a first-party service, a Google Cloud Marketplace SaaS offering or a self-managed deployment fits your team. Each row of the next table states which of those three kinds the option is.

For every engine this site documents, the table gives the Google Cloud option(s), the kind of option, this section’s page that covers it and this site’s reference for the engine itself. "First-party" means a Google-operated managed service. "Marketplace SaaS" means a partner-operated service that you subscribe to through Google Cloud Marketplace; it is billed through your Google Cloud account, often counts toward committed spend, and is usually reachable over Private Service Connect. "Self-managed" means you run the engine yourself on Google Kubernetes Engine (GKE) or Compute Engine.

Where the Google Cloud column says "alternative", the Google Cloud service is a different engine that solves a similar problem, not a hosted version of the engine on this site. Agent Search is a managed retrieval service rather than a Solr or Lucene deployment, and Spanner Graph speaks GQL rather than Neo4j’s Cypher dialect. The pages Lucene vs. Solr vs. Elasticsearch vs. OpenSearch and Neo4j vs. relational and other graph databases explain the differences. The Google Cloud column of the vector comparison lives in Comparing Vector Databases, and the landscape in The Vector Database Landscape.

Marketplace SaaS databases run in the partner’s own accounts, not in your project. You subscribe in Google Cloud Marketplace, the charges appear on your Google Cloud bill, and you connect over the public internet or, where the vendor offers it, over Private Service Connect so that traffic stays on Google’s network. Self-managed deployments run in your project: you own patching, backups, upgrades and failover, but you also get the full engine feature set and a free choice of version. Running stateful engines on GKE is covered in GKE Clusters.

Four Google Cloud databases have no engine reference on this site, because they exist only as Google products. They come up in the same decisions.

Firestore and Filestore are different products that happen to share a prefix: Firestore is the document database, and Filestore is the managed NFS file service in Block and File Storage on Google Cloud.

BigQuery stores embeddings in an ARRAY<FLOAT64> column and finds nearest neighbours with the VECTOR_SEARCH table function. It is the right fit when the vectors already live in the warehouse, the workload is batch or analytical (deduplication, clustering, offline recommendations), and a latency of hundreds of milliseconds to seconds is acceptable. For a low-latency online lookup behind an API, use a database built for it: pgvector or ScaNN on AlloyDB and Cloud SQL, Firestore, or Vertex AI Vector Search (renamed Agent Retrieval in the 2026 rebrand, still in Preview when this page was checked).

Without an index, VECTOR_SEARCH runs an exact brute-force scan, which is accurate and fine for small tables. For large tables, CREATE VECTOR INDEX builds an approximate index (IVF or TREE_AH, the latter based on ScaNN) that trades a little recall for speed. Vector indexes need the Enterprise or Enterprise Plus edition (reservations); on-demand projects can still run the brute-force query. The example creates a small embeddings table for the Bookshelf catalog, indexes it and searches it; the vector literals are shortened to three dimensions for readability, whereas a real embedding model produces hundreds.

Derived from the BigQuery documentation — Introduction to vector search, Manage vector indexes and the VECTOR_SEARCH function reference. The dataset location cannot be changed after creation, so pick it deliberately.

The query returns the two nearest books by cosine distance. The concepts behind the metrics and index types are explained in Similarity Metrics & Semantic Search and ANN Indexes: Flat, IVF, HNSW and Beyond. BigQuery can also generate the embeddings itself by calling a remote model, which belongs to the data and AI overview in AI, Data and Analytics Overview.

The flow starts from the workload, not from a product. It names the first-party default at each leaf; every leaf has the Marketplace and self-managed alternatives listed in the map above.

Treat the tree as a starting point. A real decision also weighs team skills, existing licences, the compliance regime and the portability you want: Cloud SQL and AlloyDB speak the standard PostgreSQL and MySQL protocols and are easy to leave, whereas Spanner, Firestore and Bigtable give up some portability for capabilities nothing else offers. The engine-neutral version of the same reasoning is in Choosing the Right Database.

Each page linked from the map covers engine-specific setup and tuning. The concerns below apply, in some form, to every first-party option, and several apply to the self-managed ones as well.

Two services handle most moves, and they solve different problems:

For a same-engine move the native tools are often simpler: pg_dump and pg_restore for PostgreSQL, mysqldump or native replication for MySQL, and snapshot or backup import where the service supports it. Whichever path you pick, assess compatibility first, rehearse the cutover, and measure replication lag before switching traffic. The wider migration playbook is in Architecture, Migration and Multicloud.

The BigQuery example above creates a dataset, a table and a vector index. Deleting the dataset with -r removes all of them. The other services on this page are only described here; their clean-up steps are on their own pages.

Derived from the BigQuery documentation — Manage datasets page. A deleted dataset can be restored within its time travel window (seven days by default).