PLOMID holds structured rows, documents and time-ordered events in one system, and gives you one planning and execution path across all of them. Vector, graph and blobs extend that same layer, and are on the roadmap.
Each system is good at its own shape of data. The cost shows up in the seams: the code that keeps them consistent, and the questions that cannot be answered by either one alone.
One system holds the row, another holds the document describing it, a third holds its history. Keeping them in step becomes the work.
Movement between systems is written by hand, then maintained forever. The pipeline becomes part of the product.
When the same question is asked of two systems, small differences in timing and shape show up as real ones.
Pick a model to see the shape of the data it holds. Each one is a way of shaping the same underlying data, the dashed ones extend the layer rather than replacing it.
Solid, in the product Dashed, still being built
Hover the diagram or the text, each answers the other. Click to pin.
Relational workloads, tables, joins, transactions.
Structured data with a familiar query surface. Tables, indexes, relationships and transactions on one engine.
Hover the diagram or the text, each answers the other. Click to pin.
Documents and nested objects, queried alongside rows.
Flexible documents live next to structured data, so one query can mix fields from both without a second system.
Direction, not a capability, hover to explore the shape it will take.
Short-lived state, addressed by key.
One key resolves to one value without a scan, sessions, flags and cached state read as directly as they are written.
Hover the diagram or the text, each answers the other. Click to pin.
Events, measurements and history over time.
Time-ordered data is stored with the rest of the application data, so history and current state agree.
Direction, not a capability, hover to explore the shape it will take.
Where it is, asked like any other predicate.
Position, distance and range become part of the same query surface, nearby objects answered without exporting coordinates to a second system.
Direction, not a capability, hover to explore the shape it will take.
Similarity and semantic retrieval.
Embeddings and nearest-neighbour retrieval as another access path to the same underlying data.
Direction, not a capability, hover to explore the shape it will take.
Nodes, edges and traversal.
Relationships expressed as first-class structures instead of reconstructed at query time.
Direction, not a capability, hover to explore the shape it will take.
Large objects and file-like assets.
Big immutable objects addressed like data, with metadata that stays queryable.
Direction, not a capability, hover to explore the shape it will take.
Mix models in a single statement.
Rows, distance, a time window, a traversal and an object can be named by one request, with the plan working across the layer that holds them. Mixing models in one statement is on the way, the pieces it needs are already in the layer.
PLOMID is described by what you are doing with the data, not by which sector you are in. Three examples, each with the model that carries it.
Records, keys and joins with nested documents beside them, one request that reads both.
Events and measurements written as they happen, read back as windows beside current state.
Similarity as another access path to the same data. Vector is on the roadmap, so this is a direction rather than something to build on today.
Direction, the same layer, one more access pathFour stages, the same for every data model. The shapes differ; the path does not.
A query or write arrives over one of the supported surfaces, SQL, document access, or time-ordered inserts.
Requests enter at the interfaces, are planned once against the data layer, run through shared execution and land on storage. Select a layer to see how it connects.
clients · query · parser · planner · execution · mvcc · index · storage · data
SELECT region, sum(total)
FROM orders
WHERE placed_at > now() - interval '24 hours'
GROUP BY regionRequests enter once, are planned once, and land on one storage contract.
AI clients, applications, services and jobs reach the layer through one set of interfaces, a query surface, a driver or an SDK, rather than one client per store.
A request arrives as SQL, a document access, or a time-ordered range, one entry point for every data model.
The request becomes one tree, so a document field and a table column are described the same way.
One plan is chosen against the data layer as a whole, not one plan per remote system.
Vectorized operators run the plan with bounded memory, reading the stored layout.
Readers and writers do not block each other: each statement works against a stable snapshot.
Access paths narrow the work before a row is touched, point lookups, predicates and ordered ranges.
Values land in pages, pages group into blocks, and every data model shares one durability contract.
Rows, documents and events, the data the whole stack exists to keep consistent.