MongoDB vs PostgreSQL for a LangGraph RAG Agent: How to Choose

When you build a RAG agent with LangGraph, the choice between MongoDB and PostgreSQL can look like a coin toss. Both work. The right answer depends on what you store, what your team already runs and how you intend to grow. This guide separates the questions so the decision is easier.

What the database actually does in a RAG agent

It helps to split the storage into four jobs, because they do not all have to live in the same place.

• Application data. Users, organizations, document records, settings and chat history.
• Agent state. LangGraph can save the state of a run as a checkpoint after each step, keyed by a conversation thread. That is what lets a conversation resume, lets you inspect what the agent did, and lets a run survive a restart.
• Embeddings. The vectors used for similarity search. These can live in a dedicated vector database or, with an extension, inside PostgreSQL.
• Job state. Progress and results of background ingestion, usually held by the queue plus a status record.

The MongoDB versus PostgreSQL question is mostly about the first two. The third is a separate decision, and treating it separately keeps you from choosing a database for the wrong reason.

Checkpointing

LangGraph has a checkpointer interface, and maintained checkpointer packages exist for both PostgreSQL and MongoDB, so neither choice leaves you without persistence. Check the current package documentation for the versions you use, because this area changes quickly. What matters in practice is that checkpoints can be large and numerous, since each step of each conversation writes one. Plan retention: decide how long you keep them and how you prune old threads.

Data shape and consistency

Chat messages and document metadata are naturally document-shaped, with nested fields and variable attributes, which suits MongoDB. Users, organizations, memberships, plans and billing are relational by nature, with foreign keys you want enforced, which suits PostgreSQL. Many RAG products contain both kinds, so look at which dominates yours.

PostgreSQL gives you transactions across tables by default, so creating an organization, its owner and its first project either all happens or none of it does. MongoDB supports multi-document transactions too, but they require a replica set and are used more deliberately. If your product has real relational integrity needs, that tilts toward PostgreSQL.

Schema changes

With PostgreSQL you manage the schema through migrations, for example with Alembic and SQLAlchemy. That costs some ceremony and returns a clear history and early errors when code and schema disagree. MongoDB lets documents change shape without a migration, which is fast at the start and demands discipline later, because old documents with the old shape stay in the collection until you handle them.

Operations and people

This is usually the deciding factor. Which one does your team already run, back up and monitor? Which is easier to get as a managed service where you deploy? A database your team understands deeply will fail less often and recover faster than a theoretically better one it does not. Also consider what else the database must serve: if a reporting tool or an existing application already uses PostgreSQL, adding a second kind of database is a real cost.

Vector storage is its own decision

Keeping embeddings in PostgreSQL with an extension means one database to run and back up. Using a dedicated vector database means another service, with features built for similarity search. Either pairs with MongoDB or PostgreSQL for the rest of the data. Decide on vectors by your data volume, your query needs and your operations, not as a side effect of the application database choice.

A practical way to decide

• Choose PostgreSQL if your product has users, organizations and billing with relationships you want enforced, if your team already runs it, or if you want migrations and strong transactional guarantees.
• Choose MongoDB if your data is mostly nested documents and chat records, if your team already runs it, or if you expect the shape of your records to change often in the early months.
• If both are equally comfortable for your team, choose the one that matches the rest of your infrastructure. Switching later means moving data and rewriting the data layer.

Starting from a codebase

The agent's logic does not change with the database, only the storage layer around it. BoilerShelf sells the same LangGraph RAG agent in a MongoDB edition and a PostgreSQL edition, so you can pick by database. The RAG comparison shows how they relate to the other RAG boilerplate in the store. As with any starter, run it against your own documents before you commit.