All Resources

R-48

Technology

Five Databases Are Four Too Many

Postgres for relational, Neo4j for graphs, Pinecone for vectors, Elasticsearch for text, TimescaleDB for time-series. The modern AI stack is a hidden tax on every team that ships it.

PAR2 Labs

August 29, 2026

3 min

The job of an infrastructure engineer at most companies has quietly become: keeping five databases in sync so the rest of the company can pretend they're one. We did the maths on what that costs.

The stack you didn't ask for

An AI-driven product needs to do five things with its data:

Run relational queries — joins, aggregates, range filters.

Traverse relationships — who is connected to whom, multi-hop neighbourhoods.

Search by semantic similarity — vector embeddings.

Search by keyword — BM25 over text.

Query over time — historical state, retention, point-in-time recovery.

No single database does all five. So the stack assembles itself: Postgres + Neo4j + Pinecone + Elasticsearch + TimescaleDB. Five engines, five operational surfaces, five scaling characteristics, five billing dashboards.

The hidden tax

The sync layer between these systems is almost always custom. CDC from Postgres into Neo4j. Periodic export from Postgres into Pinecone. Logstash from somewhere into Elasticsearch. Cron job into TimescaleDB.

Every one of those pipelines has the same failure mode: it works for six months, then a schema migration breaks it silently, and you discover three weeks later that your vector store is missing a quarter of your documents. The “tax” isn't infrastructure cost — it's the lost engineering time spent reconciling systems that should have been one.

The strongest argument for a multi-database stack is “best of breed for each access pattern.” The actual experience is “worst of all worlds when any of them drifts.”

The “tax” isn't infrastructure cost — it's the lost engineering time spent reconciling systems that should have been one.

What consolidation actually looks like

Tessera's bet: the access patterns aren't fundamentally different. They're different views over the same data. A hyperedge has properties (relational), endpoints (graph), text fields that can be embedded (vector), text fields that can be tokenised (BM25), and bitemporal timestamps (time-series). One write, five indexes, zero sync.

One write, five indexes, zero sync. The same records answer a relational question in SQL:

sql

SELECT * FROM transfers WHERE amount > 100000;

…a relationship question in Cypher, over the very same data:

cypher

MATCH (a)-[:SENDS]->(b) RETURN a, b

…and, without any export or copy, the same rows are reachable by semantic (vector) similarity, by BM25 keyword search, and as a bitemporal time-series. No pipeline moves anything between stores, because there are no other stores.

When five databases still make sense

We're not arguing every team should rip out their stack tomorrow. Five-database architectures make sense when:

You've already invested in deep expertise across each system.

Your scale per-dimension is so large that a unified store wouldn't fit anyway.

Your access patterns are independent — your relational team and your vector team literally never share data.

For everyone else — which is most teams — the integration cost dominates. The point of a unified hyperedge store isn't that the engine is magic; it's that the four pipelines you used to maintain simply stop existing, and with them the drift, the reconciliation, and the on-call pages they generated.

What the migration looks like in practice

Honest answer: incremental. Pick the one pipeline that's caused the most pain in the last quarter, replace it first, keep the rest. Tessera's Postgres connector exists specifically so you can start by mirroring an existing source-of-truth without committing to anything else. Once your team has confidence, retire the next pipeline.

You don't need to be brave. You need to delete one pipeline a quarter.

Key Takeaways

Relational, graph, vector, keyword and time-series needs usually assemble into five separate engines.

The real tax is the custom sync pipelines between them, which break silently when a schema changes.

In Tessera the five access patterns are views over the same hyperedges: one write, five indexes, zero sync.

Migrate incrementally — replace the most painful pipeline first, then retire one a quarter.

The product behind this

Tessera DB

A multi-model database that stores your data once and queries it five ways — relational, graph, vector, full-text and time-series — built for AI workloads and run on your own hardware.

See Tessera DB

PAR2 Labs · Technology

Work With Us