Skip to main content
LanceDB Enterprise deploys on a Kubernetes cluster (AKS, EKS, GKE, or self-managed) with object storage for data persistence and your cloud’s private networking for secure connectivity. The architecture below is the same shape on every cloud; the only cloud-specific part is how storage containers are organized, covered at the end of this page for Azure Blob Storage.

​
General architecture overview

​
Key components

  • LanceDB architecture is deployed in a Kubernetes cluster within its own VPC.
  • Client applications connect to the cluster securely using your cloud’s private link service.
  • The cluster is granted object storage read/write permissions using cloud-native workload identity (Azure Workload Identity, IRSA on EKS, or Workload Identity Federation on GKE).
  • A message queue — a managed service such as Azure EventHub, or a self-hosted Kafka cluster in Kubernetes — carries LanceDB’s internal message passing.

​
Read path architecture

​
Read path flow

  1. Client application sends a query request through the private link.
  2. Query nodes receive and process the request.
  3. Executors execute the query using the distributed data cache to speed up read queries.
  4. Object storage stores data and indices in Lance format, while executors maintain a distributed cache for performance.

​
Write path architecture

​
Write path flow

Query nodes write data and indices synchronously to object storage in Lance format while asynchronously sending data modification events to the message queue (a managed service such as Azure EventHub, or a self-hosted Kafka cluster). These write events are processed by the Lance Agent, which launches indexing pods or data optimization pods to optimize data for better read performance.

​
Deployment models

LanceDB Enterprise supports three deployment models, available on AWS, GCP, and Azure:

​
1. Fully managed service

  • Infrastructure and storage in LanceDB’s cloud account.
  • Complete management by the LanceDB team.
  • Simplest setup for customers.

​
2. BYOC (bring your own cloud)

  • Infrastructure and storage in the customer’s cloud account.
  • Fully managed by LanceDB.
  • Full control over data residency.

​
3. Hybrid — bring your own container

  • Infrastructure in LanceDB’s account.
  • Storage containers in the customer’s account.
For private deployments, high performance at extreme scale, or if you have strict security requirements, contact us about LanceDB Enterprise.

​
Azure-specific: storage containers

The one part of this architecture that is genuinely cloud-specific is how object storage is organized. On Azure, data lives in Blob Storage containers, grouped under one or more storage accounts — the same multi-tenant or multi-workload layout applies whether you use a single account with several containers, or split workloads across accounts:
The equivalent on other clouds is an S3 bucket (AWS) or a Cloud Storage bucket (GCP); everything else on this page — the Kubernetes cluster layout, the read and write paths, and the deployment models — applies unchanged.