Just Postgres: Drop the Graph Database. Keep the Graph.

When we started building cognee, one thing became obvious quickly: people wanted graph memory, but they didn't want to operate a graph database.

They wanted agents that could understand relationships, trace context, and retrieve connected facts. What they got instead was a stack: a graph database for relationships, a vector database for embeddings, Redis for sessions, and a relational database for metadata.

All of that had to be deployed, secured, monitored, backed up, upgraded, and paid for before an agent ever remembered anything useful.

That felt backwards to us.

I held onto the belief that memory should make agents easier to run, not turn the first deployment into a distributed-systems project.

So in cognee 1.0, we simplified the production stack. cognee can now run the full memory layer on a single Postgres instance: graph, vectors, sessions, metadata, and the relationships that make memory useful.

The hidden cost of graph memory

The difficult thing with the old setup wasn't so much the databases themselves.

Knowledge graphs are a great fit for agentic memory. Mapping out the relationships of elements within a dataset can greatly help enhance their representation. Facts aren't in a vacuum, they point to people, documents, decisions, projects, timestamps, permissions, and other facts. If an agent needs to understand why something matters, it needs more than nearest-neighbor similarity. It needs the structure graphs provide.

The tricky part was the infrastructure around that structure. A dedicated graph database brings its own operational world: deployment, access control, security review, backups, scaling, monitoring, incident handling, and usually a new query language or hosting model. For larger deployments, that can become a six- or seven-figure annual line item once licensing, hosting, security, and operations are included.

Postgres is different. It's open source, familiar, and already trusted in production across most companies. People know how to run it, secure it, back it up, and recover it when something goes wrong.

That became the question behind this part of cognee 1.0: what if this database — that we know people already trust — could hold the whole memory layer?

Can the whole memory layer be in Postgres?

It can.

cognee now runs the core pieces of agent memory on Postgres: the knowledge graph, vector embeddings, sessions, usage data, and dataset metadata.

• The knowledge graph runs through cognee's Postgres graph backend — entity extraction, relationship modeling, and graph traversal without requiring Neo4j or another dedicated graph database.
• Embeddings live in pgvector, next to the memory they describe.
• Sessions, conversation traces, and usage logs run through the new SQL session-cache backend, which replaces the Redis requirement while keeping sliding-TTL expiry, safe concurrent cleanup, and parity with the Redis path.
• Dataset metadata stays in the same relational layer.

Instead of wiring together separate storage systems, you run the memory layer through the database most companies are already familiar with. Point-in-time recovery now covers the whole memory layer, not only the relational slice of it.

Here's a comparison between the multi-system stack from before and the more consolidated setup shipped with cognee 1.0.

Graph structure, without the graph database

The graph still exists. We just changed where it resides.

cognee extracts entities, relationships, and embeddings. In the Postgres setup, those pieces stay together: records and metadata in the relational layer, connected structure through cognee's Postgres graph backend, and embeddings through pgvector.

For example, a data point might contain a customer note saying that a company delayed rollout because their security review is still open. cognee can store the note and its metadata as a normal Postgres record, embed the text for semantic retrieval with pgvector, and preserve the connected structure around it: Company → has_blocker → security review, security review → affects → rollout, and rollout → belongs_to → customer onboarding. The graph still exists, but it now lives inside the same Postgres-backed memory layer as the text, metadata, and embeddings.

This way, the ingestion and retrieval flow can move between similarity and structure without sending the query across separate services. If an agent asks why the company's onboarding is delayed, cognee can first find semantically relevant notes, then follow the connected entities around them — blocker, rollout, owner, customer, latest update — and bring back the surrounding context from the same database.

Developers already running Postgres will feel right at home here. cognee's schemas and tables can be added to an existing deployment, or you can run a dedicated instance for memory. Either way, graph memory no longer requires a separate graph service before the first production deployment.

Fewer hops, faster retrieval

The nice surprise was that this consolidation didn't slow things down. Actually, the opposite happened.

In our internal CI benchmarks, Postgres search was about 10% faster than the separate graph-plus-vector setup, largely because retrieval stayed inside one database instead of crossing service boundaries. We use War and Peace as a repeatable baseline workload in CI, running the same flow with live LLM calls and/or mocked LLM calls depending on what we want to measure.

That tracks when you look at the shape of the old stack. A memory query often moves between semantic search, graph structure, session state, and metadata. When those layers live in separate systems, part of every query goes toward stitching results back together across service boundaries. Postgres removes that coordination overhead.

cognee serves over 6 million memories a month across 100+ companies, and this consolidated stack is part of how we make that kind of scaling possible.

Start simple, swap when needed

Postgres is the default we'd recommend for most cognee deployments, and it's the path we optimize for — but it doesn't replace the other backends.

The change is where you start. You can begin with Postgres, keep the full graph-memory model, and move to a dedicated backend only when the workload proves it needs one.

A dedicated vector database can push approximate-nearest-neighbor throughput further. A dedicated graph engine can handle extreme traversal workloads that a general-purpose database won't always match. If you eventually need that headroom, cognee still supports those backends — Neo4j and Neptune for graphs, Redis for sessions, pgvector and LanceDB for vectors, with Qdrant, ChromaDB, Weaviate, and Milvus available through community adapters.

If you've already standardized on a dedicated store, you can keep using it.

Local development stays fully embedded: SQLite for relational data, LanceDB for vectors, and Kuzudb for local graph memory. Install cognee and start building without standing up any extra services. When you're ready for production, change the configuration and run the same memory layer on Postgres.

Run it on Postgres

pip install "cognee[postgres]"

DB_PROVIDER=postgres
VECTOR_DB_PROVIDER=pgvector
GRAPH_DATABASE_PROVIDER=postgres
CACHE_BACKEND=postgres

DB_HOST=localhost
DB_PORT=5432
DB_USERNAME=cognee
DB_PASSWORD=cognee
DB_NAME=cognee_db