Ghost shipped this month. The launch copy calls it “the first database built for agents.”
That sentence is doing a lot of work. It’s also the kind of line that hits differently if you’ve watched the AI infrastructure market for the last two years — every couple of months, something gets crowned the first something built for agents. Vector stores. RAG pipelines. Browser harnesses. Database is the latest entry. Sometimes the claim earns its place. Sometimes it’s a Postgres wrapper with good packaging.
So let’s strip the varnish. See the video below for a take on this:
What it actually is
Underneath the framing, Ghost is a managed Postgres service with three good ideas glued to it.
The first is fast provisioning: sub-two-minute database creation, schema generation, and seeding. The second is forking; disposable copies of a database, branched the way you’d branch code. The third, and the one that matters most, is a built-in MCP server. Plug Ghost into Codex, Claude Code, or Cursor, and the agent doesn’t ask you for a connection string. It runs the whole loop itself: create, migrate, query, tear down.
None of these are individually new. Postgres has been forkable on Neon for years. Provisioning has been measured in seconds on Supabase since launch. MCP servers exist for plenty of databases now. What Ghost does is package the three together and design the workflow around an agent rather than a developer. That packaging is the product.
Whether you should care depends on which side of the fence you sit. If you’re prototyping AI applications and your bottleneck is “spin up a realistic dataset to test against,” Ghost collapses a half-day of work into ninety seconds. If you’re running production data, it’s not for you yet — and Ghost’s own documentation is honest about that.
In the demo I saw the agent forks three copies of the same database in parallel, applies a different indexing strategy to each and benchmarks all three against the same query. Two minutes forty seconds, end to end. Result: a 200x speedup, with baseline, three variants, and measured numbers.
That’s not faster databases. That’s faster experimentation on databases. And the difference matters more than the headline number.
Performance tuning has historically been a senior-engineer rite of passage — equal parts intuition, scar tissue, and reading the manual at 11pm. Most of the actual work is sequential: hypothesis, change, measure, repeat. What Ghost is showing is that with cheap forks and an agent that can drive them, the whole loop becomes a parallel search problem. You don’t need to guess which index strategy will win. You try all of them at once, and the agent reports back.
This is the architectural shift worth paying attention to. The dashboard demo at the end of the article is fun but unsurprising — agents have been building CRUD apps for eighteen months. The fork-tune-measure loop is genuinely new behaviour, and it generalises beyond databases. Anywhere you have a configuration space and a measurable outcome — query plans, hyperparameters, prompts, infra topologies — the same pattern applies.
Three things to flag before anyone gets carried away
The fastest way to discredit a useful tool is to oversell it. Three caveats worth saying out loud.
- Data residency. Your databases live on Ghost’s cloud, not yours. The article notes this almost in passing, but if you’re in financial services, health, public sector, or anywhere that cares about data domicile, that single sentence is the answer to whether Ghost is in scope at all. Read the terms before you put real data anywhere near it.
- Read-only by default. The demo shows an agent being blocked from a destructive query because read-only mode was set at the database level. This is the right default, and Ghost deserves credit for shipping it. But it’s a default you still have to set. The same lesson Anthropic, OpenAI, and Google have been re-learning with computer-use agents applies here: agents will do exactly what you let them. Make destructive operations require explicit elevation, and treat the system prompt as a security boundary.
- Speed is not correctness. The example schemas in the launch demo dropped foreign keys, primary keys, and indexes “for now” — fine for a thirty-second clip, catastrophic for any database that survives past a sprint. If your agent is generating schemas without integrity constraints because that’s faster, the agent is wrong and you should say so in the system prompt. Disposable infrastructure encourages disposable thinking, and disposable thinking is how production data gets lost.
What to actually do this week
If you run POCs, workshops, or design-thinking sessions: try it. The free tier is generous, and the experience of prototyping a data structure live in front of a room of stakeholders is meaningfully different when the database appears in ninety seconds rather than after a week of platform tickets.
If you’re an architect: the interesting question isn’t should we adopt Ghost. It’s what does our internal Postgres-as-a-service look like once agents are creating most of the databases? Build for that future. The answer will involve forkable test environments, default read-only postures, parallel performance experiments, and policy-as-code. You can build all of that on infrastructure you already control. Ghost is a useful preview of the workflow, not necessarily the platform.
If you’re running production data: don’t migrate. Do steal the workflow.
Forget Ghost specifically for a moment. What’s actually being staged here is a change in the relationship between developers and infrastructure.
For thirty years, databases have been precious. You provisioned one, you named it, you guarded it. The metaphors were architectural — foundation, backbone, system of record. Ghost — and the broader category it sits in — is reframing the database as something closer to a sandbox process: forkable, ephemeral, agent-driven, cheap to throw away. That reframing is fine for experimentation. It’s a category error for production. The challenge for the next two years is that the same primitives will be sold for both, and the line between them will blur exactly as fast as the marketing copy needs it to.
I want to believe in disposable infrastructure. I’ve seen too many half-finished migrations to believe in only disposable infrastructure.
The agents are already here. Whether your data layer is ready for them is a question of taste, governance, and which problems you’re actually trying to solve — not which tool ships next.
RogueLoop. Where AI meets real-world innovation.