Skip to content

Research

8DB | Native Multimodal Data: Connect the Dots Across Graphs, Maps and Time Series

Relationships, location, time and documents offer different ways to understand the same data. 8DB connects those perspectives through native representations and shared identity, so your questions can cross them. See how that changes an investigation and what to test in your own workflow.

Published
Updated
Reading time4 minutes
Multimodal dataDatabase architectureCross-modal queryETL

An analyst wants to know which vessels have a connection to a particular owner, entered a review area and reported an unusual signal. Each part is familiar. Getting a reliable answer across the ownership graph, location history and sensor store can be the difficult part.

Which identifier names the vessel in each system? Are the records current to the same point? Can this analyst use every source contributing to the answer?

8DB's architectural proposition is to keep those perspectives connected through shared information. Change the question, keep the identity. A graph follows ownership. A spatial index filters locations. A time-series operation examines readings. Each representation contributes something useful to the same investigation.

Follow one vessel through the questions

Imagine Northstar, a fictional vessel linked to Harbor Group through an intermediary company. Its latest recorded position is inside a review area. Its sensor history contains a flagged spike.

The analyst needs all three conditions together. A graph result alone might include vessels elsewhere. A spatial result might include unrelated owners. A signal spike alone says little about either relationship.

In the interactive example, choose a vessel and switch perspectives. The visible identity stays fixed while the useful structure changes. Combining the filters selects Northstar from the synthetic records. The example makes the architecture tangible; it runs in the browser and makes no claim about database speed or a deployed maritime system.

Interactive explanation · synthetic vessel fixture

Change the question. Keep the same identity.

Select a vessel, then change how you look at it. The highlighted object remains the same across every view.

Northstar · vessel-041Source: fixture-01 · Policy: demonstration view

Who is connected to this vessel?

Harbor Group
↓ ownership link
Coast Holdings
↓ ownership link
Northstar
Harbor GroupCoast HoldingsNorthstarOwner → holding company → vessel

vessel-041 · Two hops to Harbor Group.

Now combine the questions

Connected to Harbor Group and inside the review area and a flagged signal? In this fixture, Northstar satisfies those three filters. Confidence and authority still require their own evidence checks.

This browser illustration uses one synthetic fixture to explain the vessel-query example in the article. It is not a live 8DB query or a performance measurement. A shared identity allows different indexes and physical layouts; it does not mean those views have no storage cost.

Keep specialized structures close to shared information

A projection is a way of representing and querying information. Shared identity does not require every projection to use the same physical layout. An adjacency structure serves relationships; a spatial index serves location queries. Both can refer back to the same underlying entity.

That distinction matters. Stonebraker and Çetintemel's database architecture research explains why workload-specific storage and execution choices can be valuable. Consolidation has to preserve those choices to be useful. Read the ICDE paper.

8DB is an omnimodal database with native mechanisms for multiple representations. The reviewed implementation includes record and blob operations, graph and hypergraph round trips, and vector, spatial and time-series similarity operations. Those individual paths provide building blocks. The protection, freshness and recovery behavior of a combined application must be qualified against its actual configuration.

For a buyer, the important unit is the complete question: how well does the system answer it, and how much supporting infrastructure must you operate?

Represent what an ordinary list would hide

Some questions need more than the familiar models. A hypergraph can preserve a relationship involving several participants. An order lattice can retain alternatives that are incomparable under the selected criteria. A braid can represent sequencing and interactions where changing order matters.

8DB's work on these structures extends the same idea: give the question a representation that preserves the distinctions it needs. A relationship between several parties should remain identifiable as that relationship. Competing alternatives should remain distinguishable until a justified rule selects among them.

The application still needs explicit meanings for the edges, comparisons and operations. Richer structure gives reasoning something precise to work with; the rules determine which conclusions are justified.

A better representation can make the question cheaper to answer. Sometimes the gain comes from less copying and coordination; sometimes it comes from preserving a relationship or bound that avoids a larger calculation. The useful test is whether the complete answer meets your quality requirement on the resources you can afford.

Judge the coordination work you can remove

A separate engine can be an excellent choice for a concentrated workload. Multi-model products also offer established alternatives: Arango describes graph, document, vector, key-value and search capabilities in one platform. Breadth alone cannot establish an 8DB advantage. Arango's platform description.

The opportunity for 8DB grows where questions repeatedly cross representations and deployment boundaries. Every integration you can retire may remove work around identifier mapping, update delivery, access rules and recovery. Those are potential savings to evaluate in your system, rather than a fixed percentage to assume.

Take the vessel question through one complete test. Change an ownership record and observe which answers change. Restrict a source and check whether the combined result handles that restriction correctly. Restore a declared snapshot and inspect the identities and histories it returns. Measure latency and resource use with the same completion and protection requirements on both sides.

Our separate time-series ingestion and key-value workload articles show how to read a particular capability's performance in context. A combined workflow needs its own evidence, including the coordination work between its parts.

Bring a question that currently crosses systems

Describe one question and the systems your team uses to answer it. A sentence is enough; confidential records can wait. We can map the representations, source bindings and access requirements, then identify a useful evaluation against the workflow you already operate.

Send us your cross-system question. The aim is a better answer with less machinery to keep in agreement.

Evidence scope Architecture analysis · implementation reviewed · illustrative vessel example. Explore the evidence.

Continue reading

The next layer of the argument.

Engineering note

One Protected Substrate

Multimodal Databases Already Exist. So What’s Different about 8DB?

The difference becomes useful when your application needs more than several data formats. 8DB brings native operations, connected representations and reusable mathematical structures into the database, so more of the work behind a complete answer can happen there.

8 min readArchitecture and source review · linked workload measurements · conceptual visualRead article ↗