Find related material
Cosine similarity compares vector representations. An embedding model supplies those vectors; its version, dimensions and normalization define what the comparison means.
Explore the models / 8DB
Give a similar result its context.
Find candidates through vector and hybrid retrieval, then connect them to source records and the relationships that make them useful.
Implementation snapshot / Reviewed 18 September 2026
The engineering guide points to a persisted composition regression combining stored text, dense retrieval and a typed table contribution. It explicitly distinguishes ranked fusion from a general relational join, so an application can retain the richer outputs instead of treating every result as only a score.
Explore the complete retrieval workload →Native search guide: native_search_persisted_execution.rs, composition example at 7daa7908. PersistentSearchOutput exposes compatibility ranking and native contributions.
Documentary review on 18 September 2026, not a new vector benchmark. Confirm the actual dimensions, metric, filters, recall, model-generation path, build and platform for your evaluation. The broader search release gates remain open in the reviewed records.
Cosine similarity compares vector representations. An embedding model supplies those vectors; its version, dimensions and normalization define what the comparison means.
Supported approximate-neighbor paths retrieve candidate matches. Evaluate the balance between recall, response time and memory on your corpus.
Sparse and dense retrieval fusion brings different signals into candidate selection. Product codes, names and specialist vocabulary can matter alongside semantic similarity.
Documentary review, 18 September 2026 UTC. Supported index, filter, persistence and API combinations must be checked against the build selected for evaluation. Similarity is a retrieval signal, not a truth score.
The source, the asset and the moment can each change which result is useful.
Read the passage behind the match.
Explore model ↗Check the asset and its configuration.
Explore model ↗Bring dated observations into view.
Explore model ↗Conceptual model connections. 8DB offers these native representations; fewer handoffs and simpler application assembly are opportunities to test on the supported combination.
Start with an incident description and the identity of the equipment. The embedding model represents the query.
Illustrative application design, not an executed benchmark. Qualify the composed path, including external models, authorization, persistence and update visibility.
Measure from the declared input state to the usable output, including required parsing, embeddings, storage, index readiness, querying and result assembly. Report database-stage timing separately. Include memory, storage, network and measured energy when relevant.
| Approach | What it brings | What to compare with 8DB |
|---|---|---|
| Qdrant | Hybrid and multistage retrieval, including dense/sparse fusion. | Candidate quality, filtering and reranking, then the work needed to assemble source and relationship context. |
| PostgreSQL + pgvector | Vector search inside PostgreSQL, with HNSW and IVFFlat index options. | Existing SQL investment, speed/recall tradeoffs, filtered retrieval and the broader application's data shapes. |
| SurrealDB | An integrated data-model offering spanning records, documents, graphs and vectors. | The exact operations, deployment, protection and cross-model workload you need. |
| 8DB | Vector and hybrid retrieval alongside its wider native modality family. | Whether the supported combination reduces application assembly while meeting quality, freshness and resource targets. |
Vendor documentation reviewed 18 September 2026 UTC. Capability context, not a measured ranking. Hybrid search and multiple models are established market capabilities; the evaluation should test the combination that matters to your application.
Modality performance / Evidence reviewed 18 September 2026
99,488 real 768D passage embeddings; 512 queries, top 10, eight clients, 2 GiB server cap. Warmed, unfiltered retrieval on a shared workstation; different transports and unmatched persistence/governance. Fastest tested setting meeting each floor, not equal actual recall. Qdrant built faster and leads at the strictest shown floor.
Read the results, comparison and methods →8DB: 166 s with one construction thread. Qdrant: 18.3 s with up to eight, persisted. Later 8DB build tuning is a separate calibration, not the same configuration as the best search result.
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.
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.
Explore the ideas and implementation context behind this capability.
Explore the ideas and implementation context behind this capability.
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 include the linked vendor documentation in the comparison above. Additional context: 8DB modality scope; Qdrant hybrid queries; the related articles above. Internal source leads and outstanding release checks remain in the editorial record.
Download this referenceBring the data shapes, input state, expected output and the systems you use today. Define a comparison around that complete job.
Discuss your workload