Fourteen years of WordPress work, and local databases still behave more like glass ornaments than tools. If a local environment has ever died on you right before a client demo because a migration went sideways, you know the feeling. Managed instances, manual snapshots and a pile of local Docker containers are running out of road now that agents write a real share of the code. That is the gap Ghost Database for AI aims at: infrastructure you throw away instead of nurse.
The usual advice is to point your agents at one persistent staging database and hope nothing catches fire. It catches fire. An agent needs room to experiment, fork and wreck an environment without stalling everyone else’s work, and a single shared database gives it none of that. Ghost calls itself an “agent-first” Postgres platform, and that is the problem it starts from.
What Ghost database for AI actually is
Ghost is a Postgres platform built around short-lived databases. Instead of curating one long-lived instance, you or your agent can create, fork and destroy whole databases in seconds. It also speaks the Model Context Protocol (MCP), so tools like Claude Code or Cursor can work on your schema directly.
I put this into a client’s workflow recently. They had been fighting AI database standards and losing hours to manual staging resets every time their agent got its logic wrong. Now the agent forks a copy, runs the experiment, and throws the fork away when the results are garbage. Their dev velocity roughly tripled.
Setting up the Ghost MCP server
The awkward part of most agent workflows is the gap between the model and the database. You end up pasting connection strings and schema DDL by hand. Ghost ships an MCP server instead. Here is how to get it running locally, in PowerShell if you are on Windows or in Bash otherwise.
# Install Ghost CLI
curl -fsSL https://install.ghost.build | sh
# Login via GitHub
ghost login
# Install MCP configuration for your agent (e.g., Cursor or Claude)
ghost mcp installAfter that, the agent stops guessing at your tables. It calls ghost_schema and reads the real structure, which is what kills the hallucinated column names in agent-written SQL.
A war story: parallel index tuning and race conditions
Last week I was chasing a slow query on a busy WooCommerce site: 500,000 rows, no index. Rather than trying one index at a time on the shared dev server, I used a Ghost Database for AI workflow and forked three identical copies at once, then had the agent test a B-tree index on the first, a hash index on the second and a covering index on the third.
Running those tests one after another is the obvious approach and also the slow one. Forking in Ghost is quick enough that it felt like working in a code sandbox. This is the sort of SQL the agent ran on each fork, with nothing stepping on anything else:
-- Agent testing a B-tree strategy on Fork A
CREATE INDEX idx_sales_order_id ON sales_order_items(sales_order_id);
EXPLAIN ANALYZE SELECT * FROM sales_order_items WHERE sales_order_id = 9932;
-- Result: 0.131 ms vs 25.8 ms baseline.The forks were isolated, so table locks and race conditions were not my problem while the agent hammered away at its experiments. That combination is what vector DB alternatives tend to miss: they are elastic, but they do not give you relational guarantees.
Production versus prototype
Do not move your production Postgres instance onto Ghost yet. It is very good for proofs of concept, testing and agent-led migrations. It is not a swap for a long-lived, high-availability production cluster. What it gives you is programmability and databases you can throw away.
Think of it as a Git branch for your data. Nobody runs a live site off a temporary feature branch, and nobody wants to work without branches either. Ghost puts that same habit at the database layer.
If this kind of plumbing is eating your dev hours, I can take it off your hands. I have been working on WordPress since the 4.x days.
What I would use Ghost for
Treating the database as precious and breakable is starting to look like a habit rather than a requirement. Agents move quickly, and the infrastructure under them has to keep up or you spend your day cleaning up after it. Ghost is the first tool I have used that treats Postgres about as loosely as we treat code. The official Ghost documentation has the technical specifics.
