Google Cloud added a serverless tier to Spanner on Friday, and the pricing change is more consequential than any feature. Spanner has historically required provisioned capacity billed by node or processing unit, with a practical minimum around $65 a month for the smallest instance and a real minimum closer to $700 for anything running production traffic with the availability guarantees people buy Spanner for. The serverless tier bills per request unit and per gigabyte of storage with no floor, which means a low-traffic application pays a few dollars a month. That opens Spanner to a class of workload that has always chosen Postgres instead.
What Spanner is for
Spanner provides external consistency across regions, meaning a transaction that commits in Tokyo is immediately visible to a read in Frankfurt with a guaranteed ordering, backed by TrueTime and Google's atomic clock infrastructure. That property is genuinely difficult to build and Google is one of very few operators who can offer it. For financial systems, inventory, and anything where two data centers disagreeing about state causes real damage, it is the reason to pay.
The cost of that guarantee has been price and operational rigidity. You provision capacity, you monitor CPU utilization, and you scale nodes up before you need them because scaling takes minutes. Applications with spiky or unpredictable traffic either overprovision or accept latency during ramps. That model made sense when Spanner's customers were large enterprises with steady load and makes less sense for the workloads Google now wants.
How the serverless tier works
Requests are metered in Spanner request units, a composite of CPU, memory, and IO consumed. A simple point read costs one unit and a complex query costs proportionally more, with the cost visible in query explain output before you run it in production. Pricing is $0.32 per million request units in a regional configuration and $1.10 per million in a multi-region one, plus $0.28 per gigabyte-month for storage. There is no minimum and no charge for an idle database.
Cold behavior is the question everyone asked first. Google says a serverless Spanner instance with no traffic for an extended period serves its first request in under 400 milliseconds, and sustained testing at low request rates produced p99 latencies around 22 milliseconds for point reads, which is consistent with provisioned instances. The mechanism is that serverless instances share underlying capacity rather than spinning down entirely, which Google can afford because it runs Spanner for its own products at enormous scale.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
The competitive target
The obvious comparison is DynamoDB, which has offered on-demand billing since 2018 and owns the mental default for serverless databases at AWS. DynamoDB is cheaper for simple key-value access and does not offer cross-region strong consistency or SQL. Spanner's pitch is that you get relational semantics and global consistency at a price that no longer requires a business case.
The less obvious competitor is CockroachDB, which built its entire product around being a Spanner alternative you can run anywhere and which has a serverless tier that has been well received. Cockroach's advantage is portability and a Postgres-compatible wire protocol. Spanner's PostgreSQL interface has improved substantially and still diverges in ways that matter for ORM compatibility. A startup choosing between them now compares on lock-in rather than on price, which is a better position for Cockroach than the previous comparison was.
When serverless is the wrong choice
Request-unit billing punishes inefficient queries in a way provisioned capacity does not. A full table scan on a provisioned instance consumes CPU you already paid for. On serverless it generates a line item. Google's own guidance suggests workloads above roughly 40 percent sustained utilization of a provisioned node are cheaper provisioned, and several early testers found the crossover lower than that, closer to 25 percent, once they accounted for analytical queries.
The practical approach is to start serverless and watch the bill. Google supports converting between modes without downtime, which removes the migration risk that usually makes this decision permanent. What it does not remove is the discipline required to keep queries efficient, and teams accustomed to provisioned capacity will have an uncomfortable first month when the cost of their reporting queries becomes visible.
What this says about Google Cloud's strategy
Google has spent three years making its differentiated infrastructure available at prices that do not require an enterprise contract, with BigQuery, Bigtable, and now Spanner all gaining consumption tiers. The reasoning is that developers choose databases early and stay for a decade, and that a pricing floor keeping Spanner out of side projects also keeps it out of the companies those projects become.
Whether it works depends on developer experience more than price. Spanner's tooling, local emulator, and ecosystem support remain behind Postgres by a wide margin, and no amount of pricing fixes an ORM that does not quite work. Google has been investing there, with improved Prisma and SQLAlchemy support shipping this year. The database is excellent and the surrounding experience is the reason people have not chosen it. The local emulator in particular has improved from unusable to merely awkward, which sounds like faint praise and matters enormously, because a developer who cannot run the database on a laptop will not choose it regardless of what the production system offers.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Kubernetes
