Building a Unified Data Layer for Modern Applications

Most applications no longer have one shape of data. A single request touches structured rows, a nested document, and a window of recent events — and the usual answer is three systems, three copies, and a reconciliation step at query time. This note explains why PLOMID takes the opposite position: one data layer, one storage contract, one plan across every model it holds.

The fragmentation problem

Each new workload has historically meant a new store. The application keeps the records, a document database keeps the flexible fields, and an event pipeline keeps the history. Nothing about any one of those systems is wrong. The cost is in the seams: copies drift, schemas are translated at the boundary, and a question that spans two shapes becomes a small distributed-systems project.

The burden is not the number of systems. It is the number of copies, pipelines, sync steps, and reindexes between them. That is the line PLOMID is drawn to erase, as the architecture page describes in full.

One storage contract

The central constraint is simple: every data model persists through the same page-oriented layout and the same durability rule. Recovery is implemented once instead of re-taught to each model. That decision shapes more of the system than any surface feature.

Today that contract carries three models — SQL, JSON documents, and time series — each available in the product. Vector, graph, and object support are in development, and key-value, geo, and distribution are longer-term roadmap. The status of each is stated the same way everywhere on this site, so any claim here can be checked against the roadmap.

Each model has its own note in this publication: the SQL foundation, documents beside rows, time-ordered data, the storage layout underneath them, and the multi-model direction they point toward.

What one plan looks like

A request that reads rows alongside documents gets a single plan rather than a federation step. In the playground you can run statements like this against the sample dataset:

SELECT o.id, o.total, c.profile->>'tier' AS tier
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.placed_at > now() - INTERVAL '30 days'
ORDER BY o.total DESC
LIMIT 25;

Rows and document fields appear in the same statement, with the same transaction semantics. There is no export step, no second connection, no boundary to translate across.

Getting started takes three commands — the developers page walks through them:

# fetch the source and build
git clone https://github.com/plomid/plomid.git
cd plomid
cargo build --release

And the operational surface stays familiar. Status, for example, is plain JSON over the same layer:

{
  "layer": "plomid/0.1.0",
  "models": ["sql", "json", "time"],
  "durability": "single-storage-contract",
  "replication": "roadmap"
}

Why planning is the hard part

Federation pushes the difficult question — which half of the answer comes from where — to query time, on top of systems that only know their own half. Planning once over one data layer turns that reconciliation back into a join. The planner sees every shape at once, so predicate pushdown, layout awareness, and consistent semantics are properties of the plan rather than negotiations between systems.

Federation asks each system for its half and reconciles. A unified layer plans the whole question at once.

This is also why there are no benchmarks on this site. Numbers measured on someone else’s hardware with someone else’s data are marketing; the numbers that matter are measured against your workload. The platform page states that boundary plainly.

Available, roadmap, vision

A thesis this broad needs explicit horizons, or it reads as a promise. Three hold:

• Available. SQL rows, JSON documents, and time-ordered events through one surface, one transaction model, one recovery story. What you can run today.
• Roadmap. Vectors, graphs, and objects as access paths to the same data — in development, with status tracked on the roadmap, not announced here.
• Long-term vision. Key-value and geo access, replication as policy, regions and residency — properties the architecture must not foreclose, with no dates attached.

From Relational Data to Multi-Model Infrastructure maps each workload to its horizon in detail. The rule for all of them: a model earns its place by inheriting the layer’s guarantees, not by bolting on beside them.

What this means for builders

If you are evaluating data infrastructure, the practical consequences are three:

1. One copy of the truth. Aggregates run over the operational tables, so the numbers you report and the numbers you serve come from one place.
2. One set of guarantees. Transactions, durability, and recovery are platform properties, not per-model features to compare.
3. One surface to learn. The documentation describes a single SQL surface with document and time-ordered extensions, not three products.

None of this is finished. The deployment fabric — where the layer runs and where data is allowed to be — is still roadmap, and the data sovereignty page describes the questions it has to answer rather than promising it. That honesty is deliberate: a data layer earns trust by stating its boundaries, not by hiding them.

---

A unified data layer is not a new database category. It is the removal of categories that were never the application’s idea in the first place.