Explore the models / 8DB

Documents & text

Keep the source behind the answer.

Preserve passages and document structure so retrieval can lead back to the material that supports a result.

Structure · search · trace
Model / DocumentsConceptual diagram
documents representation: conceptual diagramSOURCECONTEXTDOCUMENT → PASSAGE → EVIDENCE
A document is represented through its sections and passages, with a route back to the source.

The decision / Specialist context

Make an answer traceable to the right source.

Finding a phrase is useful. Knowing which version it came from, what it applies to and whether it is still valid makes it actionable.

WHEN TO CONSIDER 8DB

When the job crosses models.

8DB’s documented lexical-search fixture and native composition path give a concrete starting point for source-aware retrieval. Evaluate the parser, update and permission paths your application needs.

Explore the connected workflow ↗
Alternative to evaluate

MongoDB

Flexible document modeling with embedding, references and selective validation.

Read the source ↗
Alternative to evaluate

SurrealDB

Integrated document, graph and other model-oriented application data.

Read the source ↗
WHAT THE WORK REQUIRES

W3C PROV provides a vocabulary for provenance. Spotify’s search work supplies a practical motivation: help a person find relevant source material through the language of their question.

W3C PROV ↗Spotify podcast natural-language search ↗

Implementation snapshot / Reviewed 18 September 2026

Use stored knowledge to explain a match.

Documented native search regression

A documented regression indexes “automobile” and stores its lexical relationship to “car”. Exact-token search finds the first term; enabling stored synonym expansion lets the second retrieve the entity. The application uses the native Rust search API.

See the stored synonym example →
Same stored record. A different route to finding it.

Choose a query, then switch the stored synonym relationship on or off.

01 / QUERYcar

The term the application asks for.

02 / STORED RELATIONSHIPcar ↔ automobile

Present in the store; expansion is disabled for this query.

03 / INDEXED ENTITYautomobile

No exact-token match for “car”.

Expected fixture resultNo match

The indexed token is “automobile”. The stored relationship is not used while expansion is off.

Browser illustration of the documented native-search regression at 7daa7908. This control does not execute 8DB or generate an answer. A stored synonym connection is distinct from embedding similarity; input parsing, permissions and answer generation require their own qualification.

Download the example and evaluation checklist ↓
API, release scope and evidence limits

unified_search_with_store with a populated store and typed request. Example pinned to native_search_lexical_scope.rs at 7daa7908; later integration status is tracked separately.

This is a scoped search fixture, not qualification of every document parser, access-control policy or assistant workflow. The reviewed search records retain open integration and broader release gates. Confirm the evaluated build and input formats.

Start with the operations
your question needs.

  • Document and hierarchical representations
  • Native lexical retrieval
  • Links between passages, claims and source documents

Documented product scope, reviewed 17 September 2026. The underlying build and deployment must be qualified for your application.

Parsing coverage depends on the input format and decomposer. Extracting a claim, generating an embedding or interpreting a document can require an external model; storage does not establish correctness of those derived claims.
Connected native models

Keep the next question within reach.

Document retrieval can be the start of a source-backed investigation. 8DB keeps document structure and relationships available alongside vectors, records and graph dependencies.

These connections show the models involved in the application design. Compare the supported combination and full workflow with a realistic alternative.

Input → usable value / interactive design example

Answer an engineering question with inspectable sources

documents representation: conceptual diagramSOURCECONTEXTDOCUMENT → PASSAGE → EVIDENCE
Step 1 / Documents

Receive and parse a supported report

A document is represented through its sections and passages, with a route back to the source.

Next: Keep the source

Conceptual application workflow. Qualify the supported operations, external tools, protection and persistence for the complete path. These diagrams are explanatory, not measured results.

Read the complete workflow and comparison scope
  1. Receive and parse a supported report
  2. Preserve document sections and source identity
  3. Retrieve relevant passages and semantic candidates
  4. Resolve related equipment and recorded observations
  5. Assemble an answer with traceable supporting passages

A useful answer includes parsing, indexing, retrieval, evidence assembly and any model call. Compare the quality and cost of that whole path; count synchronization if source documents and indexes live separately.

Compare a realistic alternative.

Multimodel products such as SurrealDB provide document and related data-model entry points. The choice requires comparing concrete source-preservation and query behaviour, not just counting supported labels.

SurrealDB data models

Compare equivalent outputs and required guarantees, including the simplest single-product alternative where one exists. A specialist may remain the better fit when its operators, ecosystem or operational maturity are decisive. Combining native models becomes valuable when your actual question crosses them.

Modality performance / Evidence reviewed 18 September 2026

Define the useful result. Measure the complete job.

The comparison to make: Find an applicable passage and return its source, revision and related facts.

A reviewed timing for this specific job is not yet published here. The evaluation below defines the useful result and the measures that matter. Supporting measurements must match this model, its quality target and the required operating conditions.

01Retrieval quality
02Parse-to-searchable time
03Permission & update visibility
Include memory, storage, energy and hardware writes

Record build-time and serving memory separately, original and derived stored bytes, measured joules per completed job, and physical writes including indexing, compaction and recovery. A smaller representation does not by itself prove lower energy or longer device life.

Match correctness, freshness, durability and protection across alternatives. Encryption, authorization, adapters, network setup and output delivery belong in the complete-job comparison wherever required. No universal zero-overhead claim follows from these results.

Evaluate the result you need

Find an applicable passage and return its source, revision and related facts.

Illustrative evaluation workflow · qualify the required operations and deployment

  1. 01Document
  2. 02Passages and terms
  3. 03Relevant match
  4. 04Inspectable source

Source coverage

Can the result lead back to the relevant passage and revision?

Import to searchable

Include parsing, indexing and derived representations.

Update visibility

Check corrected, deleted and restricted sources.

Bring the workload that matters to you.

We’ll use its output, quality and operating requirements to define a useful comparison.

Discuss an evaluation ↗
Comparison scope, sources and next evidence

Recover document/lexical timings and run a source-mutation fixture. Separate JSON storage, text search and complete answer retrieval; verify parser and permission scope.

Match the required correctness, freshness, durability and protection. Include ingestion, transformation, indexing and delivery in a complete-job result. Measure memory, stored bytes, energy and physical writes separately. Vendor descriptions establish offers, not independent rankings or 8DB compatibility.

Market review: 20 September 2026 · Reference revision 3.0. Linked benchmark results retain their own dates and scope. Standards are evaluation context, not an 8DB certification.

Choose the path that fits your deployment.

Verify the supported API/SDK, data format, persistence and indexing behaviour for the release you plan to use. Match the operation-by-modality protection profile and device qualification to the workload.

Post-quantum protection · Plan a workload evaluation

Related articles

Take the next step into the thinking.

Reference / Reviewed 17 September 2026

Readable, shareable and traceable.

This reference explains 8DB’s public modality description with an explicit workload and selection criteria. It is a documentary review, not fresh execution of every operator or platform.

Public sources: 8DB modality scope; SurrealDB data models; the related articles above. Internal source leads and outstanding release checks remain in the editorial record.

Download this reference

Evaluate the question
your application needs to answer.

Bring the data shapes, input state, expected output and the systems you use today. Define a comparison around that complete job.

Discuss your workload