AlloyDB Express: Postgres in ~2 seconds for developers and agents

← All field guides

Your prototype needs more than a convincing screen

Imagine building a customer feedback app. Your coding assistant has produced a polished screen with cards, filters, and a search box. Now a stakeholder asks: will a submission survive a refresh? Can two teammates use it? Can we find similar feedback without knowing the exact words? Those questions turn a visual mockup into an application prototype.

AlloyDB Express gives developers and coding agents a quickly provisioned PostgreSQL database, with compute that pauses after 15 idle minutes. It also supports vector search, hybrid search, and model access from SQL. For your prototype, that means you can connect a real data layer early, test the idea, and improve the app with a coding assistant.

This guide combines documented product capabilities with a proposed prototype walkthrough. We have not benchmarked or deployed the example application. Product facts below were checked on 6 November 2026. The workflow, examples, and evaluation criteria are our recommendations.

What Express gives your prototype

Use Express as the database behind the application you are building: save form submissions, retrieve records, and try AI-powered search. Your coding assistant can help write the schema and backend, while you check that the resulting app behaves as intended.

Start with sample data you control. Express does not automatically provide a live copy of your production database. If your goal is an agent analyzing existing production records, evaluate that access pattern separately; Google's PostgreSQL for agents is a different offering.

Choose the smallest useful version of your app

For our example, build a feedback inbox for a small product team. The first version lets a teammate submit feedback, browse saved items, and change an item's status. Add semantic search only after that basic journey works. This keeps the prototype focused on a question you can answer: can the team find and act on useful feedback?

AlloyDB supplies the database portion. Your prototype still needs a frontend, application backend, hosting, and an authentication design. Draw that path before prompting your assistant: browser → application API → database. Keep database credentials on the server, outside browser code and screenshots.

What the preview means for your demo

The Express technical overview specifies PostgreSQL 18, a single zonal primary, 1 or 2 vCPUs, and 4 or 8 GB RAM. Storage stops accepting writes at 20 GB. Connections are capped at 200. There are no managed backups, PITR, HA, disaster recovery, CMEK, or SLA in this configuration.

It lists approximately two seconds to provision public-DNS connectivity, twenty seconds for Private Service Connect, and approximately twenty seconds to resume. The technical documentation lists Terraform and Config Connector as unsupported for Express. Use the documented console, CLI, REST, or MCP management path, and recheck support before automating.

These limits change how we would design a trial. Use rebuildable data, cap concurrency, and measure the first connection after idle separately from a warm query. Do not interpret a successful small test as evidence that a large production dataset will behave identically. Do not make a preview environment the only place an important record exists.

Walk through one working prototype

This is our proposed build sequence, not a tested starter project. You can create the database through the console and let your assistant build the application around it; automating provisioning is optional.

1. Write the demo's acceptance criteria. Specify that a teammate can submit feedback, see it after a refresh, change its status, and search their own team's records. Give the assistant these observable outcomes before asking it to generate screens.
2. Create a dedicated development database. Choose a supported region and a connection method your backend can reach. Keep the resource name and connection configuration in your project notes so you can find and remove it later.
3. Ask for a small schema and a repeatable setup. For this example, start with teams, memberships, and feedback records. Have the assistant save schema changes as migrations—versioned instructions for changing the database—along with a script that loads sample data.
4. Connect the backend, then the UI. Store credentials in the backend's secret configuration. Use a restricted application database identity for ordinary requests. Confirm that a submitted record reaches the database before adding more visual polish.
5. Try realistic sample records. Include similar feedback from two teams, empty input, a long description, and a repeated submission. Check that the backend enforces membership; hiding another team's records in the UI is insufficient.
6. Invite a small demo audience. Watch someone complete the journey without coaching. Record confusing steps and failed requests. Ask the coding assistant to fix one observed problem at a time, then repeat the same check.

Keep the setup reproducible. If a schema experiment goes wrong, you should be able to recreate the prototype from source and sample data. Save a short demo script alongside the code so the next iteration can be checked against the same user journey.

Where MCP fits

The management guide documents an AlloyDB remote MCP endpoint at https://alloydb.googleapis.com/mcp. Its creation sequence calls create_cluster, polls get_operation, and then calls create_instance. CLI creation similarly separates the cluster and primary instance; the instance starts at 1 vCPU and can subsequently be resized.

MCP provides the interface through which an agent requests operations. Your tool policy still decides which requests are allowed. For a first prototype, manual console setup may be enough. Add MCP provisioning when repeatedly creating environments becomes a real bottleneck; limit the assistant to the project and operations your prototype needs.

Retries need special care. If a create request times out, first reconcile whether the resource already exists. Otherwise, a retry loop can create duplicate environments. Use a stable task identifier, record the returned resource name outside the model's conversation, and make cleanup target that exact resource.

Connectivity is part of the experiment

The same management guide says console creation enables public DNS and PSC by default, while CLI, REST, and MCP default to PSC at cluster creation. Public DNS must be enabled at the instance level; PSC consumer projects must be allowed. Public connections also require appropriate network authorization. A resource reporting ready does not prove your test runner can reach it.

We would therefore distinguish four milestones in logs: resource created, network reachable, database authenticated, and first record saved. This prevents an agent from responding to a networking problem by repeatedly changing application code.

AI inside Postgres: useful, but still a design choice

Express supports pgvector and ScaNN search, Gemini access from SQL, and natural-language query generation. Putting retrieval beside relational data can simplify a prototype: a document, its organization identifier, its access metadata, and its embedding can participate in the same data model.

Consider a question such as “Find feedback similar to this item for my team.” Similarity alone is insufficient. The system also needs to know which organization the caller belongs to, whether deleted documents should appear, and whether the source is current. Design these constraints before choosing a similarity threshold.

Our suggested sample dataset includes a deliberately more similar document owned by another organization. If the system returns it, better retrieval quality has exposed an authorization defect. Repeat the test through the application's real access path; a privileged test connection can hide the problem.

Also separate deterministic assertions from model quality. Check schema constraints and tenant boundaries exactly. Evaluate semantic relevance against a labeled set. If a query calls an external model, record the model configuration, latency, and failure behavior. Database execution time alone no longer describes the user's total wait.

This database can sit behind an analytics tool delivered through MCP Apps in an agent's chat. The widget still needs a trusted metrics definition and a server-side authorization boundary. A conversational interface does not make unrestricted SQL the right tool contract.

What scale-to-zero actually changes in the budget

The pricing page currently says billing starts in December 2026. Its regional tables list Oregon (us-west1) at $0.115 per CU-hour and $0.30 per GiB-month, versus Singapore at $0.141 and $0.369. Compute is billed by the second; storage remains billable when paused. The monthly allowance is shared per billing account and limited to the first twelve months: 50 compute units and 2 GB storage. Confirm the allowance's metering in your billing account; the page's wording uses “compute units,” while usage rates use CU-hours.

Illustrative gross calculation: one Oregon prototype at 1 CU for three total billable hours per day across twenty days consumes 60 CU-hours: $6.90 compute. If it retains 1 GiB for a full month, storage adds $0.30. That is $7.20 before allowances, discounts, networking, model calls, and other charges—not a current bill or a measured workload.

The important input is billable time, not time spent typing. Our calculation assumes the three hours already include any idle interval before suspension. Repeatedly waking environments can produce a different bill from one continuous test session. A health check that prevents inactivity may also defeat the savings you expected; measure actual suspension behavior.

Set a budget for the experiment and review usage after your first few sessions. Keep an inventory of abandoned prototypes: paused compute does not remove retained storage. Budget alerts help you notice spending; also establish who will stop or delete resources when the experiment ends.

Decide whether the prototype earned its next iteration

If you are testing navigation or copy, static sample data may answer your question. If you need persistence, shared records, or database-backed search, a real backend becomes useful. For ordinary SQL behavior, local Postgres is a useful baseline. Evaluate Express when its managed environment or AlloyDB AI features serve the experience you are trying to demonstrate.

• Does the main journey work? Have a fresh user submit and retrieve a record without instructions. Check the stored result rather than relying on a success toast.
• Does it survive an idle period? Try opening the demo after leaving it unused. Provide a clear loading state and appropriate connection handling; measure the actual delay.
• Can you trust the sample data? Use synthetic records you can recreate. Test two team accounts and confirm that each sees only authorized records.
• Does AI improve the experience? Compare similar-feedback search with a simple keyword filter on the same examples. Keep the added feature only if users find it useful.
• Can another builder run it? Hand over the repository and setup instructions. A prototype that depends on an undocumented chat history is hard to maintain.

Graduating to production is a separate decision

According to the Express overview, an in-place upgrade preserves data, credentials, network configuration, and the connection string. Downgrading back is unsupported. Treat the upgrade as a change to operating responsibility, not simply a larger machine.

Before that change, establish recovery objectives, restore procedures, access reviews, capacity expectations, and alert ownership. Confirm the production configuration meets them. Re-run the application checks after the change, and verify that the team can recover from a mistake without relying on the coding agent that created the system.

For an application prototyper, success is a working user journey that teaches you something about the idea. Use Express to test persistence, shared data, or AI search where they matter. Keep the scope small, make the demo reproducible, and use what you learn to decide whether the application deserves a production investment.