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, withprod further split into
a nested search namespace:
Namespace name and path
A namespace’s name is just its own component, such assearch. 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 identifierdatabase.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’sstorage_options.
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.
http:// (common in local development), also set
ALLOW_HTTP=true or pass allow_http=True in storage_options.
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.
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
Adb:// 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.
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.