Files
lancedb/docs/web/management/index.mdx
T
Brendan Clement 6398ff3629 docs: declare where management, jobs, feature engineering and curation apply
Databases, namespaces, jobs and data evolution work in both offerings.
Materialized views, computed columns and column refresh work in the
embedded library and vary on a deployment, which has to enable them.
Views and functions exist only on a deployment that enables them, and
aggregation, joins, windowing and sampling are SQL, so they need one
with SQL enabled.

Sections now say where they differ: views have SDK methods on a
deployment, dropping a function needs a further setting, a local job
handle runs in-process and has no history, create_index and
refresh_column behave differently against a deployment, and the
overviews no longer call computed columns and materialized views
available everywhere.
2026-10-08 21:31:42 -07:00

157 lines
5.5 KiB
Plaintext

---
title: "Management"
sidebarTitle: "Overview"
description: "Create, list, and drop the objects in a catalog, from Python, TypeScript, or SQL."
icon: folder-tree
keywords: ["ddl", "create", "drop", "list", "catalog", "management"]
---
Every [catalog object](/basics/catalog) is created, listed, and dropped the same
few ways. This section is the reference for those operations; the pages linked
from it cover what each object is for.
Operations that can take a while have an `_async` form returning a
[job](/basics/jobs).
## The surface at a glance {#surface}
<Note>
SQL requires a deployment that enables its SQL endpoint -- a local database has none.
See [SQL](/basics/sql#sql-is-remote).
</Note>
### Namespaces {#namespaces}
| | Python | TypeScript | SQL |
| --- | --- | --- | --- |
| create | `create_namespace` | `createNamespace` | -- |
| list | `list_namespaces` | `listNamespaces` | -- |
| describe | `describe_namespace` | `describeNamespace` | -- |
| exists | `namespace_exists` | -- | -- |
| drop | `drop_namespace` | `dropNamespace` | -- |
See [Namespaces](/management/namespace).
### Tables {#tables}
| | Python | TypeScript | SQL |
| --- | --- | --- | --- |
| create | `create_table` | `createTable` | `CREATE TABLE` |
| create empty | `create_table(schema=)` | `createEmptyTable` | `CREATE TABLE` |
| open | `open_table` | `openTable` | -- |
| list | `table_names`, `list_tables` | `tableNames`, `listTables` | -- |
| exists | `table_exists` | -- | -- |
| rename | `rename_table` | `renameTable` | -- |
| clone | `clone_table` | `cloneTable` | -- |
| drop | `drop_table`, `drop_table_async` | `dropTable`, `dropTableAsync` | `DROP TABLE` |
| drop all | `drop_all_tables` | `dropAllTables` | -- |
See [Tables](/management/table) for creating one and shaping its schema.
### Materialized views {#materialized-views}
| | Python | TypeScript | SQL |
| --- | --- | --- | --- |
| create | `create_materialized_view` | `createMaterializedView` | `CREATE MATERIALIZED VIEW` |
| open | `open_materialized_view` | `openMaterializedView` | -- |
| list | `list_materialized_views` | `listMaterializedViews` | `SHOW MATERIALIZED VIEWS` |
| refresh | `refresh` | `refresh` | `REFRESH MATERIALIZED VIEW` |
| drop | `drop_table` | `dropTable` | `DROP TABLE` |
<Note>
`list_materialized_views` reads every table's schema to find them, so it costs
one open per table. `SHOW MATERIALIZED VIEWS` asks the server instead.
</Note>
See [Materialized views](/management/materialized-view) for creating one, and
[Refresh a materialized view](/feature-engineering/materialized-views) for keeping
it current.
### Views {#views}
| | Python | TypeScript | SQL |
| --- | --- | --- | --- |
| create | `create_view` | `createView` | `CREATE VIEW` |
| list | `list_views` | `listViews` | -- |
| drop | `drop_view`, `drop_view_async` | `dropView`, `dropViewAsync` | `DROP VIEW` |
<Badge color="red">Enterprise</Badge> Views exist only on a deployment that
enables them; the SDK methods send the view's SQL query to the deployment. See
[Views](/management/view).
### Functions {#functions}
| | Python | TypeScript | SQL |
| --- | --- | --- | --- |
| create | `create_function`, `create_function_async` | -- | `CREATE FUNCTION` |
| get | `get_function` | -- | -- |
| list | `list_functions` | -- | `SHOW FUNCTIONS` |
| drop | `drop_function` | -- | -- |
<Badge color="red">Enterprise</Badge> A function runs on the server, and only on
a deployment that enables functions, so there is no local form. The TypeScript
SDK has no function methods; use Python or SQL.
See [Functions](/management/function).
### Jobs {#jobs}
| | Python | TypeScript | SQL |
| --- | --- | --- | --- |
| list | `list_jobs` | `listJobs` | `SHOW JOBS` |
| open | `open_job` | `openJob` | -- |
| cancel | `cancel_job` | `cancelJob` | -- |
| errors | `job.events` | `job.events` | `SHOW ERRORS` |
See [Jobs](/basics/jobs).
### Indexes {#indexes}
| | Python | TypeScript | SQL |
| --- | --- | --- | --- |
| create | `create_index`, `create_index_async` | `createIndex`, `createIndexAsync` | `CREATE INDEX` |
| list | `list_indices` | `listIndices` | -- |
| stats | `index_stats` | `indexStats` | -- |
| drop | `drop_index` | `dropIndex` | `DROP INDEX` |
<Note>
SQL `CREATE INDEX` covers one column and takes no user-chosen name -- the server
names it. For a multi-column or named index, use the SDK.
</Note>
Indexes are a performance decision rather than a structural one, so they are
covered under [Maintenance](/indexing).
## Namespaces qualify everything {#namespace-paths}
Most connection-level operations take a `namespace_path` (`namespacePath`) to
act inside a namespace rather than at the database root:
<CodeGroup>
```python Python icon="python"
db.table_names(namespace_path=["prod", "events"])
tbl = db.open_table("clicks", namespace_path=["prod", "events"])
```
```typescript TypeScript icon="square-js"
await db.tableNames({ namespacePath: ["prod", "events"] });
const tbl = await db.openTable("clicks", { namespacePath: ["prod", "events"] });
```
```sql SQL
SELECT * FROM prod.events.clicks
```
</CodeGroup>
In SQL the path is written as dotted identifiers instead.
## Dropping is not undoable {#dropping}
<Warning>
`drop_table` removes the table and every version of it. Table
[versioning](/management/table#versioning) does not survive the table being dropped, and
neither `drop_database` nor `drop_all_tables` asks for confirmation.
</Warning>
Dropping a **view** removes only the saved query. Dropping a **materialized
view** removes stored rows, because a materialized view is a table.