Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lancedb.com/llms.txt

Use this file to discover all available pages before exploring further.

LanceDB Enterprise is the production deployment option for teams that want to run LanceDB as a private cloud or bring-your-own-cloud (BYOC) multimodal lakehouse. If you are new to multimodal lakehouses, the short version is this: LanceDB keeps vectors, metadata, and source data together in open table storage, while Enterprise adds the distributed infrastructure needed to serve real production workloads on top of that data. It is designed for teams that need more scale, more operational visibility, and more control than a single embedded process can provide.
If you need private deployments, high performance at extreme scale, or if you have strict security requirements, reach out to our team to set up a LanceDB Enterprise cluster in your environment.

​
Why use LanceDB Enterprise?

If you are evaluating LanceDB for a production AI system, Enterprise is built around three practical needs: handling very large vector workloads, running feature engineering close to the data, and operating the platform with production visibility.

​
1. 100B+ row scale

LanceDB Enterprise is built for demanding workloads that exceed the capabilities of a single machine, whether that’s extremely large data volumes or a high number of concurrent queries. Instead of asking your application to own caching, query scaling, and maintenance, Enterprise turns those into platform capabilities. This matters when your AI application moves past a prototype and starts serving real users, larger datasets, and more concurrent requests.
  • Low-latency tiered cache: Enterprise keeps frequently read data closer to compute, so common queries do not need to fetch the same data from object storage over and over again. That helps reduce wait times and makes performance more predictable as traffic increases.
  • Horizontal query throughput: Instead of relying on one application process to answer every query, Enterprise can spread search traffic across multiple nodes. This lets teams add capacity as usage grows, rather than re-architecting the application each time demand spikes.
  • Distributed search: Coming soon. Enterprise is adding dynamic horizontal scaling to search execution to allow for low latency search at much higher volumes and concurrency.
  • Distributed indexing and compaction: Coming soon. Enterprise is expanding support for large-table maintenance so indexing and storage cleanup can happen as platform workflows rather than as manual operator tasks.
  • Enterprise training cache: Coming soon. Enterprise is extending the same storage-aware caching model to training and feature engineering pipelines so large jobs can use GPU capacity more efficiently.

​
2. Feature engineering with Geneva

For many teams, retrieval is only part of the problem. They also need a reliable way to derive new columns, run backfills, and keep feature pipelines close to the data they already store in LanceDB. This is what Geneva enables.
  • Derived features: Create new columns from existing data and user-defined logic without standing up a separate feature platform first.
  • Large-table backfills: Update or recompute features across large datasets without wiring your own distributed batch system around OSS tables.
  • Shared workflows: Use Geneva clusters, manifests, and jobs to manage feature engineering work in one place.

​
3. Enterprise-grade monitoring

Production retrieval systems need more than search or training performance. Teams also need to observe the system, choose how it is deployed, and satisfy security and compliance requirements.
  • Metrics and traces: Integrates with existing observability systems for monitoring and distributed tracing using OpenTelemetry.
  • Deployment choice: Run LanceDB as a managed deployment or install it inside your own cloud account with BYOC.
  • Private networking and compliance: Designed for production environments that need encryption at rest, private connectivity options, and compliance coverage such as SOC 2 Type II and HIPAA.

​
How is LanceDB Enterprise different from OSS?

LanceDB OSS runs inside your application process. LanceDB Enterprise runs as a distributed cluster across many machines. Both are built on the same Lance columnar file format, so moving data from one edition to the other does not require a data conversion step.
DimensionLanceDB OSSLanceDB EnterpriseWhat the difference means
ModeSingle processDistributed fleetOSS lives on one host. Enterprise spreads work across nodes and keeps serving even if one node fails.
Latency from object storage500–1000 ms50–200 msEnterprise mitigates network delay with an SSD cache and parallel reads.
Throughput10–50 QPSUp to 10,000 QPSA cluster can serve thousands of concurrent users; a single process cannot.
CacheNoneDistributed NVMe cacheEnterprise keeps hot data near compute and avoids repeated S3 calls.
Indexing & compactionManualPlatform-managed workflowsOSS requires operator-managed maintenance; Enterprise is moving more of that work into the platform as support expands.
Data formatSupports multiple available standardsSupports multiple available standardsNo vendor lock-in; data moves freely between editions.
DeploymentEmbedded in your codeBYOC or ManagedEnterprise meets uptime, compliance, and support goals that OSS cannot.

​
Architecture and scale

LanceDB OSS is directly embedded into your service. The process owns all CPU, memory, and storage, so scale is limited to what one host can provide. LanceDB Enterprise separates routing, query execution, and background work across a cluster. You can add capacity by adding nodes, and the platform can keep serving traffic even when individual nodes are unhealthy. Read More: LanceDB Enterprise Architecture

​
Latency of data retrieval

With LanceDB OSS, read latency depends heavily on where the data lives. If you use local disk or shared file storage, reads can be quite fast. But if you point an embedded deployment at S3, GCS, or Azure Blob, each read still pays the latency of remote object storage, especially when data is cold. LanceDB Enterprise is designed for the object-storage-backed case. It uses NVMe SSDs as a hybrid cache and executes reads across a distributed serving layer, so repeated reads do not always pay the full object-store round trip. The first read fills the cache, subsequent reads can come from local disk, and parallel chunked reads further reduce tail latency. This matters when the application serves interactive dashboards, real-time recommendations, or other latency-sensitive workloads on top of object storage. Read More: LanceDB Enterprise Performance

​
Throughput of search queries

A single LanceDB OSS process shares one CPU pool with the rest of the application. When concurrent queries hit that CPU, retrieval and similarity processes compete for cores. The server cannot process more work in parallel and any extra traffic waits in the queue, raising latency without increasing queries per second. LanceDB Enterprise distributes queries across many execution nodes. A load balancer assigns queries to the least-loaded node, so throughput grows as more nodes join the cluster instead of stalling at a single-process ceiling.

​
Caching of commonly retrieved data

LanceDB OSS has no built-in cache. Every read repeats the same object-store round trip and pays the same latency penalty. LanceDB Enterprise shards a cache across the fleet with consistent hashing. Popular vectors remain on local NVMe drives until they age out under a least-recently-used policy. Cache misses fall back to the object store, fill the local shard, and serve future reads faster. This design slashes both latency and egress cost for workloads with temporal locality.

​
Maintenance of vector indexes

Vector indexes fragment when data is inserted, updated, or deleted. Fragmentation slows queries because the engine must scan more blocks. LanceDB OSS offers a CLI call to compact or rebuild the index, but you must schedule it yourself. LanceDB Enterprise is designed to move more of this maintenance into background platform workflows so operators spend less time managing it manually. We are continuing to expand distributed indexing and compaction support for the largest workloads. Read More: Indexing in LanceDB

​
Deployment and governance

When you work with LanceDB OSS, it is included as part of your binary, Docker, or serverless function. The footprint is small, and no extra services run beside it. LanceDB Enterprise comes in two flavors. The BYOC deployment installs the system inside your VPC, so data never leaves your account. The managed option hands day-to-day operations to the vendor, including patching, scaling, and ongoing monitoring. Both enterprise modes are designed for private networking, compliance, and operational oversight. Read More: LanceDB Enterprise Deployment

​
Which one should I use?

It’s very simple to get started with OSS: Get started with pip install lancedb and begin ingesting your data and vectors into LanceDB. LanceDB OSS makes sense when your dataset fits on one machine, traffic is still modest, and your team is comfortable handling maintenance tasks such as compaction or reindexing itself. Move to LanceDB Enterprise when retrieval becomes shared infrastructure for your business: your data or traffic has outgrown a single machine, you need private deployment options, or you want platform support for monitoring, security, and large-scale feature workflows. If these sound like your use cases, reach out to us and we can help you scope your workload and arrange an Enterprise proof of concept.