mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-30 15:26:52 +00:00
Will JonesandClaude Opus 5.5
4d7a64712f
## Summary Adopts the product terminology guide across the docs site pages, SDK docstrings and error messages. "LanceDB OSS" and local mode become **LanceDB Embedded**. "Remote" as the execution model becomes **LanceDB Distributed**, which LanceDB Enterprise provides. Where free vs paid is the point, pages contrast "LanceDB Embedded (open source)" with "LanceDB Enterprise". This is a first trial of the Embedded name, so reviewers can judge it in context. - **Embedded vs Distributed** for where execution runs (`optimize()`, consistency, branching, maintenance). Main pages define it once: "LanceDB Enterprise runs LanceDB Distributed: …" - **LanceDB Cloud** is kept only for legacy-Cloud specifics (`db://` region, the brute-force KNN limit) and marked legacy. "Cloud and Enterprise" becomes Enterprise or Distributed. - **Plan executor** becomes "executor" or the fleet name. - **Error messages** change, e.g. `optimize is not supported for remote tables.` → `... in LanceDB Distributed.` Tests that match on them are updated. - **Vale rules** (`EmbeddedName`, `OSSProduct`, `RemoteExecution`, `DistributedEnterprise`, `LegacyCloud`, `InternalNames`) enforce the terms in prose. Unchanged: identifiers (`availability.oss`, the `remote` module and feature, `RemoteTable`, `db://`), heading anchors, internal code comments, and Geneva. ## Evidence - Rust lib tests for the changed messages and the Python tests in `test_remote_db.py`, `test_materialized_views.py` and `test_table.py` pass locally. - Not run locally: - The Node tests: `remote.test.ts` and `table.test.ts` have updated assertions. - Vale. - The `experimental_functions`-marked materialized-view tests. - `docs/src` API reference was hand-edited to match the docstrings rather than regenerated. ## Merge Risk **Door:** two-way; prose and message text only. **Blast Radius:** `docs`, `error-messages`: callers matching on old error strings would break. Companion PRs: lancedb/docs (assembler labels, STYLE.md) and sophon (Enterprise pages). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
74 lines
3.5 KiB
Plaintext
74 lines
3.5 KiB
Plaintext
---
|
|
title: "LanceDB Embedded or Enterprise?"
|
|
sidebarTitle: "Embedded and Enterprise"
|
|
description: "Start with an embedded library, or use the LanceDB Enterprise multimodal lakehouse for shared AI workloads."
|
|
icon: compass
|
|
keywords: ["oss", "enterprise", "embedded", "deployment", "availability", "comparison"]
|
|
---
|
|
|
|
LanceDB gives you two ways to work with multimodal data, both built on the open
|
|
[Lance](/basics/lance) format.
|
|
|
|
**LanceDB Embedded (open source)** is a library that runs in your
|
|
application's process; your data can live on local disk or in object storage.
|
|
You control the application,
|
|
its resources, and table maintenance, without a separate database service.
|
|
[Try the quickstart](/quickstart) to create a table and run your first search.
|
|
|
|
**LanceDB Enterprise** is a multimodal lakehouse for data curation, feature
|
|
engineering, search, and training data access. It adds query-serving capacity,
|
|
data caching, and background operations for teams working with shared
|
|
multimodal datasets. LanceDB Enterprise runs LanceDB Distributed: query
|
|
execution, indexing and maintenance run on the Enterprise service, outside your
|
|
application.
|
|
[Connect to Enterprise](/basics/connect#enterprise) when your cluster is ready.
|
|
|
|
<span id="labels" />
|
|
<span id="availability" />
|
|
|
|
## Why choose Enterprise? {#why-enterprise}
|
|
|
|
### Serve growing workloads {#serving}
|
|
|
|
Add query-serving capacity as more applications and users depend on your data.
|
|
Enterprise spreads query traffic across a fleet and caches frequently read
|
|
table data near compute, reducing repeated reads from object storage. Query
|
|
serving and background work use separate resources, so you can size each for
|
|
your workload. See [Enterprise architecture](/enterprise/architecture).
|
|
|
|
### Reduce operational work {#operations}
|
|
|
|
Let the service handle routine table maintenance instead of scheduling it in
|
|
application code. Enterprise handles background [compaction](/maintenance/compaction) and can
|
|
[clean up old table versions](/maintenance/cleanup) according to your retention
|
|
policy. Configure these maintenance tasks for your Enterprise cluster so each
|
|
application does not have to schedule them.
|
|
|
|
### Fit your deployment requirements {#deployment}
|
|
|
|
Choose a managed deployment or bring LanceDB into your own cloud account.
|
|
Enterprise integrates with OpenTelemetry for metrics and traces, helping your
|
|
team monitor the service alongside your applications. Talk to us about your
|
|
cloud, networking, and operational requirements to plan the right deployment.
|
|
The [Enterprise overview](/enterprise) explains the available options.
|
|
|
|
### Connect your data workflows {#workflows}
|
|
|
|
Use the same tables for retrieval, dataset preparation, and training data access.
|
|
With its [SQL endpoint](/basics/sql) enabled, Enterprise supports analytical
|
|
[curation](/curation), including joins, grouping, and sampling.
|
|
[Feature engineering](/feature-engineering) adds derived columns and tables;
|
|
computed columns and materialized views require the corresponding features to
|
|
be enabled for your Enterprise cluster.
|
|
[Geneva](/geneva) runs Python feature backfills as distributed jobs.
|
|
[Training data loaders](/training/data-loading), available in both offerings,
|
|
read the resulting datasets for model training.
|
|
|
|
## Plan your Enterprise deployment {#get-started}
|
|
|
|
[Talk to us about your workload](https://www.lancedb.com/contact) to discuss your
|
|
data, query traffic, pipelines, and deployment requirements.
|
|
|
|
For a closer look at how the service runs, read the
|
|
[Enterprise architecture](/enterprise/architecture).
|