LanceDBinfrastructure

Why LanceDB for Vector Search

Embedded vector database built on Lance columnar format

v1.1·10 min read·Kenneth Pernyér

lancedbvectorembeddingsaisemantic-search

The Problem

AI applications need vector search. Embeddings power semantic search, RAG (retrieval-augmented generation), recommendation systems, and similarity matching. But how do you store and query millions of vectors efficiently?

The vector database landscape is crowded and confusing.

Pinecone, Weaviate, Qdrant, Milvus, Chroma, pgvector—each makes different trade-offs. Some are cloud-only. Some require infrastructure. Some are designed for scale we don't need yet.

For AI-assisted development, we want the same pattern we apply elsewhere: start simple, add complexity only when required. An embedded database that grows with us beats a distributed system we have to manage from day one.

We needed a vector database that:

Embeds directly in the application (no separate service)
Handles our current scale without operational overhead
Uses a format optimized for AI/ML workloads
Has a clear path to scale when needed

Current Options

Option	Pros	Cons
pgvectorPostgreSQL extension for vector similarity search.	Uses existing PostgreSQL infrastructure SQL interface familiar to developers Combines vectors with relational data Managed options everywhere	Performance degrades at scale Not optimized for vector-heavy workloads Index types limited compared to specialized DBs PostgreSQL overhead for pure vector use cases
PineconeFully managed vector database. Zero infrastructure.	Zero operational overhead Scales automatically Good performance out of the box Simple API	Cloud-only, no local development Cost scales with usage Vendor lock-in Data leaves your infrastructure
LanceDBEmbedded vector database built on Lance columnar format.	Embedded—runs in your process, no server Lance format optimized for ML workloads Works locally and in cloud storage (S3) Rust core, Python/JS bindings	Younger than alternatives Smaller community Scaling requires architectural changes Fewer managed options
QdrantRust-based vector database with rich filtering.	Excellent filtering capabilities Rust performance Good documentation Self-hosted and cloud options	Requires running a server More operational overhead than embedded Another service to manage

Future Outlook

Vector databases are infrastructure for the AI age. Every application that uses embeddings needs one.

The trend is toward simpler, embedded solutions for most use cases.

LanceDB represents this trend: start with an embedded database, scale to cloud storage when needed. No Kubernetes, no managed service bills, no vendor lock-in.

The Lance columnar format is designed for ML: fast scans, efficient storage, version control for datasets. It's not just a vector database—it's a foundation for AI data infrastructure.

For massive scale (billions of vectors, millisecond latency requirements), dedicated services like Pinecone or self-hosted Qdrant make sense. For most applications, embedded is enough.

Our Decision

✓Why we chose this

Zero infrastructureEmbedded in your application. No server to deploy, no service to manage.
Lance formatColumnar format designed for ML: fast vector operations, efficient storage, versioning.
Local-first developmentDevelop locally with real data. No cloud dependency during development.
S3-compatible scalingSame code works with local files or cloud object storage.

×Trade-offs we accept

Younger ecosystemLess battle-tested than Pinecone or pgvector. We accept this for the simplicity gains.
Scaling architectureHorizontal scaling requires moving to distributed setup.
Community sizeSmaller community than established options. Documentation is good but fewer Stack Overflow answers.

Motivation

We chose LanceDB because it matches our philosophy: start simple, add complexity only when required.

For our current scale—thousands to millions of vectors—embedded is perfect. We don't need a distributed vector database. We don't want to manage another service. We want vectors stored alongside our application, queryable in milliseconds.

The Lance format is a bet on the future of AI data infrastructure. It's designed for the workloads we're building: embeddings, features, model artifacts. When we need to scale, the format supports it.

This choice is honest: we're still evaluating.

The vector database space is evolving rapidly. LanceDB fits our current needs. If requirements change—massive scale, complex filtering, managed operations—we'll re-evaluate. The data is portable; the decision isn't permanent.

Recommendation

Use LanceDB for:

RAG applications: Store document embeddings, retrieve by similarity
Semantic search: Find similar items, recommendations
Local AI development: Prototype without cloud dependencies
Moderate scale: Up to millions of vectors

Consider alternatives when:

You need managed operations (→ Pinecone)
You need complex filtering at scale (→ Qdrant)
Vectors are secondary to relational data (→ pgvector)

Start embedded. Add infrastructure only when you hit real limits.

Examples

lib/vectorStore.tstypescript

import * as lancedb from '@lancedb/lancedb';

// Connect to local database (or S3 URI for cloud)
const db = await lancedb.connect('./data/vectors');

// Create table with embeddings
interface Document {
  id: string;
  text: string;
  vector: number[];  // embedding from your model
  metadata: Record<string, unknown>;
}

const table = await db.createTable<Document>('documents', [
  {
    id: 'doc-1',
    text: 'LanceDB is an embedded vector database...',
    vector: await embed('LanceDB is an embedded vector database...'),
    metadata: { source: 'docs', category: 'database' },
  },
]);

// Semantic search
const query = await embed('How do I store embeddings?');
const results = await table
  .search(query)
  .limit(10)
  .toArray();

// Results ranked by vector similarity
for (const doc of results) {
  console.log(doc.text, doc._distance);
}

LanceDB embeds directly in your application. Create tables, add documents with embeddings, search by similarity—all without a separate server.

SurrealDBWhy SurrealDB Burn & PolarsWhy Burn & Polars Converge-ProviderLLM-based Agents