AlloyDB Express creates Postgres databases in under two seconds for coding agents. Review the upgrade button
Google's AlloyDB Express, in preview, gives developers and AI coding agents throwaway Postgres databases that scale to zero, then upgrade in one click. The risk moves from creation to promotion.
Listen to this article · 4 min
AI-generated narration of the full article.
A coding agent building a feature needs a database to test against. Until now, that meant asking someone, reusing a shared development instance, or waiting several minutes for a new one. Each of those slowed the agent down, and each was also a moment when a person noticed that a database was being created.
Google’s AlloyDB Express, announced in preview on November 4, removes the wait. Google says it creates a PostgreSQL-compatible database in under two seconds, and it is aimed explicitly at developers and AI coding agents.
What it offers
AlloyDB Express scales to zero: it pauses after 15 minutes without activity and wakes within seconds when a query arrives. Pricing follows that design. Active compute costs US$0.115 per compute-unit hour, billed by the second; paused compute costs nothing; storage costs US$0.30 per GB-month for space actually used; and there is a free tier of 50 compute units a month. Google describes the footprint as small, one to two vCPUs and 20 GB of storage.
It includes the AI features of full AlloyDB: pgvector and Google’s ScaNN vector indexes, Gemini calls inside SQL, and natural-language-to-SQL tools. Security options include public DNS endpoints that mask IP addresses and block incoming traffic until explicitly allowed, private connectivity, IAM, VPC Service Controls and native PostgreSQL roles.
The key feature is the last one: a one-click upgrade to full AlloyDB, keeping data, schemas, users and connection strings, and adding high availability, read replicas and disaster recovery.
Fast creation is fine. Silent promotion is not
A database that appears in two seconds and costs nothing while idle is the right tool for agents. Throwaway environments are safer than shared ones: an agent that wrecks its own scratch database harms nobody.
The risk is in two other places.
Sprawl. When databases cost nothing at rest, nobody deletes them. Each one holds whatever the agent loaded, which in practice is often a copy of real data “just for testing”. Six months later, a security review finds hundreds of small databases with customer records and no owner. We described the same pattern for agents that become authors of production changes: the volume of small actions, not any single one, is what overwhelms the controls built for people.
Promotion. The one-click upgrade keeps the connection strings, which is convenient and is exactly the problem. A prototype database, created by an agent, with schemas and roles nobody reviewed, can become a production database without changing a line of the application that uses it. The moment that matters for review is no longer creation. It is the upgrade.
Three rules worth setting now
- Tag every database with its creator, human or agent, and an expiry date. Delete on expiry unless someone renews it.
- No production data in Express instances, enforced with VPC Service Controls and data access policies, not with a guideline. Agents should test on synthetic or masked data.
- Treat the upgrade as a change request. Restrict the permission to promote an instance to full AlloyDB to a role that requires review: schema, roles, network exposure and backup settings.
AlloyDB Express is a good example of infrastructure redesigned for the speed of coding agents. The governance has to be redesigned for the same speed, and the cheapest place to do it is before the first hundred databases exist.