A database for your AI: what an agent actually needs from storage

TL;DR. "A database for AI" means three different things: a database your AI builds an app on, a database your agent can query over MCP, and memory for the agent itself. The first two are ordinary Postgres needs (a schema, migrations, rows scoped to the signed-in user, a way to get your data back out, and a way for the agent to run SQL). The third is usually a vector store and a different question. Chat assistants such as ChatGPT and Claude have no database for your app; IDE agents use whatever you give them; builders bundle or bolt on a backend. Hatchable gives every project a private Postgres that the connected AI can migrate and query over MCP, with sign-in included.

The three things people mean by "database for AI"

Searches for "chatgpt database", "claude database", "cursor database" and "bolt database" all look alike and want different things. Sorting them out first saves a wrong purchase.

1. A database your AI builds an app on

This is most people. You asked an AI to make you a tracker, a CRM, a booking page, and it produced a page that forgets everything on refresh. What you want is an AI app with a database: tables the AI designs, code that reads and writes them, and a place all of it runs. The AI is the builder; the database is part of the app it builds.

2. A database your agent can query over MCP

Here the data already exists and you want the agent to answer questions against it, or to maintain it. The Model Context Protocol (what MCP is) is how an agent gets a "run this query" tool. Postgres MCP servers do exactly this, and there are several to choose from (compared here).

3. Memory for the agent

The agent should remember what you told it last week. That is not a relational database problem; it is a retrieval problem, usually solved with embeddings and a vector index, sometimes with plain text files. It gets its own section below because mixing it up with the first two is where people buy the wrong thing.

What an AI app with a database actually needs

For the first two meanings the requirements are the boring, well-understood ones, and the AI needs them more than a human does because it cannot improvise around a missing piece:

• A schema it can write and read. Real tables with types and indexes, not a key-value blob. Agents are good at SQL because there is twenty years of it to learn from.
• Migrations. Schema changes as files that apply once and stay in the project. Without them the second change breaks the first, and the agent has no record of what it did.
• Rows scoped to the signed-in user. The moment two people use the app, "each person sees their own entries" has to be enforced in the database, not remembered in every query the agent writes.
• Backups, or at minimum an export you control. Ask any platform how your data comes back out before you put anything in. Table exports and SQL dumps are the honest answer.
• A way for the agent to run SQL. Schema inspection and ad hoc queries over MCP, so "what sold on Friday?" is a question, not a dashboard trip. This is also how the agent debugs its own app.
• Isolation and transactions. One private database per app, and multi-step writes that commit together or not at all.

Notice what is not on the list: a connection string you paste into three places, an ORM dialect, a separate account with a separate bill. Those are costs, not needs.

Why vector stores are a different question

A vector store holds embeddings (numeric representations of text or images) and finds the nearest ones. That is what agent memory and "search by meaning" need, and it is genuinely useful. But it is not a system of record. It cannot enforce that an invoice has a customer, it does not do "sum of orders by month", and it should not be the only copy of anything. Most real AI apps need both: Postgres for the facts, a vector index for the fuzzy retrieval, ideally living next to each other so the agent does not juggle two services. If your question is "which database for AI agents", the answer is usually "Postgres, plus vectors alongside it", not "a vector database instead".

How ChatGPT, Claude, Cursor and Bolt handle it, as of August 2026

Broad strokes, hedged, because every product here changes quickly:

• Chat assistants (ChatGPT, Claude, Gemini). They have no database for your app. A chat can write SQL and can render a small app inline, but there is nothing running when the tab closes. They can, however, connect to a database-bearing platform over MCP, and then the database lives there.
• IDE and terminal agents (Cursor, Claude Code, Codex). They use whatever you give them: a local SQLite file, a Postgres you provisioned, a hosted database you connected. They are excellent at the code and entirely dependent on you for the infrastructure, unless an MCP server supplies it.
• Prompt-to-app builders (Lovable, Bolt, Replit, v0, as examples). They typically either bundle a managed backend (Lovable Cloud is built on Supabase, per Lovable's docs) or offer a one-click integration with one (Bolt has historically paired with Supabase). This works well on day one. The trade-offs tend to be a usage meter on the backend, and a schema that lives in someone else's dashboard.

General characterisations based on public information as of August 2026; check each vendor for current details.

How Hatchable handles it

Hatchable is the platform where AI-built apps go live, and it treats the database as part of the app rather than an add-on. You connect the AI you already use to https://hatchable.com/mcp (OAuth, no API key), and from then on:

• Every project gets its own private Postgres the moment it is created, on every plan including free. Standard PostgreSQL, real SQL, real indexes. Nothing is shared between projects.
• The agent writes migrations as SQL files in the project, applied in order at deploy, each exactly once. Your schema history is the file list.
• The agent runs SQL over MCP. The same connection that built the app can inspect the schema and query the data, before and after launch.
• Sign-in is included (email-code login and passkeys, Google sign-in available), and a table can be marked private-per-person so the database enforces who sees which rows.
• Semantic search lives alongside the tables. Embeddings and vector storage are part of the project, so "Postgres plus vectors" is the default rather than a second service.
• The data is yours. Export any table, and take the project as a zip and SQL download or push it to GitHub with history.

The full spec is on the database feature page, and the step-by-step version is how to give your agent a database. The short version:

1. Connect your AI

   Claude, Claude Code, Cursor, Codex, ChatGPT, Gemini or Antigravity; each takes about a minute from its connect page (Cursor, for example, is one setting). Approving the sign-in creates your free account.

2. Describe the app, including the data

   "Build a client tracker where each client has invoices, and only I can see it." The AI creates the project, writes the tables and migrations, the pages and the API routes, and deploys.

3. Ask questions of the data

   "Who owes the most?" comes back as rows in the chat, over the same MCP connection. Schema changes are one more ask.

No credits, no per-prompt fees: your own AI subscription writes the code. The free plan includes unlimited private projects and one published app, no card; Builder is $12 a month for unlimited published apps.