Skip to main content
LanceDB Embedded runs in your application’s process; your data can live on local disk or in object storage. LanceDB Enterprise distributes query execution, indexing, maintenance and refresh work across a cluster of many machines, outside your application. 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. See Architecture for how each one’s components fit together.

​
How they differ

​
Compare features

​
Usage differences between Enterprise and Embedded

The quickstart guide shows both LanceDB Embedded connections and Enterprise db://... connections. Once connected to LanceDB, the table API is largely the same: create a table, search, filter, evolve the schema, and store multimodal records. However, there are some semantic differences worth understanding when your code is talking to LanceDB Enterprise.

​
1. Connection model

In LanceDB Enterprise, your app connects via a db://... URI and sends requests to the cluster API. The cluster executes table operations on your behalf. Your code is coupled to a managed service endpoint, whereas LanceDB Embedded is directly coupled to local or object-storage paths.

​
2. Returned table type

Connecting to an Enterprise table via open_table(...) returns a RemoteTable, unlike LanceDB Embedded, which returns a LanceTable. RemoteTable is a catalog-backed table accessed through a server/cluster, and does not support all the same methods as LanceTable (see below).

​
3. Materialization APIs

For Python users working with LanceDB Enterprise, RemoteTable does not support table-level materialization methods like table.to_arrow() or table.to_pandas(). This protects users from accidentally materializing tables that are too large to fit in memory. Instead, materialize results through query/search builders, for example table.search(...).limit(...).to_pandas() for a vector or full-text search, or table.search().where(...).limit(...).to_arrow() for a filtered scan. For quick previews, use table.head().

​
4. Maintenance lifecycle

In LanceDB Embedded, you run maintenance yourself: optimize() compacts data files, adds new rows to existing indexes, and removes old table versions. In Enterprise, the cluster runs this work — along with async write and reindexing workflows — as background jobs, and the SDK’s maintenance calls do not trigger it. On an Enterprise table, the synchronous Python optimize(), compact_files(), and cleanup_old_versions() only emit a warning, and the asynchronous Python, TypeScript, and Rust clients reject optimize() as not supported. That means maintenance is managed by platform behavior and cluster configuration, not by explicit per-table maintenance calls in your application code.

​
5. Guardrails and limits

Enterprise can enforce platform-level guardrails, such as index/table limits and safety checks around operations like merge_insert when too many rows are unindexed. LanceDB Embedded mostly exposes storage/format-level behavior, and you tune many lifecycle tasks yourself. This means an operation in LanceDB Enterprise can fail due to service-level policy, not just because of local table shape or schema mismatch.
As a rule of thumb, all you need to remember is this: treat db://... as a network service boundary, use query builders to fetch results, and otherwise interact with your tables as you would in LanceDB Embedded.

​
Which one should I use?

It’s very simple to get started with LanceDB Embedded: Get started with pip install lancedb and begin ingesting your data and vectors into LanceDB. LanceDB Embedded (open source) 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.