Vector search on object storage: Performance at scale without the infrastructure tax
Most vector databases require three systems: raw data in a lake, metadata in a warehouse, embeddings in a vector index. Three copies of state. Three things to keep in sync.
LanceDB stores everything in one table on object storage. Compute nodes are stateless. No RAM constraints at scale.
.svg)
Why teams switch
Compute-storage separation
Data lives on object storage at $0.02/GB/month. Compute scales with query load, not data size. 10 TB of data, one small query node during off-peak. No paying for idle capacity.
One table. Actual data
Embeddings, metadata, and raw blobs in the same table. Not links to S3. Blobs. Vector search, full-text search, and SQL filtering compose into a single query. No round trips.
Write a new column without rewriting the table
Adding a column doesn't rewrite existing data. Zero copy. New embedding model? Access control column? Test two models side by side? Column-level operations, not table-level rewrites.
IVF-based indexing
Inserts go to the appropriate partition without touching others. Deletes handled by lightweight bitmaps. MVCC for concurrent reads and writes. Index rebuilds happen asynchronously.
Comparison
The Power of the Lance Format
Vector Search
- Fast scans and random access from the same table — no tradeoff
- Zero-copy access for high throughput without serialization overhead
Multi-Modal
- Raw data, embeddings, and metadata in one table — not pointers to blob storage
- No separate metadata store to keep in sync
Enterprise-Grade Requirements
Security
Granular RBAC, SSO integration, and VPC deployment options.
Governance
Data versioning and time-travel capabilities for auditability.
Support
Dedicated technical account management and guaranteed SLAs.
Talk to Engineering
Or try LanceDB OSS — same code, scales to Cloud.
