--- title: "Database" sidebarTitle: "Database" description: "Create, describe, list, attach, and drop databases with SQL." icon: database keywords: ["database", "create database", "describe database", "show databases", "drop database", "attach database", "sql"] availability: embedded: unavailable enterprise: available --- A database is the catalog's top-level container: it holds [namespaces](/sql/ddl/namespace), which hold tables, views and other objects. Database statements name one database, independently of the session's current database. Database creation uses the deployment's native catalog and storage settings. ## CREATE DATABASE {#create} ```sql SQL icon="database" CREATE DATABASE analytics CREATE DATABASE IF NOT EXISTS "team/search" ``` Creates a persistent database. Requires `CREATE DATABASE` on the system, and ownership of the database name if it already has an owner. The caller becomes the owner of a new name, following the same rules as the REST API. The result has `operation`, `name`, and `status` columns. Status is `created`, or `already_exists` with `IF NOT EXISTS`. Without that clause, an existing database is an error. Creation never overwrites an existing database. `WITH` options are unsupported on `CREATE DATABASE`. Use `ATTACH DATABASE` [below](#attach) to register a database at an existing location. The `system` database and reserved storage names cannot be created. ## DESCRIBE DATABASE {#describe} ```sql SQL icon="database" DESCRIBE DATABASE analytics DESC DATABASE "team/search" ``` Requires `USAGE` on the database. Returns one row with `name` and `properties`. Properties are the catalog's metadata encoded as a JSON object; a database without metadata returns `{}`, and a database mid `CASCADE` drop reports a transient property marking it as dropping. A missing database is an error. `DESCRIBE DATABASE system` returns empty properties and requires system `USAGE`. ## SHOW DATABASES {#show} ```sql SQL icon="database" SHOW DATABASES ``` Returns a sorted `name` column containing the databases the caller has `USAGE` on, including `system` when permitted. `LIKE` and `WHERE` filters are unsupported. ## ATTACH DATABASE {#attach} ```sql SQL icon="database" ATTACH DATABASE analytics WITH (location = 'analytics') ATTACH DATABASE IF NOT EXISTS analytics WITH (location = 'analytics') ATTACH DATABASE analytics WITH (location = 's3://customer-bucket/raw/analytics/') ATTACH DATABASE analytics WITH (location = 'az://customer-data@customeraccount.blob.core.windows.net/raw/analytics') ``` Registers an existing database at a path relative to the catalog's storage root, or at an external S3, GCS or Azure location, instead of creating a new one. `location` is the only supported option -- naming a storage integration explicitly is refused. For an external location, the deployment automatically binds the most specific [storage integration](/sql/ddl/storage-integration) whose prefix covers it; one must already exist. An Azure location must be account-qualified (`az://container@account.blob.core.windows.net/path`); a bare `az://container/path` is refused. `ATTACH DATABASE` requires the same creation privileges as `CREATE DATABASE`. For an external location, it also requires `USAGE` on the storage integration that binds it, and on that integration's own database and namespace; the integration itself must live in a native, root-backed database under the catalog root. Attaching writes Enterprise's own tracking metadata into the location to bring it under management -- it does not rewrite, move, or re-encode any existing table's data. A relative-path location never accepts an absolute path (`/tmp/db`), a `file://` URI, a Windows path (`C:/db`), a `..` segment, an empty string, or a doubled slash (`sub//db`). An S3 or GCS location must be a concrete prefix, not a bare scheme (`s3://`) on its own. `IF NOT EXISTS` makes the statement a no-op rather than an error when the database is already attached. A quoted name reaches characters a bare identifier cannot, such as `` ATTACH DATABASE "team/search" WITH (location = 'team-search') ``. Removing an externally attached database with `DROP DATABASE` unregisters the attachment and releases its storage-integration reference, without deleting the underlying data. ## DROP DATABASE {#drop} ```sql SQL icon="database" DROP DATABASE analytics DROP DATABASE IF EXISTS analytics RESTRICT DROP DATABASE analytics CASCADE ``` Requires `USAGE` and `OWNERSHIP` on the database. The default, `RESTRICT`, refuses a database that still contains objects. `CASCADE` refuses new objects in the database, revokes every grant in it, and starts a job that drops its contents; deployments without cascade support reject it. An externally attached database cannot be dropped with `CASCADE`. `RESTRICT` returns `operation`, `name`, and `status` columns: `dropped`, or `not_found` with `IF EXISTS` for a missing database. `CASCADE` returns `operation`, `job_id`, and `status` columns: the job's id with `dropping`, or an empty `job_id` with `not_found`. The name stays taken until the job finishes and the dropped storage is cleaned up. The `system` database and federated databases cannot be dropped. `ALTER DATABASE` is unsupported. ## What to read next {#next} CREATE SCHEMA inside an attached database. Creating tables once a database and namespace exist. The SDK equivalent, and connection settings.