LatticeDB vs Vector Databases

Most RAG systems start with a vector database — Chroma, LanceDB, pgvector, or sqlite-vec — and that is usually the right first move. This page is about the point where a pure vector store stops being enough, which arrives sooner than most teams expect.

Where vector-only retrieval breaks down

A vector database answers one question well: which chunks are semantically nearest this query. The problems show up around that answer.

Chunks have context that similarity does not capture. The nearest chunk came from a document, which has an author, a date, a version, and a place in a hierarchy. Retrieval quality usually improves when you can pull that context in — and in a vector-only store, that means a second database and a join in application code.

Similarity misses exact terms. Someone searching for an error code, a function name, or a product SKU wants lexical matching, not semantic neighbourhood. This is what BM25 is for, and it is why hybrid retrieval consistently outperforms pure vector search.

Relationships are the answer sometimes. "What else did this author write", "what supersedes this document", "what is two hops from this concept" are traversals. No amount of embedding quality answers them.

The usual response is to run a vector store plus a relational database plus a search index, and keep three systems consistent. LatticeDB's argument is that these are one question and should be one query.

MATCH (chunk:Chunk)
WHERE chunk.embedding <=> $query_vector < 0.3
   OR chunk.text @@ 'connection pool exhausted'
MATCH (chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person)
WHERE doc.version = $current_version
RETURN doc.title, author.name, chunk.text
ORDER BY chunk.embedding <=> $query_vector
LIMIT 10

Vector similarity, lexical matching, graph traversal, and a metadata filter, resolved together against one file. The full worked example is in Building a RAG System.

Feature comparison

Published latency figures

Every number below except the LatticeDB row comes from the vendor's own documentation or a third-party benchmark, on hardware and with methodology we did not control. They are order-of-magnitude orientation, not a head-to-head result — see how to read the numbers.

Sources for each row are in Competitive Analysis. LatticeDB's own measurements, including recall and memory at every scale, are in Benchmarks.

When a vector database is still the better choice

Your retrieval genuinely has no graph in it. A flat corpus of independent chunks with no meaningful relationships is exactly what a vector store is for. Adding a graph model buys you nothing.

You need to scale past one machine. LatticeDB is one file on one host. Qdrant, Weaviate, Milvus, and Pinecone shard and replicate.

You are already on Postgres. If your metadata lives in Postgres, pgvector keeps everything in one database and one transaction. That consolidation is worth more than a few milliseconds.

You need the ecosystem. LangChain and LlamaIndex integrations, managed hosting, hybrid-search tuning knobs, and reranking pipelines are mature in the dedicated vector stores and thin here.

Billions of vectors. LatticeDB is benchmarked to 1M vectors using roughly 1 GB of memory. Beyond that scale you want a purpose-built distributed system.

When LatticeDB fits

When your retrieval corpus has structure — documents, authors, versions, topics, citations, conversations — and you want that structure to participate in retrieval rather than sit in a separate database. When exact-term matching matters alongside semantic similarity. When you would rather ship one file than operate three services.

Start with Building a RAG System for a worked example, or Working with Embeddings for the vector-indexing details.