Introduction
Giving an AI agent direct access to your production database is a great way to lose your weekend.
Traditional databases are expensive to spin up, slow to fork, and have a meaningful blast radius when
an agent makes a mistake. One DROP TABLE
in the wrong session and you’re restoring from backups.
Ghost.build reframes the problem. It’s a database designed for AI agents from the ground up: free tier with unlimited databases and forks, instant parallel cloning, an MCP server that drops into Claude Code, Codex, or Cursor in one command, and the kind of pricing that makes you stop treating databases as precious. This guide walks through what it is, how to install it, and four real experiments — including running ten databases in parallel to test ten different data-migration strategies before touching production.
📚 Table of contents
- Why traditional databases hurt with AI agents
- What Ghost.build does differently
- Installing Ghost and the MCP server
- Demo 1 — a reading log database from one prompt
- Demo 2 — a movie database with a Next.js dashboard
- Demo 3 — query optimization with three parallel forks
- Demo 4 — ten parallel forks for a real migration
- Free-tier limits and when to upgrade
- When to use Ghost (and when not to)
- Best practices
- Common mistakes
- Frequently asked questions
⚠️ Why traditional databases hurt with AI agents
Postgres, MySQL, even managed offerings like RDS or Supabase weren’t designed with autonomous agents in mind. The friction points show up fast.
- Spinning up is slow. New DB = minutes, not seconds
- Each instance costs money. So you don’t spin up ten
- Forking is rare and painful. Cloning a 50GB DB takes time and disk
- Auth is heavy. Connection strings, IAM roles, security groups
- Blast radius is real. An agent with admin can wreck production
- No built-in MCP. Bolted on, not designed for
👻 What Ghost.build does differently
Five design choices that change how it feels to use.
Instant spin-up
Create a new database in seconds. Forks are instant. You don’t wait, you don’t plan capacity.
First-class MCP server
Create, fork, query, delete, list — all through MCP. Claude, Codex, Cursor, all supported out of the box.
Unlimited forks on the free tier
Want to test 10 parallel migration strategies? Fork 10 times. No surprise bill.
Hard spending caps
You set a ceiling. Agent in a loop can’t accidentally rack up a $5,000 bill.
📦 Installing Ghost and the MCP server
Three commands. No account creation flow beyond a GitHub login.
- Install the CLI — copy the platform-specific install command from ghost.build docs.
- Run
ghost loginand authenticate via GitHub. - Run
ghost mcp installand pick your agent (Claude Code, Codex, Cursor). - Restart Claude Code. Run
/mcpand verify ghost shows up with tools:create_database,execute_sql,fork_database,list_databases,delete_database.
📖 Demo 1 — reading log from one prompt
Prompt
“Spin up a new Ghost database called reading_log
with a schema for books: title, author, date finished, rating out of 5. Seed it with 10 AI/ML books.”
Claude calls the MCP, creates the DB, runs DDL, inserts seeds. Follow up with “what’s the average rating?” and “sort books by rating” — the agent runs SQL against the live database and returns formatted results. No DB client, no connection string, no setup.
🎬 Demo 2 — movies + Next.js dashboard
Crank up the scale. “Create movie_night
with title, director, year, genre, runtime, rating. Seed 100 movies across genres and decades.”
Then ask for a dashboard: “Build a one-page Next.js dashboard with shadcn/ui, connect to the
movie_night DB, show a movie table,
genre filter, and stat cards (total movies, avg rating, top director).”
Claude grabs the connection string for the underlying database, scaffolds Next.js, wires the dashboard to live queries. End-to-end app from two prompts. Memory across sessions is preserved — close Claude, reopen it, ask “what Ghost databases do I have?” and the list is there.
⚡ Demo 3 — query optimization with three parallel forks
Where Ghost actually shines: parallel experimentation on production-like data.
Setup prompt
“Create shop_analytics with
customers, orders, order_items, products, categories. Seed 100,000 customers, 500,000 orders, 1M
order items. No indexes beyond primary keys — I want it slow on purpose.”
Run the test query (top 10 customers by last-90-day spend, with order count and AOV). Baseline: roughly 1.8 seconds. Now the experiment:
Experiment prompt
“Fork three databases in parallel. Don’t wait for each fork to finish before starting the next one. On each fork, apply a different optimization: targeted indexes, materialized view, denormalized summary table. Benchmark the test query on each and rank them.”
The agent forks three DBs concurrently, applies each strategy, benchmarks, returns a ranked report. Pick the winner and apply it to the base DB — the forks stay untouched until you delete them, at zero cost.
🔟 Demo 4 — ten parallel forks for a real migration
Migrations are scary because they’re irreversible. Forking lets you test all the candidate strategies side by side without touching the source DB.
Setup
“Create users_base with 500
fake users: name, email, phone, created_at, updated_at. Make the phone column messy: 3% null, 2%
malformed, the rest valid but in mixed formats. Mix bad rows throughout.”
Experiment
“Fork users_base 10 times,
in parallel, no wait between forks. Try a different phone-cleanup strategy on each:
drop-bad-rows, backfill, regex normalize, quarantine table, formats list, etc. After cleanup, add
the NOT NULL + strict-format check. Compare strategies on rows kept, rows dropped, complexity, and
data quality.”
Ten forks running ten different migrations in the time it would have taken to write one. Pick the winner, apply to base, delete the rest. No production risk, no provisioning friction, no bill.
💰 Free-tier limits and when to upgrade
- Compute: 100 hours/month free
- Storage: 1 TB free
- Databases & forks: unlimited
- Spending caps: set hard limits at the project level
Most prototyping, experimentation, and personal-project use fits inside the free tier. Upgrade when you start serving live traffic or need compute beyond the 100-hour ceiling.
🚫 When not to use Ghost
- Web dashboards that need predictable, usage-based pricing — the free tier’s compute-hour model can surprise you
- Apps that need fine-grained cost attribution per tenant or per query
- Compliance-heavy workloads that mandate specific cloud regions or BYOK
- Production workloads at large scale — managed Postgres still wins on raw scale
The sweet spot is agent experimentation, prototyping, persistent memory for Claude/Codex sessions, and pre-production migration testing. For everything else, pair Ghost with a traditional database — Ghost as the experimentation playground, the managed DB as the source of truth.
✅ Best practices
- Treat databases as disposable. Spin them up freely, delete them when done.
- Fork before any destructive change. Test on the fork, apply to base only when confident.
- Run parallel forks for migrations. Strategy comparison is cheap and decisive.
- Use explicit names with the database name in the prompt. If you have many MCPs installed, “use Ghost” helps the agent route correctly.
- Cap spend at the project level. Cheap insurance against runaway agents.
- Nuke unused forks promptly. Even free, they consume mental overhead.
❌ Common mistakes
- Letting the agent fork sequentially instead of in parallel — specify “don’t wait”
- Forgetting to delete experiment forks — cluttering the dashboard, eating storage
- Testing on the base DB instead of a fork — that’s the whole point you came here to avoid
- Running production traffic through the free tier with no monitoring — check compute hours weekly
- Treating Ghost as a Postgres replacement — it’s a complement, not a swap
- Not setting a spending cap before handing the keys to an agent
Conclusion
Most databases hurt to use with AI agents because they were designed in an era when spinning up a new instance was a real decision. Ghost.build inverts that — databases become cheap, disposable, parallelizable. Once you’ve seen ten forks running ten migration strategies in the time it took to write one, going back to “test it in staging and pray” feels archaic.
Install it in five minutes. Pair it with Claude Code. Run the four demos in this article and the pattern clicks. From then on, “fork the DB and try it” is the new default for any change that touches data.
Related reading
-
MCP Explained: Build Your Own Server
The protocol powering Ghost.build’s Claude Code integration—understand MCP to extend or replace any step in the workflow.
-
When an AI Agent Deleted the Production Database
A real incident showing why forking before destructive operations—exactly what Ghost.build enables—matters in production.
-
Claude Code: Hands-On Deep Dive
A thorough walkthrough of Claude Code’s core workflows—the agent that Ghost.build’s MCP server is built to integrate with.