Refresh quickstart around AI data workflows

docs/docs.json

@@ -47,7 +47,6 @@
                 "group": "LanceDB Enterprise",
                 "pages": [
                   "enterprise/index",
-                  "enterprise/quickstart",
                   "enterprise/architecture",
                   "enterprise/security",
                   "enterprise/benchmarks",

docs/enterprise/architecture.mdx

@@ -81,7 +81,7 @@ A [remote table](/tables-and-namespaces#understanding-tables) is the user-facing
 
 This is why Enterprise feels familiar at the API level while operationally behaving differently. Your application still issues table operations and queries, but it is no longer coupled to a local storage path or a single host. Instead, the cluster takes responsibility for execution, coordination, and background upkeep. In SDK terms, `open_table(...)` returns a `RemoteTable`. Architecturally, a remote table is the bridge between the client-facing API and the storage-backed system behind it.
 
-This design makes LanceDB Enterprise suitable for catalog-backed layouts, see [Namespaces and the Catalog Model](/namespaces) for more details. For the basic application flow, see the [Enterprise quickstart](/enterprise/quickstart).
+This design makes LanceDB Enterprise suitable for catalog-backed layouts, see [Namespaces and the Catalog Model](/namespaces) for more details. For the basic application flow, see the shared [quickstart](/quickstart).
 
 ## Read path
 

docs/enterprise/index.mdx

@@ -26,7 +26,7 @@ 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
+LanceDB Enterprise is built for demanding workloads that exceed the capabilities of a single machine, whether from 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
@@ -134,6 +134,68 @@ monitoring. Both enterprise modes are designed for private networking, complianc
 
 Read More: [LanceDB Enterprise Deployment](/enterprise/deployment/)
 
+## Usage differences between Enterprise and OSS
+
+The [quickstart](/quickstart) guide shows both local 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 embedded LanceDB 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 embedded LanceDB,
+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()` or `table.query(...).to_arrow()`. For quick previews, use
+`table.head()`.
+
+### 4. Maintenance lifecycle
+
+In Enterprise, maintenance operations like `optimize` and `compact_files` are handled by the cluster
+as background work. You can trigger them manually, but they are not required for performance or
+correctness in the same way they are in embedded LanceDB.
+
+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. Embedded LanceDB 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.
+
+### 6. Cluster-managed background work
+
+In Enterprise, async writes and reindexing workflows are handled by cluster background systems. In
+embedded LanceDB, if you want ongoing upkeep, you usually schedule and run it yourself in your
+application or jobs.
+
+In practice, your app issues table operations, and the platform handles distributed orchestration for
+maintenance and indexing in the background.
+
+<Info>
+As a rule of thumb, all you need to remember is this: treat `db://...` as a remote service boundary,
+use query builders to fetch results, and otherwise interact with your tables as you would in embedded
+LanceDB.
+</Info>
+
 ## Which one should I use?
 
 [It's very simple to get started with OSS](/quickstart/): Get started with `pip install lancedb` and begin ingesting

docs/index.mdx

@@ -90,7 +90,7 @@ for agents. Start here:
     href="/quickstart"
   >
     Get started with LanceDB in minutes.
-</Card>
+  </Card>
   <Card
     title="Basic Table Operations"
     icon="table"
@@ -118,7 +118,7 @@ private deployments, and can operate under strict [security requirements](/enter
 <Card
   title="Quickstart"
   icon="rocket"
-  href="/enterprise/quickstart"
+  href="/quickstart"
 >
-  Get started with LanceDB Enterprise in minutes.
+  Get started with LanceDB in minutes, including Enterprise `db://` connections.
 </Card>