TLDR: ghost gives your agent instant, ephemeral postgres databases. unlimited databases, unlimited forks, 1tb storage, free. pair it with Memory Engine for memory, pg_textsearch for full-text search, TigerFS for files, and Ox for sandboxed execution. All postgres-native.
try Ghost today: curl -fsSL https://install.ghost.build | sh
your agent can reason. it can plan. it can call tools and write code and hold a conversation that feels almost human.
but ask it what it did yesterday and it doesn't know. ask it to store something for later and you’re the one figuring out where it goes. give two agents the same files and things break. tell it to run code safely and you're one bad rm -rf away from a really bad day.
agents are getting smarter everyday. we haven't spent nearly enough time giving them somewhere to be productive.
duct tape as ai infra
if you're building agents today, your infrastructure might look something like this:
neon or supabase for the database
mem0 or zep for memory
pinecone or pgvector for search
s3 for files
e2b for sandboxed execution
five services. it works. kind of.
until your agent's memory can't query its own database. until your sandbox can't read your agent's files. and what happens if the glue code holding everything together dissolves.
ghost is the database your agent is missing
traditional databases are designed to be permanent, and the ritual of DB setup feels permanent. you provision one, you name it, you size compute, you choose a cloud provider, and a cloud region. you care for it, you back it up, you keep it running for years. that's fine for human workflows. it's wrong for agents.
ghost gives your agent postgres databases that are instant, ephemeral, and disposable. provision them through CLI or MCP. no UI. a thousand databases for a thousand parallel sessions, free.
the mental model is git, not RDS. spin up a database the way a developer creates a branch. do work. if the work is good, keep it. if not, throw it away. fork before a risky migration. run experiments on the fork. merge or discard. databases become part of the workflow, not the infrastructure you worry about underneath it.
ghost is MCP/CLI only. your agent discovers it the same way it discovers any other tool, through MCP, and starts provisioning databases immediately. CLI works too, if that's more your speed. and because every ghost database is just postgres, your agent already knows how to use it. every LLM has postgres in the weights. schema design, queries, indexes, debugging. no proprietary query language. no SDK to learn. just SQL.
ghost does one thing and does it well. but because it's postgres, it pairs naturally with other tools that extend what your agent can do.
extend ghost with purpose-built tools
ghost gives your agent a database. that alone gets you pretty far. but agents need more than storage. they need memory, search, files, and safe execution. here's what plugs into ghost:
memory engine: persistent, temporal agent memory
pairs with ghost. works with any postgres.
your agent forgets everything between sessions. you've probably already tried to solve that with a vector database or a standalone memory service.
memory engine solves this inside postgres. when you pair it with ghost, your agent's memory and data live in the ghost space. y you can query memories with SQL. you can ask "what did this agent know about this user at 3pm on tuesday?" and get an answer, because memory engine understands time natively.
no separate vector database. no syncing between systems. no second bill. just postgres doing what postgres is good at.
the temporal part matters more than it sounds. most memory solutions treat memory like a flat store. things go in, things come out. memory engine tracks when things were true. when facts changed. when old information got superseded by new information. this is how human memory works and it's how agent memory should work too.
it's not just temporal either. memory engine lets your agent search its memory with keyword, semantic, faceted, and hierarchical search in the same query. under the hood, retrieval is powered by pg_textsearch, which combines BM25 for keyword precision with pgvector for semantic similarity. pg_textsearch also ships with every ghost database, so you get full-text search out of the box even if you're not using memory engine. no elasticsearch sidecar. no separate search cluster to sync and monitor.
tigerfs: a filesystem backed by postgres
pairs with ghost. works with any postgres.
agents create files constantly. reports, code, datasets, images, logs. most of that output ends up in s3, unstructured and impossible to query. tigerfs gives your agent a filesystem backed by postgres, so files become first-class data. transactions on writes, concurrent access from multiple agents, and metadata you can actually query.
two agents working on the same project both need to write files. tigerfs handles that without corruption. s3 doesn't.
search: vector, keyword, and hybrid search built into postgres
pairs with ghost. works with any postgres.
every ghost database ships with pg_textsearch and pgvectorscale. that gives you BM25 keyword search, vector semantic search, and hybrid search combining both. no elasticsearch. no pinecone. no separate system to sync.
you don't need to know how to set any of this up. ghost MCP includes skills that teach your agent how to configure search indexes, choose between keyword and semantic approaches, and wire up hybrid search with reciprocal rank fusion. tell your agent you need search on a table and it handles the rest.
this is also what powers memory engine's retrieval. when your agent searches its memories, it's using hybrid search under the hood: BM25 for keyword precision, pgvector for semantic similarity, combined and ranked. all inside postgres.
ox: sandboxed execution with full context
pairs with ghost. works with any postgres.
agents need to run code. ox gives them a sandboxed execution environment that's connected to their data but quarantined from their main branch. when paired with ghost, an ox sandbox can query the agent's database and read its tigerfs files directly. no API hops. no extra auth.
this is the difference between a sandbox and a workspace. your agent doesn't just execute code in isolation. it executes code in the context of everything it knows.
how people are building with ghost
ghost was in private preview for the past two months. here are some of the things beta testers built.
the code review agent
the agent picks up a PR. it forks its ghost database to get a clean copy of the current state. it spins up an ox sandbox, runs the test suite against the fork, and checks for regressions. it searches memory engine for past reviews on the same files. what broke last time. what patterns the team prefers. what feedback the author got previously. it writes its review, stores the results in tigerfs, and updates its memory with what it learned.
the research agent
the agent spins up a ghost database to store everything it finds. company profiles, product comparisons, pricing data. it writes raw reports to tigerfs as markdown files. it checks memory engine: have we researched this company before? what did we find last time? what changed? when it needs to crunch numbers, it forks the database into an ox sandbox so it can run analysis without touching the original data. when it's done, it stores what it learned with full temporal context. next quarter, the agent knows what the landscape looked like this quarter.
the multi-agent team
three agents, one project. one writes code. one writes docs. one runs tests. all three read and write files through tigerfs without stepping on each other. all three check memory engine so they don't duplicate work. all three get their own ox sandbox that can still query the shared ghost database. they share a substrate without sharing a failure mode.
the data exploration agent
a user asks "what would our metrics look like if we changed the pricing model?" the agent forks the ghost database. rewrites the pricing logic on the fork. reruns three months of transactions against the new model in an ox sandbox. doesn't like the result. forks again with a different model. runs it again. the user gets three scenarios in ten minutes. all run against real data. none of them touching production.
all on postgres
we are proud members of the postgres fan club. here's why we build on it:
postgres is battle-tested. it's been in production for 30+ years. it handles transactions, concurrent access, replication, and failure recovery. when your agent's infrastructure needs to be reliable, you want it built on something boring.
one substrate means zero glue code. when your database, memory, search, and files all run on postgres, they share the same transaction model, the same auth, the same query language. the integration layer doesn't exist because it doesn't need to.
we've been building on postgres for years. before ghost, we built timescaledb, one of the most widely-used postgres extensions for time-series data. memory engine's temporal capabilities come directly from that work. we're applying a decade of postgres engineering to a new problem.
get started
ghost is in early access. install it with the comment below. run ghost mcp install directly in claude code, and let your agents cook.
curl -fsSL https://install.ghost.build | sh
the full toolkit:
- ghost → instant, ephemeral postgres databases for agents
- memory engine → persistent, temporal agent memory
- pg_textsearch → BM25 + keyword search for postgres
- tigerfs → postgres-backed file storage
- ox → sandboxed execution, connected to your data
everything is postgres. everything is MCP-native. each one works on its own. they're better together.
Top comments (35)
Hey dev.to community - Jacky, head dev rel of ghost here!
This is a major full circle for me personally, having worked with @jonmarkgo and @theycallmeswift personally a whole TEN YEARS AGO for Dragon Hacks 2016 where Swift and Jon physically was there to support us when I directed that 650 student hackathon. Love the MLH guys, and I'm beyond stoked to be able to collab with them again!!!
Hope y'all are enjoying using Ghost. All feedback, comments, good or bad, feel free to comment below, or email me directly at jacky (at) tigerdata (dot) com
Can't wait to see what y'all are building. Tag us on socials at @ghostdotbuild
Playing around with this now 👻
Let's goooo Ben. I'd love to see what you're hacking on
Will do. This unlocks some interesting new things
Gamechanger
Thank you!!
memory is the whole game honestly. i run a bunch of agents for PM work and the ones that actually stay useful are the ones with some form of persistent context - otherwise you just keep re-explaining the same project background every session. the "think but not remember" split is a fundamental architecture problem not just a UX annoyance
i'm thinking of, and perhaps you have a suggestion, of compressing .md files and giving some away as "context as a service". Can you get some folks to try?
interesting idea. compressed context bundles could be useful for onboarding agents to a specific domain. not sure about the "as a service" framing but the underlying pattern - sharable, versioned context packs - makes sense.
Great framing of the problem. Agents without memory are fundamentally limited.
I've been running a different experiment though: a personal AI agent with zero database. Just markdown files + SQLite FTS5 for full-text search + grep as fallback. Hot memory in conversation context, cold memory in files, everything git-versioned.
After months of daily use, my takeaway: for personal/single-agent systems, files are not just good enough — they are actively better:
git blamethe memory file and see exactly what it remembered and when. Try debugging a vector similarity recall failure.git revert, not a database migration.The interesting design question is not "which database?" but "what's the minimum viable memory infrastructure for your agent architecture?" For multi-agent enterprise systems, Postgres absolutely makes sense. For a personal agent running on your laptop,
grepgets you surprisingly far.AutoGPT went through a similar evolution — they ended up removing their vector DB dependency. Sometimes the simplest tool that works is the right one.
The minimum viable memory infrastructure question is the right one to ask. Most agent tooling starts from the assumption that you need a full stack and works backwards. Your setup starts from what actually breaks and adds just enough to fix it. Curious though, does the markdown approach hold up when your agent needs to cross-reference things. Like if it needs to connect something it learned last week with something from today, is grep enough or do you end up building implicit structure into your file naming to make that work.
Good question. Cross-referencing across time is exactly where file structure becomes load-bearing — not as a schema, but as a naming convention.
After 2 months of 24/7 operation, the structure that emerged:
Temporal queries = grep across daily files by date range. Thematic queries = topic files. Cross-reference = inline
ref:slugpointers to library entries.The surprising finding: this scales better than expected. Around 150 files, still instant grep. The bottleneck is not search — it is deciding what is worth remembering. That is the same bottleneck a database has, just more honest about it.
The implicit structure does not become necessary all at once — it grows organically as the agent's knowledge grows. Each file has a clear reason to exist (temporal, thematic, or referential), so you never hit the "where did I put that?" problem. The naming convention IS the schema.
This is super cool - curious about the design decision to go with something like PostgreSQL rather than something like a local SQLite db since I associate that more with ephemeral data
A few reasons why:
SQLite is local, Postgres can be available remotely, independent of where your application is running
Postgres has a richer ecosystem for things like vector, time-series, geospatial, full text search, etc than SQLite
Ghost makes Postgres feel as lightweight as SQLite
(And we also happen to love Postgres)
Easy answer - Postgres for everything
No compromises!
This nails a problem I keep running into. You listed the five-service duct tape stack — but I think there's a layer missing even before infrastructure: perception.
Right now most agent loops look like: think → plan → act → store. The "store" part is what Ghost solves. But agents fail before they even get to storage because they never looked at their environment first.
Here's a concrete example:
The second agent doesn't need a smarter planner. It needs good eyes — and then somewhere to remember what it saw. That's where ephemeral databases like Ghost click into place perfectly: perception creates the data, Ghost gives it somewhere to live between sessions.
The git mental model you described (branch, experiment, discard) maps surprisingly well to perception too. Each perception snapshot is like a commit — a record of "what was true at this moment." Forking a database to test a hypothesis is basically the agent saying "let me see what happens if the world looks like this."
I wrote about this perception-first pattern recently — the argument is that we've over-invested in making agents think and under-invested in making them see. Your infrastructure layer is the natural complement to that.
wow
Cant wait to see what you build with it!
I think ephemeral as a word is really badass and ephemeral databases is an interesting idea. I'm not too familiar with why we would prefer one over a persistent database though? Why not build ghost to to simply be able to work on a clone of the persistent database instead? Or better still, give developers the option to choose how temporary their database is? I get the idea of sandboxing but why not have a mock database sandbox?
TLDR - we are launching "dedicated databases" soon for people who don't want ephemerality
two reasons why I personally like having an ephemeral database:
using the database as a scratch pad
for infrequent workloads, eg side projects
but yes we are launching "dedicated databases" soon, but that's not anything new
Loved this post! How does ghost handle cleanup of abandoned databases? In the multi-agent scenario especially, it seems pretty likely to end up with a bunch of orphaned forks if an agent crashes in the middle of a task or a session just never finalizes