GCP Database Options: How to Pick Without Overbuying

For most applications on Google Cloud the answer is Cloud SQL running PostgreSQL, and the rest of the catalogue exists for workloads that have outgrown it in a specific, identifiable way.

That is an unfashionable thing to say about a product line with seven entries, but the alternative is what usually happens: someone picks a globally distributed database for an app with four hundred users, and spends the next year explaining the bill. Here is what each product is genuinely for, and the signals that tell you when you have actually outgrown the simple option.

Table of contents

• The relational options
• The non-relational options
• BigQuery is not in this comparison
• How to actually decide
• The costs that surprise people
• Migrating in and out
• How this fits the rest of the stack
• FAQ

The relational options

Three products, and the gap between them is larger than the names suggest.

Cloud SQL is managed MySQL, PostgreSQL or SQL Server. It is a single primary instance with optional read replicas and automated backups. This is an ordinary relational database that somebody else patches, and for the overwhelming majority of applications it is the correct choice. It is also the one that behaves exactly like the database you develop against locally, which is worth more than it sounds.

AlloyDB is a PostgreSQL-compatible engine with a rearchitected storage layer, aimed at heavier transactional and analytical mixed workloads. It speaks Postgres, so migration is mostly a connection string, and it costs meaningfully more. The case for it is real but specific: you are hitting the ceiling of a large Cloud SQL instance and your workload has an analytical component that a read replica is not solving.

Spanner is a globally distributed relational database with horizontal scaling and strong consistency across regions. This is a genuinely remarkable piece of engineering and it is almost always the wrong answer for a new application. The problems it solves, multi-region writes with strong consistency and scaling beyond what a single primary can handle, are problems most systems never have.

The honest heuristic: start on Cloud SQL. If you ever outgrow it, you will know precisely which limit you hit, and that limit will tell you which of the other two to move to.

The non-relational options

Firestore is a serverless document database with real-time client synchronisation and offline support. Its strongest case is a mobile or web client that subscribes to data and gets pushed updates, without you building a socket layer. That is a genuinely good reason to pick it. The trade is a query model with real limits: no joins, no aggregate queries beyond counts, and indexes you have to declare in advance for anything compound.

Bigtable is a wide-column store for very high write throughput and low-latency lookups by key, at scale. Time series, IoT telemetry, event streams, ad serving. If your access pattern is genuinely a key lookup and your volume is genuinely enormous, it is excellent. If you are going to want to ask a question you did not plan the row key for, it will hurt.

Memorystore is managed Redis, Valkey and Memcached. This is a cache, and occasionally a queue. It is not a primary datastore, and the failure mode of treating it as one is data loss during a failover.

The pattern across all three: they trade query flexibility for something specific, whether that is real-time sync, write throughput, or latency. Take that trade when you need the thing you are getting. Do not take it because the product page sounds impressive.

BigQuery is not in this comparison

BigQuery gets listed alongside the databases and it belongs in a different conversation. It is an analytical warehouse: columnar storage, serverless query execution, and pricing based on how much data each query scans.

It is superb at scanning billions of rows to answer an analytical question. It is a poor fit for serving a web application, because query latency is seconds rather than milliseconds and there is no concept of a fast indexed point lookup.

The mistake worth avoiding is pointing your application at BigQuery for user-facing reads. The second mistake is a dashboard that runs an unbounded scan on every page load, which is how people discover that per-query pricing is an interesting incentive structure.

The normal architecture is both: a transactional database serving the application, and a periodic export into the warehouse for analysis.

How to actually decide

Work through these in order and stop at the first one that fits.

1. Do you have relational data with joins, transactions and ad-hoc queries? Cloud SQL with PostgreSQL. This is most applications.
2. Do clients need to subscribe to data and receive live updates without a socket layer you maintain? Firestore.
3. Are you writing millions of events per second with a known key-based access pattern? Bigtable.
4. Have you genuinely saturated a large Cloud SQL primary with a mixed transactional and analytical load? AlloyDB.
5. Do you need strongly consistent writes across multiple regions, and can you justify the cost to a finance team? Spanner.
6. Is the question analytical rather than operational? BigQuery, alongside one of the above, not instead of it.

The step most often skipped is the first one. Relational is the default for a reason: it does not require you to know your query patterns in advance, which is useful, because on a new product you do not know them.

A schema you can query in ways you did not anticipate is worth a great deal more than a scaling ceiling you will not reach. You can always denormalise later. Un-denormalising is much harder.

The costs that surprise people

Database pricing on any large cloud has more dimensions than the instance size, and the ones that catch people out are rarely the compute.

• Egress. Data leaving a region, or leaving the provider, is billed per gigabyte. An application in one region talking to a database in another pays for every query result, forever.
• Storage that only grows. Most managed database storage auto-expands and does not shrink when you delete rows. Reclaiming it means a maintenance operation, not a checkbox.
• Backups and point-in-time recovery, which are separate line items from the instance and scale with retention.
• High availability, which typically means paying for a standby instance that does nothing until the day it does everything.
• Per-query pricing on the warehouse, where one badly written dashboard query on a schedule can cost more than the database it is reporting on.

The general shape: the instance is the number on the pricing page, and the total is that number plus several others that depend on how the system is arranged rather than how big it is.

Worth noting for comparison, because it is the thing most people are actually trying to work out: a managed Postgres or MySQL on RunxBuild starts at four dollars a month on the Dev plan and six on Basic, with backups, connection limits and private networking included, and the private network between a service and its database means queries do not cross a billable boundary.

Migrating in and out

One practical point that matters more than most feature comparisons: how hard is it to leave.

Cloud SQL and AlloyDB speak standard PostgreSQL and MySQL. A dump and restore moves you in or out, and your application code does not change because it was written against the engine, not the platform.

pg_dump -Fc 'postgresql://user:pass@source-host:5432/appdb' > appdb.dump
pg_restore -d 'postgresql://user:pass@target-host:5432/appdb' appdb.dump

Firestore, Bigtable and Spanner do not work that way. Their data models and query APIs are specific to them, so leaving means an export, a transformation, and a rewrite of every query in your application. That is not an argument against them, but it is a cost that belongs in the decision rather than in a future quarter.

If you are unsure which you need, the portable option is also the reversible one, and reversibility is usually worth more at the start of a project than any ceiling you are not near.

How this fits the rest of the stack

Most of the difficulty in picking a database is that the comparison is presented as a feature matrix when the real question is much smaller: does this application have relational data, and does it have a scaling problem it can actually name. If the answers are yes and no, the decision is made. Once you know which shape you need, the RunxBuild hosting calculator is a quick way to see the database line next to the service, the storage and the bandwidth, so the whole figure is visible rather than just the instance.

Useful related references:

• GCP vs AWS: Pricing, Network, and When to Pick Each
• Decentralized Computing vs Cloud Computing: AWS/GCP vs DePIN
• Competitors for AWS: GCP, Azure, and the Smaller Clouds
• Databases on RunxBuild

FAQ

Which GCP database should I use for a web application?

Cloud SQL running PostgreSQL, for almost all of them. It is an ordinary managed relational database, it matches what you develop against locally, and it does not require you to know your query patterns in advance. Move on from it when you can name the specific limit you have hit.

What is the difference between Cloud SQL and AlloyDB?

Both are managed and PostgreSQL-compatible. AlloyDB rearchitects the storage layer for heavier mixed transactional and analytical workloads and costs considerably more. It is worth it when a large Cloud SQL primary is genuinely saturated, and it is not worth it before that.

Is BigQuery a database?

It is an analytical warehouse rather than an operational database. Queries scan large volumes and return in seconds, and pricing is based on bytes scanned. It is the wrong thing to serve a web application from, and the right thing to analyse that application’s data in, alongside a transactional database.

When should I choose Firestore over a relational database?

When clients need live updates pushed to them and offline support, and you would otherwise be building a synchronisation layer yourself. Accept in exchange that there are no joins, aggregates are limited, and compound queries need indexes declared in advance.

What makes cloud database bills larger than expected?

Usually not the instance. Cross-region egress on every query result, storage that grows and does not shrink, backup retention, a standby instance for high availability, and scheduled analytical queries priced per byte scanned. Keeping an application and its database on the same private network removes the largest of those.