Five layers, one storage contract.
Interfaces, planner, execution and storage are available today. The deployment fabric, where all of it runs, is the layer still being worked out.
What sits under the query.
One request, the whole way down. Follow a stage to see what it is responsible for, what it receives and what it hands on, the signal holds still while you look.
One request, top to bottom
A statement enters at the top, is planned once against the layer, and lands on stored data. The side paths show where one plan reaches several shapes.
- in
- a question about the data
- out
- the answer
One plan, several data shapes.
The planner is where a unified data layer either works or does not: one request reading a table, a nested document field and a time window, without three separate round trips.
The planner resolves the request against the data layer as a whole, which columns exist, which documents carry the field being filtered on, which time range is being asked for, then chooses how to read the stored layout, not how to talk to four services.
Federation pushes that work to query time, on top of systems that each only know half the answer. Planning once over one data layer is the difference between a join and a reconciliation.
- Predicate awareness across data models
- Layout-aware reads instead of row-at-a-time access
- Consistent semantics for the same expression in every model
Select an operation on the right: each answers what it is responsible for, the part of the statement it reads, and where that work lands in the architecture.
plan mixed_orders_by_region
The request resolves to one plan over the data layer as a whole — not one query per system, reconciled later.
reads SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY region
limit 50
The request names a cap, so the plan stops at fifty rows instead of reading everything the scan could produce.
reads SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY region
aggregate group by region = orders.region
Rows reduce to one value per region inside the layer, before anything is returned.
reads SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY region
scan orders (sql) columns: region, total, placed_at
The structured part of the request is answered from stored pages, with the predicate pushed into the scan.
reads SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY region
read payload (json) field: payload.sku
A nested document field is resolved the same way as a table column, so one request describes both.
reads SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY region
range events (time) window: last 24 hours
The window becomes a read over ordered data, so only the pages inside it are touched.
reads SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY region
The shape of a plan, not output from a benchmark run. Select an operation to see what it is responsible for and the part of the statement it reads.
A statement, the whole way down.
Eight stages, one path, the same for every data model. Select a stage to see what it is responsible for. The last one is the only stage that is not built.
SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY regionA statement arrives over one of the supported surfaces, SQL, a document field access, or a time-ordered range.
One entry point is what makes one set of types and one set of semantics possible; everything the rest of the path relies on starts here.
- One entry point for every data model
- Types and parameters resolved up front
- Nothing forwarded to a second system
SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY regionThe request becomes one tree, whatever shapes it touches, so a document field and a table column are described the same way.
A request cannot be planned until it is understood, and one tree is what lets a column and a nested field sit in the same predicate.
- One syntax tree for the whole request
- Document paths resolved as expressions
- Time windows as first-class predicates
SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY regionThe plan is chosen against the data layer as a whole: which columns exist, which documents carry the field, which ordered range can answer the window.
This is where a unified layer differs from federation: the decisions are made once, up front, instead of being reconciled at query time.
- One plan, not one per remote system
- Layout-aware read choices
- Consistent semantics per expression
SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY regionOperators run over the plan with bounded memory, reading the stored layout rather than a row at a time.
The plan is only a description until operators run it; bounded memory is what keeps one heavy request from starving the others.
- Vectorized operators
- Parallel and incremental work
- Bounded memory per query
SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY regionReaders and writers do not block each other. A statement sees a stable snapshot of the data while writes continue underneath it.
Concurrent work would otherwise serialize: snapshots are what let a long read and a steady write stream share the layer without waiting on each other.
- Snapshot reads give consistent answers
- Concurrent writers do not block readers
- One transaction boundary across models
SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY regionAccess paths narrow the work before any row is touched: point lookups, secondary predicates and ranges over ordered data.
Touching every page to answer a predicate would scale with the data instead of with the answer; access paths are how the work narrows.
- Point and range access
- Predicates pushed into the scan
- Ordered reads for time-ordered data
SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY regionValues land in pages, pages group into blocks, and every data model persists through the same durability and recovery path.
Nothing counts as an answer until it survives; one durability contract is what makes recovery a property of the platform, not of each model.
- Page-oriented layout for mixed shapes
- One durability contract across models
- Recovery as a platform property
SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY regionWhere the same stack runs across more than one node or region. This is the part of the design still open, and it is not available to use.
Everything before this stage runs on one node today; where the same stack runs next, and what a region means, is the open part of the design.
- Region boundaries as declared policy
- Replication as a designed property
- Not available yet, roadmap
From live data
to durable storage.
Writes land in layouts designed to be read back predictably: rows and documents become pages, pages group into blocks, and every data model moves through the same storage contract.
- Page-oriented layout for mixed shapes
- One durability contract across models
- Recovery treated as a platform property
A row, a document field, a time-ordered event, every shape enters storage through the same door.
Values pack into fixed pages, the unit every model is read and written in, so mixed shapes share one layout.
Pages group into blocks so a range of related values is read together, instead of one page at a time.
One durability contract underneath: the same recovery path for every data model, treated as a platform property.
What sits under the query: rows, pages and blocks.
A query narrows before it reads: predicates remove work, an index picks the path, pages are touched, and only then is a row reconstructed. The further left, the less is read.
query SELECT region, sum(total) FROM orders WHERE placed_at > now() - interval '24 hours' GROUP BY region
The whole path Predicates remove work, an access path narrows it, pages are touched, and a row is reconstructed only at the end.
- Page
- The unit pages and blocks are read in, shared by every data model.
- Block
- Pages grouped so that a range of related values is read together.
- Row
- Reconstructed from its page only when it is actually needed.
What each layer is responsible for.
The same nine layers, in words. Each has one job, when a layer starts doing two, the boundary is in the wrong place.
Interfaces
What enters.
above Planner & coordination
The surfaces applications, AI clients and developers talk to.
- SQL queries and drivers
- Document and JSON access
- Time-ordered reads and writes
Planner & coordination
What gets decided.
sits below Interfaces · above Execution
Turns a request into a plan over one data layer.
- One plan across data models
- Predicate and layout awareness
- Consistent semantics
Execution
What runs.
sits below Planner & coordination · above Storage
Runs the plan close to where the data lives.
- Vectorized operators
- Parallel and incremental work
- Bounded memory per query
Storage
How data persists.
sits below Execution · above Deployment fabric
Rows, documents and events persisted through one storage contract.
- Page-oriented layout
- Shared durability guarantees
- Recovery as a platform property
Deployment fabric
Where it runs.
sits below Storage
Roadmap, not available yetWhere the system runs, and where data is allowed to be.
- Self-hosted and cloud topologies
- Region and residency boundaries
- Replication as policy, not accident
Readers and writers do not wait for each other.
Multi-version concurrency control is what lets a long read and a steady write stream share one data layer. Each statement works against a snapshot, so its answer is internally consistent, and writers are never held up by the readers around them.
The same rule applies whether the statement touches a table, a document field or a time window, because all three run through one execution and storage path.
- Snapshot reads
A statement reads a consistent view of the data as of the moment it started, so it never sees a half-finished write.
- No reader/writer blocking
Writers do not wait for readers and readers do not wait for writers, which is what keeps concurrent workloads predictable.
- One boundary
The same transaction semantics apply to rows, documents and time-ordered data, because they share one execution and storage path.
What is settled, and what is still moving.
Some parts of the design we would defend in a review. Others are openly in motion. Saying which is which is more useful than pretending everything is finished.
Settled
- One storage contract
- Every data model is persisted through the same page-oriented layout, durability rules and recovery path.
- One plan per request
- The planner reads the data layer directly instead of coordinating a list of independent remote systems.
- One recovery story
- Recovery is a property of the platform, so it does not have to be re-taught per storage system.
- One primary surface
- SQL for structured data, with document field access and time windows available inside the same query.
Still moving
- Deployment fabric
- Where the system runs, and what a region means for reads, writes and residency.
- Distribution
- Replication and region boundaries as declared policy rather than an accident of setup.
- Vector, graph and blobs
- Additional access paths over the data that already lives in the layer.
- Multi-storage
- One system spanning more than one class of backing storage.
Building around data infrastructure?
Talk with the PLOMID team about integration, architecture or technical collaboration, whether you are connecting a system to the layer, running it, or designing on top of it.