Relational databases won the last forty years by being general: one engine, one language, one set of guarantees. What broke the monopoly was not a better table but new shapes of data — documents that refuse schemas, embeddings that answer by similarity, relationships that want traversal, objects too large for rows, events arriving by the million. Each shape got its own specialized system, and every organization now operates several.
The multi-model question is whether those shapes need separate systems or separate access paths over one system. PLOMID bets on access paths. This note maps each workload to its status — available today, in development, or roadmap — with no blurring between the three.
Why workloads pull apart
Each shape stresses a different part of an engine:
| Workload | The pressure it creates | Status in PLOMID |
|---|---|---|
| Relational rows | Transactions, joins, constraints | Available today |
| JSON documents | Flexible shape beside strict columns | Available today |
| Time series | Append-mostly writes, windowed reads | Available today |
| Vectors | Similarity as an access path | In development |
| Graphs | Traversal over first-class edges | In development |
| Blobs / objects | Large immutable values with queryable metadata | In development |
| Key-value | Single-key direct access | Roadmap |
| Geo | Distance and region predicates | Roadmap |
| Distribution | Replication, regions, residency | Roadmap |
The table is the whole article in miniature. Everything below explains what each row means — and what it does not yet mean.
Available today: rows, documents, events
The three shipped models share one SQL surface, one transaction model, and one storage contract. A single statement already crosses all three:
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'
AND (c.profile ->> 'channel') = 'api';The profile document the query reads needs no migration when a new dimension appears:
{
"tier": "pilot",
"channel": "api",
"contacts": [{ "role": "ops", "since": "2026-04-11" }]
}Rows carry the records, JSON carries the flexible dimensions, and TIMESTAMPTZ columns carry history — each covered in its own note (SQL, JSON, time series). The point that matters here: these three are not three integrations. They are one engine with three doors, and the doors open onto the same room.
In development: vectors, graphs, blobs
The three models being built share a design constraint: each must become an access path to the same data, not a sidecar store.
- Vectors mean similarity over data that already serves the application — retrieval inside existing workflows, embeddings stored beside their source rows, no export pipeline into a separate index.
- Graphs mean relationships as first-class structures — nodes and edges expressed directly instead of reconstructed with recursive joins at query time.
- Blobs mean large immutable objects addressed like data, with metadata that stays queryable — found by a query rather than by naming convention.
None of the three is usable yet. The status labels on the roadmap are the source of truth, and this article will be updated — with an updatedDate, not a rewrite of history — as each one lands.
Roadmap and long-term vision
Beyond the models in development sit the properties of a distributed layer: key-value access, geo predicates, replication as policy, region and residency boundaries, multi-storage topologies. These are explicitly roadmap and long-term vision — directions the architecture must not foreclose, not features with dates.
The storage engine is where that future is either enabled or blocked: fixed-size pages, a WAL-first commit path, and snapshot reads are the properties a distributed layer will one day inherit. The unified data layer thesis is the argument for why one layer is worth building toward at all.
Multi-model is not a count of supported syntaxes. It is the discipline of giving every workload the same guarantees — one copy of the truth, one transaction model, one recovery story — and stating plainly which workloads have them today.
