Nobody designed the six-database platform. It accreted. The relational store was there first. Documents arrived with the web, so a document store. Search needed an inverted index, so a search engine. Graph questions got slow, so a graph database. Embeddings arrived with machine learning, so a vector index. Blobs never fit anywhere, so an object store. Each choice was locally correct, and the sum is a platform in which the same fact lives in four places, is protected four ways, and is governed by whichever access model happens to be weakest today.
The consolidation pitch has been made before, badly, by vendors who bolted a JSON column onto a row store and called it multi-model. Sceptics are right to have heard it all. This article is for those sceptics: data architects and platform leads who know what the seams cost and who will not accept a consolidation claim without acceptance criteria. It states the cost, says what a single substrate has to prove, and reports what 8DB has demonstrated against those criteria.
The seams are the cost
The licence bill is not the problem. The problem is what lives in the gaps between engines.
- Governance seams. Six engines mean six access models, and the effective policy over a fact that appears in several is the weakest of them. Every audit finding about a leaked record eventually traces to a seam.
- Provenance seams. A pipeline that copies a record from one store to another discards its origin at the boundary. Ask where a fact came from and the answer is "the ETL job", which is not an answer.
- Protection seams. Each engine encrypts its own way, with its own keys, its own rotation and its own exposure. A post-quantum migration is six migrations.
- Semantic seams. The relationship between a document, the entities it names, the vectors that represent it and the graph edges it implies is real, and it is lost the moment the four representations live in four systems joined by identifiers that drift.
- Operational seams. Six upgrade cycles, six backup regimes, six restore procedures, six on-call rotations.
The operational costs are visible and get budgeted. The governance and provenance costs are invisible until the incident, and then they are the incident.
What "one substrate" has to mean
A single engine is only an improvement if the shapes it holds are first-class rather than emulated, and if the protection, governance and provenance really are one path rather than six behind a facade. A serious claim has to be specific about which shapes are supported, what "supported" means, and what remains outside.
In 8DB the substrate is a content-addressed atom store with an index over it, and the shapes are projections of that store rather than separate engines: key-value and batch records, blobs, labelled records, vectors with nearest-neighbour behaviour, spatial operations and dynamic time warping, directed edges and n-ary hyperedges. Because they are projections of one store, a fact is written once, sealed once, governed once and attributed once, and the relationships between its representations are structure rather than foreign keys in a pipeline. We have written about the idea in Data Modality Is a Projection, Not a Product Boundary; this article is about what it has to prove.
The acceptance criteria we hold ourselves to
A consolidation claim should be tested the way a sceptic would test it. These are the criteria in our independent evaluation package, and they are the ones we would hand any competitor.
- Byte-correct results across shapes in one tested store and write path. Not "a JSON column"; the same store persists key-value, blob, labelled, vector, spatial, time-warped, graph and hypergraph data and returns each correctly.
- One sealing path. Persisted content is sealed at write, and raw storage is scanned for known plaintext markers, for every shape, not only the tables.
- One governance model. Labels and clearances enforced through key derivation, identically for every shape, and testable offline.
- One provenance and integrity model. Content addressing and per-record inclusion proofs under a single signed root, regardless of shape.
- Explicit non-claims. Which modalities are not yet formal claims, stated in the package rather than left for the buyer to discover.1
Criteria 1 to 4 are formal claims in that package, accepted only when named harnesses pass against frozen baselines on an evaluator's isolated host. Criterion 5 is the one most vendors skip.2
Where consolidation earns its keep first
Not everywhere at once. The datasets worth moving first are the ones where the seams hurt most: long-retention records under regulatory hold, where six protection regimes mean six migrations; fused intelligence and analytics, where provenance across representations is the product; agent memory and retrieval stores, where governance across shapes is a security boundary; and anything that must be sealed, governed and attributable on a disconnected node with no room for six engines.
What to bring us
- Your seam map. The systems a single important fact passes through, and the access model at each. We will show which seams a single substrate removes and which remain.
- One failing join. A question your platform cannot answer because its answer spans engines. That becomes the demonstration.
- Your sceptic. The evaluator bundle exists so your most doubtful architect can run the criteria above on an isolated host before anyone from 8Braid is in the room.
Write to hello@8braid.com with the subject "One substrate: seam review". You will hear back from an engineer.
Sources and further reading
- Stonebraker and Cetintemel, "One Size Fits All": An Idea Whose Time Has Come and Gone
- 8DB: Data Modality Is a Projection, Not a Product Boundary
- 8DB: One Store for Many Shapes, Disconnected
- 8DB: What an Independent Evaluator Should Be Able to Run
Footnotes
-
Vector, point-cloud, time-series and hypergraph support exists in 8DB and is not claimed to carry uniform protected treatment until evaluator-visible tests exist for it. ↩
-
Two things we will not claim yet: performance and cost. A single substrate can be slower than a specialised engine at the specialised engine's own task, and a claim that it is not requires a head-to-head on the buyer's workload with the method published first. Total cost of ownership requires a real estate and a real year. We will publish both when we can do so with harness and scope attached, and not before. The argument in this article does not depend on either; it depends on the seams, which are free to count. ↩
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work