What Database Should You Use for an Agentic AI Application?

Ask "what database should I use for an agentic AI application?" and most answers hand you a product name. That is the wrong shape of answer, because an agentic application does not hold one kind of data. It holds five, they arrive on the same day, and each one wants a different home. Pick by pile, not by product, and the decision mostly makes itself.

The short answer. Your application's own state goes in Postgres. Hot session context goes in Redis — later than you think. Semantic recall starts as pgvector inside that same Postgres and graduates to a dedicated vector store only when you can measure why. Logs and token accounting go in an analytics store, separate from day one. And the business facts your agent produces — the pile almost every selection guide forgets to list — belong in a record layer that can show who wrote each fact, and whether a human ever accepted it.

One concrete application

Abstract advice is cheap, so take a specific app: an agent that triages support tickets. It reads each incoming ticket, classifies it, searches past resolutions, drafts a reply for a human to approve, and updates the customer record with what was decided. Ordinary, buildable, and already enough to generate all five piles:

Application state — users, tickets, customers, permissions. Small, transactional, must be exact.
Session and hot context — what the agent is mid-way through: the current conversation, tool results, rate-limit counters. Ephemeral, high churn, latency-sensitive.
Semantic recall — ten thousand resolved tickets and the help center, embedded so the agent can find "ones like this".
Telemetry — every prompt, response, tool call and token count, kept for debugging and cost accounting. Append-only, grows forever.
Produced facts — the classification on each ticket, the drafted resolution, the updated customer record. Other people and later agent runs will read these as truth.

The first four piles have well-worn answers. The fifth is where agentic applications quietly go wrong — hold that thought.

Where each pile goes

Pile	Home	Why
Application state	Postgres	Transactions, constraints and joins. This is the solved problem; do not innovate here.
Session & hot context	Postgres first, Redis when latency proves it	Most agent apps are not fast enough for session reads to be the bottleneck. Add Redis for per-request counters and dedupe windows, not by default.
Semantic recall	pgvector in the same Postgres	One system to operate, embeddings next to the rows they describe. A dedicated vector store earns its place at tens of millions of vectors or measured latency targets — not before.
Telemetry	An analytics store (ClickHouse, DuckDB-class tools), or a separate Postgres	Append-heavy and unbounded. Next to your state tables it becomes vacuum-and-partition pain within months. Cheap to separate early, expensive to retrofit.
Produced facts	A record layer	These are read as truth by people and by later runs. They need provenance (which agent, from what input) and a review state (proposed vs accepted) that a general-purpose engine does not model.

Engine thresholds, benchmarks and the deeper Postgres-first argument live in our reference page, which database your AI agent should use. This post is about the decision, not the tuning.

The decision sequence

Ask these in order; each answer narrows the next.

What does my application itself store? Users, orders, tickets, content. That is Postgres, full stop — managed or self-hosted is a budget question, not an architecture one.
What does the agent need to recall? Documents and past cases, by similarity. Start with pgvector. Write down the number of vectors and the latency you actually measure; that note is your future trigger for a dedicated store, and not before.
What is hot and disposable? In-flight sessions, counters, locks. If losing it costs nothing, it can live in Redis — or in Postgres until you can prove it is slow.
Where do the logs go? Somewhere else. Decide this on day one, while it is still a config line.
What will the agent write that others will believe? This is the question that decides whether your stack needs a record layer, and most teams only ask it after the first incident.

Three ways teams get this wrong

Starting with the vector database. It demos beautifully — embed everything, ask anything. Six months later the team has a recall system with nothing reliable to recall from: the facts are still scattered across tickets, docs and chat. Recall is pile three. It is rarely the first problem.

Treating chat transcripts as memory. The agent's history piles up in conversation logs, and the next run re-reads raw transcripts hoping to reconstruct what was decided. Transcripts are telemetry (pile four). Decisions belong in records, in the shape the next run — and the next person — can actually use.

Letting the agent write straight into the production database. The writes are well-formed, authorized, and some of them are wrong — plausibly, confidently wrong. The database cannot tell you which rows a human has seen. When a customer acts on one of those rows, you discover that "the agent wrote it" and "we stand behind it" were never the same statement in your system. This is the failure the fifth pile exists to prevent.

Where the record layer sits

Notice that the fifth pile is not a bigger database or a smarter one. It is a different job: keeping business facts in typed records, with the docs that explain them and the rules the agent follows in the same workspace, and letting writes arrive as proposals — a change request with a diff that a person can accept or reject — whenever the stakes warrant it, while routine writes land directly. That is the layer Busabase occupies: it runs on Postgres itself (PGlite locally, standard Postgres in Cloud), and agents reach it over MCP, an agent skill, the API or the CLI. It does not replace piles one to four. It is the home for the one pile they were never designed to hold.

So: Postgres for state, pgvector until measurement says otherwise, Redis when latency is proven rather than feared, telemetry in its own store from the start — and a record layer for the facts your agent produces, because those are the ones your business will be judged on.

FAQ

Do I need a vector database to build an agentic application? You need vector search for recall; you rarely need a separate vector database at the start. pgvector inside your existing Postgres covers most applications well past launch. Graduate when measured scale or latency says so, not when a launch post says so.

Can one Postgres instance do everything? Piles one, two and three, comfortably, for a long time. Pile four will eventually make it hurt. Pile five is not a matter of capacity at all — it is a missing concept (provenance and review state), and no amount of tuning adds a concept.

What changes when a second agent arrives? Every shared pile gets a second writer. State and recall survive that fine. Produced facts are where it bites: two agents writing the same customer record, neither able to see what the other proposed or what a human already accepted. Multi-agent systems do not fail on the engine. They fail on unreviewed, unprovenanced facts — which is why the fifth question in the sequence matters more with every agent you add.