Skip to main content

Catalog Hierarchy

A catalog keeps track of named data objects, such as tables and views, so applications can discover and access them. In LanceDB Enterprise, the catalog is the top-level entry point: it organizes databases, which in turn organize namespaces and tables — similar to a catalog in Postgres, Snowflake, or other database systems. The catalog itself has no name of its own — it’s just the root — and an Enterprise deployment’s catalog is identified by its endpoint, not a name like the objects beneath it. LanceDB Embedded has no catalog at all. Connect directly to a database instead of going through a catalog. A database contains namespaces that group related tables and views. Namespaces can also contain other namespaces, letting teams organize data by project, environment or purpose. For example, a search application can keep production and staging data in separate namespaces within the same database, with prod further split into a nested search namespace:

Namespace name and path

A namespace’s name is just its own component, such as search. Its path is the full sequence of names from the database down to it: in the diagram above, search sits inside prod, so its path is the sequence prod, search. A namespace path is never written by joining those names with . — a dot is a valid character inside a name, so a dot-joined path couldn’t always be split back into its components unambiguously. The two forms below are how SQL actually writes one.

Schema

SQL addresses a namespace path as a schema, the ANSI standard’s term for the same concept: a nested path collapses into one identifier, its components joined by $ instead of .. The path’s length changes what the schema looks like: $ can’t appear in an ordinary name, so a schema can always be split back into its exact path, unlike a dot-joined one. (This “schema” is the namespace path as a SQL identifier — distinct from a table’s Arrow schema, its column names and types.)

Object identifier

An object — a table, view, function, secret, or storage integration — is addressed in SQL by the ANSI three-part identifier database.schema.name, where schema is exactly the $-joined path above. The documents table in search, nested inside prod, in database ai_data, is ai_data.`prod$search`.documents. One directly under the database root uses public: ai_data.public.documents. See Namespace for the full CREATE/ALTER/DROP syntax.

Connecting

You always run table and query operations within a database; cross-database operations go through SQL instead. The same Python, TypeScript and Rust SDKs reach a database and the catalog separately.

Connecting to Catalog

connect_catalog(endpoint) connects to Enterprise’s root catalog, which can list, create and drop databases across the whole deployment. Its connect_database(name) and create_database(name) then return the same kind of database connection lancedb.connect() does. This connection is for database administration, not table or query work: list, create and drop databases through it, then switch to a database connection for everything else — tables, queries, and SQL all run within a database, never directly against the catalog. Local filesystem and object-store deployments have no catalog to connect to — each is already scoped to one database.

Connecting to Database

lancedb.connect(uri) opens one database in a single call — a local directory, an object-storage path, or (with a db:// URI) a specific Enterprise database. The table below shows which URI reaches which kind of database directly.

A local directory

Embedded in your application, LanceDB reads and writes the tables in a directory on disk.

Object storage

With an object storage URI the library is still embedded: your process runs every query and reads and writes the bucket directly, with credentials from its environment or its connection’s storage_options.
In Rust, pass the same URI to connect. LanceDB supports these object storage backends: Pass credentials as environment variables (uppercase), or as a storage_options dict at connection or table level (lowercase keys); a table’s storage_options inherit the connection’s and override on a per-key basis. Choosing among these is a tradeoff between latency, scalability, cost and operational complexity, before you even pick a cloud-specific backend: object storage (S3, GCS, Azure Blob) has the highest latency but is the cheapest and scales storage effectively without limit; networked file storage (EFS, Filestore, Azure Files) and third-party stores (MinIO, WekaFS) sit in between; block storage (EBS, Persistent Disk, Managed Disk) and local NVMe are the fastest but tie data to one instance, so scaling means sharding or copying it yourself.
If the endpoint is http:// (common in local development), also set ALLOW_HTTP=true or pass allow_http=True in storage_options.
Consult AWS’s networking requirements for S3 Express before enabling it. Set aws_server_side_encryption to aws:kms and aws_sse_kms_key_id to the key ID or ARN to encrypt at rest with an AWS KMS key. The same options apply at connection or table level, and combine with bucket-level default encryption.
The IAM principal needs kms:Encrypt, kms:Decrypt and kms:GenerateDataKey on the configured KMS key.
Tencent COS and GooseFS build availability. Both are bundled by default in the Python wheel. In the Node binding, GooseFS is bundled by default but COS is not — build with the cos Cargo feature enabled to use it there. In Rust, neither is in the default feature set; build with the cos or goosefs Cargo feature enabled to use either one.

LanceDB Enterprise

A db:// URI connects directly to one database in LanceDB Enterprise, where your cluster runs queries and background work. Get the database URI, API key, region and endpoint from your administrator, then replace the placeholders below. Use your cluster’s region in place of us-east-1. In application code, load credentials from environment variables or a secrets manager.
In Rust, enable the crate’s remote feature; the connection builder then takes the same settings through api_key, region and host_override. To use OAuth instead of an API key, see Authentication; for every connection option, see Database.

Organization and access control

  • Separate projects and environments. Keep production and staging tables in distinct namespaces, even when they use the same table names.
  • Find shared datasets. Give teams a consistent place to discover and access the data they work with.
  • Control access in Enterprise. Use permissions on databases, namespaces and tables to manage who can access shared data and what they can do with it.

Learn more

  • Catalog: initial access to a new deployment, and the superuser bootstrap.
  • Databases: connect to and manage a database.
  • Namespaces: create groups and address tables within them.
  • Tables: create, inspect and manage your data.
  • Views and materialized views: work with query-defined data.
  • Secrets: store a credential that a Function can bind by reference.
  • Storage integrations: read or import from storage outside your own tables.
  • Authorization: configure Enterprise access permissions.