8DB gives application builders native operations for richer questions and decisions. A fleet investigation can combine ownership, location and temperature history in one answer. A decision feature can retain useful alternatives when cost, benefit and confidence conflict. Teams can compose and reuse those operations as their product grows.
For teams building operational intelligence or domain-specific AI, that can mean less query plumbing and fewer domain algorithms to recreate. The useful test is how much of your feature the database already implements, and how much work your team still owns.
SurrealDB and ArangoDB already combine multiple models. The useful comparison is how much of your complete job each database can perform, how well it performs it, and what your team still has to build around it.
The question crosses the models
Consider a fleet operator investigating overheating:
Which vessels owned through a company's subsidiaries spent consecutive hours above a temperature threshold inside a review area?
The ownership graph finds the vessels. Time-series operations inspect their readings. Location determines which observations qualify. Sequence matters: an isolated spike and sustained overheating are different events. A missing observation matters too.
8DB and SurrealDB both answered this question in our published shipping-query comparison. The 8DB implementation used native typed operations composed in Rust; the comparator used tuned SurrealQL. The complete answer, including qualifying timestamps, was checked on both sides.
The 8DB route read temperature first and fetched coordinates only for vessels that could still qualify. It kept track of consecutive observations directly. This is where a representation earns its place: it lets the implementation do less unnecessary work while preserving the answer.
That experiment used prepared, resident data with a local HTTP request and decoded response. It measured neither authenticated operation nor durable completion. Its results support that workload, while the article records the tuning, hardware and limits needed to interpret them.
Change the question.
Keep the connection.
The useful difference is the operation you can perform, not just the shape you can store.
Choose a perspective to explore its question and operators.
- Identity
- asset/A17
- Type
- Field pump
- Part of
- Cooling loop
- Location
- Inspection area
Which asset are we talking about?
- Key lookup
- Property filter
Retrieve asset A17 and its typed properties. This identity is the reference point for the other questions.
Start with an identifiable object that other records and operations can refer to.
Related identities and typed values give the questions a common meaning. Different queries can still need different indexes, physical layouts and maintenance.
Read all five perspectives
- Record: Which asset are we talking about?
Key lookup · Property filter. Retrieve asset A17 and its typed properties. This identity is the reference point for the other questions.
- Relationships: What is this asset connected to?
Typed-edge traversal. Follow A17's part-of relationship to the cooling loop, then the loop's supplies relationship to the workshop.
- Location: Is it inside the inspection area?
Point-in-region query. Compare A17's location with a region. The example point falls inside the outlined inspection area.
- Sensor history: What do the readings tell us, and what is missing?
Time-window scan · Interval hull. The supplied readings span 68–78 °C. One observation is absent; the interval hull does not fill that gap or certify the sensor.
- Decision structure: Which options remain worth considering?
Partial-order comparison · Non-dominated frontier. Plan A costs less; Plan B has less downtime. Both remain on the frontier. Plan C is worse on both criteria in this example.
What we mean by an atomic foundation
I started building 8DB from scratch in March 2026 with a question inspired by nature: could a small set of composable structures support many kinds of information, with useful rules at each level?
In a database, that means taking identity, relationships, values and operations seriously at the foundation. A modality becomes a way to represent and work with information through that foundation. We describe this as an algebraic projection: a view with defined structure and operations that remains connected to the information it describes.
A graph exposes connections. A spatial representation supports questions about location. A time series preserves how observations relate through time. They can refer to shared entities while using the specialized indexes and layouts that make their own operations useful.
Specialized indexes, derived structures and domain-specific code still have work to do. Shared identity can span different physical layouts. The architectural aim is to make those capabilities cooperate around connected information, with more of their semantics supplied by the engine.
Storing an object is the beginning
A database can store a list of possible interventions as JSON. A more useful question is whether it can retain the alternatives that remain worth considering when cost, expected benefit and confidence point in different directions.
8DB's lattice operations make that kind of comparison explicit. In one inspected application integration, a domain supplies the ordering of its decision criteria and calls an existing operator to retain the non-dominated alternatives. A cheaper candidate can remain alongside a more capable one until the application has a justified reason to choose.
The domain supplies the meaning; the engine supplies a reusable operation. That is a substantial difference from merely having somewhere to save the candidate list. A separate lattice example shows how keeping competing explanations available can help a researcher decide what to measure next.
Time-series integration offers another example. A point observation, a bounded value, a below-detection observation and an absent reading can carry different meanings. Typed adapters connect those meanings to existing interval and lattice operations. The application defines the domain rules and uses the appropriate maintenance path to keep derived summaries current.
This is why we use omnimodal to describe 8DB. It is an extensible architectural direction, supported by native capabilities beyond the familiar document, graph and vector grouping. The question for an unfamiliar structure becomes: which representation and operations does it need, and which foundations can it reuse?
The modality library extends into hypergraphs, braids, point clouds, meshes, raster fields, tensors, lattices and manifolds. Each guide describes its actual operations. A multi-party relationship, an order-sensitive interaction and a geometric neighborhood are different structures; preserving those distinctions gives an application more useful building blocks.
A new capability still needs implementation and qualification. The opportunity is to inherit useful work instead of rebuilding the entire stack around each addition.
Compare the strongest alternatives
Several architectures can serve the same application. Here is the comparison worth making, based on the vendor documentation reviewed for this article.
| Approach | What it already offers | What to compare for your job |
|---|---|---|
| SurrealDB | Multiple data models, a unified query layer and shared transactional storage for records, edges and indexes | The native operations your domain needs, the chosen query plan and the work left in application code |
| ArangoDB | Integrated graph, document, vector and search capabilities | How its available operators and execution fit the complete question |
| PostgreSQL with suitable extensions | Mature relational infrastructure, extensible types and indexing, plus maintained specialist extensions | Whether one deployment already meets the need, and which extension and lifecycle responsibilities remain |
| A specialist stack | Independently chosen engines, scaling and operational ownership | The value of specialization against the actual cost of moving, reconciling, protecting and recovering shared information |
| 8DB | Native representations and domain operations built around reusable foundations, alongside integrated protection and embedded capabilities | The delivered combination for your deployment, including its complete query, resource use and lifecycle behavior |
SurrealDB's architecture documentation describes a shared store. Arango's platform presents integrated capabilities. PostgreSQL has established index extension contracts. A shared store or an extension mechanism alone cannot explain 8DB's difference.
Our case rests on the operations and combinations we have built, the results we can demonstrate, and the ability to extend that foundation. For the buyer, three questions expose the difference:
- Can it perform the domain operation? Retaining meaningful alternatives or interpreting bounded observations is more useful than storing their serialized form.
- Can it answer the combined question efficiently? The complete output matters, including the observations that explain it.
- What will the next feature inherit? Reusable operators, persistence and supported lifecycle behavior can save your team from creating another bespoke subsystem.
The work between systems counts too
Suppose an application stores observations in one system and searchable evidence in another. A correction has to reach the right index. Access changes have to reach the paths that serve the data. Recovery has to bring back a usable relationship between source and derived state.
An integrated product can take responsibility for some of that work. In a separately reviewed 8DB protected-record path, source changes and lexical index changes share a write transaction. The read path checks correspondence between source and index. Its recovery protocol restores historical content under current authority. Our restore article explains the practical reason: restoring data should not automatically restore an old permission.
That protected indexed-record route is separate evidence from the shipping benchmark. Together they show two useful kinds of integration: composing a richer question and maintaining a supported relationship through its lifecycle. A deployment that combines them needs its own qualification.
The potential buyer benefit is fewer responsibilities spread across connectors, jobs and services. The application can spend more effort on the useful question. Where a specialist materially improves the outcome, keeping it may still be the right decision.
Performance belongs beside capability
Breadth earns its place when the complete job performs well enough to use. We publish separate comparisons for cross-modal queries, time-series ingestion, key-value workloads and graph lookups.
These are different workloads with their own completion boundaries and configurations. They let a buyer inspect specific results instead of assuming that breadth requires poor performance, or that one strong result proves every possible combination.
The larger opportunity is an application whose questions become richer without its infrastructure becoming equally complicated. A reusable core can make new capabilities easier to add. Selective execution can make useful answers cheaper to compute. Integrated protection and recovery can reduce coordination your team would otherwise own.
Bring the question your stack makes difficult
Choose one feature that currently crosses data models or systems. Write down the answer it must return, the operations it needs and what must survive a correction, access change or interruption.
Then compare the complete job: capability, latency, resource use and the work your team must maintain. Include the strongest realistic alternative, which may already be one well-chosen database.
Bring us that question. We can map it to 8DB's native capabilities and define a bounded evaluation. You should be able to see where the architecture helps before deciding how much of your application it should own.
Research basis: current competitor documentation and retained implementation review, checked September 2026. The visual is a conceptual explanation. Linked benchmark articles retain their own measured scope; this article reports no new experiment.
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