Your Coding Agent Can Bring Its Own Databases

Short version: give a coding agent one Layerbase API key and it can provision real databases instead of improvising storage. In this run Claude Code created four engines in 38 seconds, verified each connection rather than trusting the create response, and wrote no teardown step, because every database carried a TTL from the moment it existed. The whole loop runs on the free plan if you stay on Postgres and Valkey; the two heavier engines below are why this particular run sat on Pro.

Ask a coding agent to build a feature that needs a cache, and watch what it does about storage. It writes a docker-compose you didn't ask for, or tucks a SQLite file next to your source, or fakes the whole layer with an in-memory map and a TODO. The code is usually fine. The storage is improvised, because the agent had nowhere real to put it.

So I gave Claude Code a Layerbase API key and a one-paragraph brief. It stood up a four-database stack in 38 seconds, verified every connection, wrote state to the layers and read it back, and never wrote a teardown step. Nothing was left behind anyway, because every database it created carried an expiry from the moment it existed.

One thing before the transcript: you do not need a paid plan for this. The free tier includes PostgreSQL and Valkey, which is the database-plus-cache pair most projects reach for first, and API keys work there exactly the same way. Two of the four engines below are Pro engines, and I'll point out where that matters.

The brief

Build the four-layer stack from the small-stack post: durable Postgres for state, a cache for working memory, a vector store for retrieval, something columnar for run traces. Make them transient, with TTLs. Verify each connection instead of trusting a create response.

That was the whole thing. No engine versions, no region, no naming scheme, no teardown plan. The gaps were deliberate. What I left out is what I wanted to watch it handle.

The run

layerbase cloud create agent-pg      --engine postgresql --ttl 1h --json
layerbase cloud create agent-cache   --engine valkey     --ttl 1h --json
layerbase cloud create agent-vectors --engine qdrant     --ttl 1h --json
layerbase cloud create agent-traces  --engine clickhouse --ttl 1h --json

The --ttl 1h was the agent's own choice, not something I asked for. The skill it had installed says transient is the default shape for scratch work, and an hour is the floor. You can go up to 72.

34.1 seconds of wall clock, back to back from a laptop. Three came back "status": "running". ClickHouse answered in half a second claiming "provisioning", and the agent polled until that flipped. Worth knowing if you script this: one engine in four hands you a handle to something that isn't up yet.

Then it checked its work instead of trusting the create responses. layerbase cloud url returned a connection string per database, and it tried all four. Postgres answered select version() with PostgreSQL 18.4. Valkey answered PONG. Qdrant returned its version document over HTTPS. ClickHouse got a socket check rather than a query, because layerbase cloud connect shells out to a clickhouse-client I don't have installed on that laptop.

First create to last verified connection: 38.3 seconds. One credential. No signup flows, no dashboards, no verification email arriving mid-session.

Valkey took one detour worth mentioning. The naive redis-cli -u ... fails, because the endpoint routes by TLS servername, and the error message says exactly that and names the option to set. The agent recovered in one turn. Error messages that name their own fix matter a lot more when the reader is a machine.

And about handing an agent a key at all: this was my own account and an account-scoped key, deliberately. If that makes you nervous, good. Layerbase keys can be scoped to a single database, and the scope is enforced in the cloud API's auth layer, so a scoped key reaching outside its database gets a 403. Give your agent a scoped key, or an account of its own.

It used them, too

Standing a stack up is the easy half. A second session got the same key and one addition to the brief: use the layers, don't just create them.

Postgres took the durable checkpoint table and handed a row back:

create table agent_checkpoint (
  id         bigserial primary key,
  step       text not null,
  status     text not null,
  payload    jsonb not null,
  updated_at timestamptz not null default now()
);

insert into agent_checkpoint (step, status, payload) values
  ('fetch_sources', 'done',    '{"docs": 12, "tokens": 8431}'),
  ('rank_chunks',   'done',    '{"kept": 5, "dropped": 7}'),
  ('draft_answer',  'running', '{"attempt": 2}');

select id, step, status, payload from agent_checkpoint where status = 'running';

 id |     step     | status  |    payload
----+--------------+---------+----------------
  3 | draft_answer | running | {"attempt": 2}
(1 row)

Valkey held the working copy of that same checkpoint, with an expiry of its own, plus a counter:

$ layerbase redis-cli usage-cache
SETEX agent:run42:checkpoint 900 "step=draft_answer tokens=8431"
OK
GET agent:run42:checkpoint
step=draft_answer tokens=8431
TTL agent:run42:checkpoint
900
INCR agent:run42:tool_calls
1

Those two layers, the checkpoint table and the cache, are the free-tier pair. Everything in the two blocks above runs on a $0 account.

Qdrant got a toy collection, three notes, and a nearest-neighbor query:

curl -s -X POST "$QDRANT_URL/collections/agent_memory/points/search" \
  -H "api-key: [redacted]" -H 'Content-Type: application/json' \
  -d '{"vector":[0.85,0.15,0.0,0.0],"limit":1,"with_payload":true}'

{"result":[{"id":1,"version":1,"score":0.99795175,"payload":{"note":"user prefers pnpm over npm"}}],"status":"ok","time":0.002072201}

ClickHouse got a connection check and no query, the same missing client as before. Three layers written to and read back, one connected but unqueried. That is a rough edge in our tooling, and I would rather print it than pretend I ran a query I didn't.

Nothing to clean up

The account the moment the last check passed:

NAME                    ENGINE        STATUS        EXPIRES
agent-traces            clickhouse    running       ttl 2026-08-02 17:33
agent-vectors           qdrant        running       ttl 2026-08-02 17:33
agent-cache             valkey        running       ttl 2026-08-02 17:33
agent-pg                postgresql    running       ttl 2026-08-02 17:33
... my regular databases below them, every EXPIRES cell a dash

Four rows with a hard expiry, stamped one hour after each create, to the second.

This is the part I actually care about. An agent will eventually crash between the create and the delete. It hits a rate limit, loses its session, gets killed mid-run. If cleanup is a step the agent has to remember, some fraction of runs leave debris behind forever, and the debris is your problem. Here the delete is the platform's job. A crashed run costs nothing and strands nothing.

Where this fits

The transcript is a demo. The loop is not. Three places I'd actually point it at:

A proof of concept. Hand the agent a key and a spec on Friday. It provisions what the demo needs on a 72 hour TTL, builds against real engines instead of mocks, and by Monday the whole stack has deleted itself. You review a working demo, not a docker-compose someone has to remember to tear down.

CI. A database per test run, created inside the workflow, gone when the TTL says so even if the job is cancelled or the runner dies:

- run: |
    DATABASE_URL=$(layerbase cloud create ci-${{ github.run_id }} \
      --engine postgresql --ttl 2h --json --show-secrets | jq -r .connectionString)

The full pipeline version, including branch-per-PR from a seeded parent, is in databases for CI and AI agents.

Any agent, not just Claude Code. The CLI is plain commands, so Codex, Cursor, Gemini CLI, or a cron job runs the identical flow. npx layerbase agent init drops a skill into your repo that mostly tells the agent to fetch layerbase.com/agents.md before stating any price, limit, or engine, so it reads today's answer instead of its training data.

What it costs

The free plan is $0 with no card: 2 databases, 5 GB, 8 engines including the Postgres and Valkey used above, and 5 API-key creates a month. That is enough to hand an agent a key this afternoon and watch it work.

Pro is $15/month, flat: up to 10 databases across all 18 cloud engines, 500 API-key creates a month, no compute-hour meter, no per-command charge. The run above sat on Pro because Qdrant and ClickHouse are Pro engines. The four databases held four slots for an hour and then zero, and the bill afterward was $15, the same as before.

The alternative shape is four vendors: Neon for Postgres, Upstash for the cache, Qdrant Cloud, ClickHouse Cloud. Four keys, four dashboards, four incompatible meters, which I worked through in the multi-database tax. A human forgets one of the four dashboards. An agent has to hold all four credentials and SDKs in context at once.

Why this isn't Neon

Neon is very good at this. They publish about 350 millisecond database creation, faster than anything above, they have a real Agent Plan, they ship claimable Postgres at pg.new with no account at all, and in May 2025 they reported that "over 80% of databases were being created by AI agents rather than humans". They saw this coming first.

What their answer doesn't cover is the shape of the stack. Every agent-database vendor sells one engine: Neon and Supabase are Postgres, PlanetScale is MySQL and Postgres, Turso is SQLite. That's fine while the agent only needs a relational database, and it's four vendors the moment it has working memory to checkpoint and traces to grade. Layerbase isn't faster than Neon. It's broader, on one credential.

FAQ

Do I need a paid plan to give an agent a key?

No. API keys work identically on the free plan, which covers PostgreSQL and Valkey, the database-plus-cache pair most projects reach for first. The run in this post used Pro only because Qdrant and ClickHouse are Pro engines.

What stops an agent from leaving databases behind?

The --ttl flag. A database created with --ttl 1h deletes itself an hour later whether or not anything remembers to clean up. That is why the transcript above has no teardown step: there was nothing to tear down.

Does this work with agents other than Claude Code?

Yes, because the interface is a CLI rather than an SDK. Codex, Cursor, Gemini CLI, or a cron job run the identical commands. npx layerbase agent init drops a skill into your repo whose main instruction is to fetch layerbase.com/agents.md before stating any price, limit, or engine, so the agent reads the current answer rather than whatever was in its training data.

Why not just use Neon?

For a Postgres-only agent, Neon is excellent and faster at creation than anything here. The case for Layerbase is shape rather than speed: every agent-database vendor sells one engine, so the moment your agent needs working memory to checkpoint and traces to grade alongside its relational store, you are holding four credentials and four SDKs. This is one.

How does an agent know what things cost?

By reading, not by remembering. There is one flat price per plan with no meters, which is a fact an agent can state correctly, and agents.md is a live document it fetches at the time of the answer. A metered price is something an agent has to estimate, and estimates are where it invents numbers.

Appendix: what an agent can reach for

Layerbase Cloud hosts 18 engines on one credential. Each tier includes everything to the left of it:

FerretDB is the document answer on Cloud: it speaks the MongoDB wire protocol, so Mongo drivers connect unchanged. MongoDB itself is licensed in a way we cannot host, which I would rather name than leave unexplained.

To hand your own agent a key: create a database, mint a key in settings, and run npx layerbase agent init in your repo.