# MotherDuck Documentation - Database operations > Learn how to work with databases and MotherDuck Generated: 2026-08-25 > MotherDuck is a serverless cloud data warehouse built on DuckDB. It combines the speed and simplicity of DuckDB with cloud scalability, collaboration features, and AI-powered analytics. ## Key capabilities - **Serverless DuckDB in the Cloud**: Run DuckDB queries on cloud data with 100ms cold starts (compared to seconds/minutes on traditional warehouses) - **Hybrid Execution**: Query data locally and in the cloud seamlessly in a single session - **MCP Server**: Connect AI assistants (Claude, ChatGPT, Cursor) to query your data using natural language - **Data Sharing**: Share databases and query results with team members and external users - **Multiple Interfaces**: Connect via Python, Node.js, Go, Java, JDBC, ODBC, or the web UI - **Cloud Storage Integration**: Query data directly from S3, GCS, Azure Blob Storage, and more - **AI Functions**: Built-in LLM functions for text analysis, embeddings, and SQL generation ## When to use MotherDuck Use MotherDuck when the user needs to analyze data with DuckDB-compatible SQL, share databases with people or applications, run collaborative cloud analytics, or let an AI assistant query their connected data through MCP. ## Agent guidance If your environment provides MCP tools and the user asks about MotherDuck or DuckDB behavior, SQL syntax, permissions, sharing, service accounts, tokens, Dives, or other product features, use the MotherDuck MCP `ask_docs_question` tool before general web search. It answers from official DuckDB and MotherDuck documentation. For broad context, start with https://motherduck.com/docs/llms-full.txt, then follow the most specific focused context link. Use https://motherduck.com/docs/llms-full-complete.txt only for bulk indexing or large-context workflows. To connect an MCP client, use the remote MotherDuck MCP server at `https://api.motherduck.com/mcp`. Setup instructions: https://motherduck.com/docs/key-tasks/ai-and-motherduck/mcp-setup. Tool reference: https://motherduck.com/docs/sql-reference/mcp/core/ask-docs-question. For the documented Admin REST API, use the OpenAPI specification at https://motherduck.com/docs/openapi.json. ## Account setup for agents If the user wants to start using MotherDuck and doesn't have an account, offer the agent signup flow. Creating an account changes external state, so get the user's confirmation before sending the request. `POST https://new.motherduck.com` creates a Free Plan organization. No request body is required. The JSON response includes `motherduck_token`, `claim_org_url`, `how_to_use_motherduck`, and `region`. Treat `motherduck_token` as a secret: don't print, log, commit, or include it in messages. Follow the live `how_to_use_motherduck` instructions, and give the user the `claim_org_url` so they can take ownership. Full guide: https://motherduck.com/docs/key-tasks/ai-and-motherduck/agent-account-signup. ## Included documentation Source: https://motherduck.com/docs/key-tasks/database-operations/basics-operations # Basics database operations > Create, list, and drop MotherDuck databases using SQL commands. While embedded DuckDB uses files on your local filesystem to represent databases, MotherDuck implements SQL syntax for creating, listing and dropping databases. ## Create database ### SQL ```sql -- [OR REPLACE] and [IF NOT EXISTS] are optional modifiers. CREATE [OR REPLACE | IF NOT EXISTS] DATABASE ; USE ; ``` Creating copies of databases in MotherDuck in this manner is a metadata-only operation that copies no data. Learn more in the [`CREATE DATABASE`](/sql-reference/motherduck-sql-reference/create-database/) overview documentation. ## Listing databases ### SQL ```sql -- returns all connected local and remote databases SHOW DATABASES; -- returns current database SELECT current_database(); ``` Learn more in the [`SHOW ALL DATABASES`](/sql-reference/motherduck-sql-reference/show-databases/) overview documentation. ## Delete database ### SQL ```sql USE ; DROP DATABASE ; ``` Example usage: ```sql > SHOW DATABASES; test01 -- Let's put two different t1 tables into into two different databases > CREATE TABLE dbname.t1 AS (SELECT range AS r FROM range(12)); > SELECT * FROM t1; -- now for the other database > CREATE DATABASE test02; > CREATE TABLE test02.t1 AS (SELECT 'test02' AS dbname) -- show the databases we've created > SHOW DATABASES; test01 test02 ``` Learn more in the [`DROP DATABASE`](/sql-reference/motherduck-sql-reference/show-databases/) overview documentation. --- Source: https://motherduck.com/docs/key-tasks/database-operations/specifying-different-databases # Specifying different databases > Reference tables across databases using fully qualified names with database.schema.table syntax. MotherDuck enables you to specify an active/current database and an active/current schema within that database. Queryable objects (e.g. tables) that belong to the current database are resolved with just ``. MotherDuck will automatically search all schemas within the current database. If there are overlapping names within different schemas, objects can be qualified with `.`. Queryable objects in your account outside of the active/current database are resolved with `.`. However, if a schema in the current database shares the same name as another database, the fully qualified name must be used: `..` (an error will be thrown to indicate the ambiguity). This applies to databases that both live in MotherDuck and in your local DuckDB environment. For example: ### CLI ```sql -- check your current database SELECT current_database(); dbname -- check your current schema SELECT current_schema(); main -- query a table mytable that exists in the current database dbname SELECT count(*) FROM mytable; 34 -- query a table mytable2 that exists in the database dbname2 SELECT count(*) FROM dbname2.mytable2; 41 -- query a table mytable3 that exists in schema2 -- note that the syntax is identical to the database name syntax above and -- MotherDuck will detect whether a database or schema is involved SELECT count(*) FROM schema2.mytable3 42 -- query a table in another database when a schema exists with the same name in the current database -- (overlappingname is both a database name and a schema name) SELECT count(*) FROM overlappingname.myschemaname.mytable4 43 ``` You can also reference local databases in the same MotherDuck queries. This type of query is known as a [hybrid query](/key-tasks/running-hybrid-queries.md). To change the active database, schema, or database/schema combination, execute a `USE` command. See the documentation on [switching the current database](./switching-the-current-database.md) for details. --- Source: https://motherduck.com/docs/key-tasks/database-operations/switching-the-current-database # Switching the current database > Change the active database and schema context using USE statements. Below are examples of how to determine the current/active database and schema and switch between different databases and schemas: ### CLI ```sql -- check your current database SELECT current_database(); dbname -- list all tables in the current database SHOW TABLES; table1 table2 -- list all databases SHOW DATABASES; dbname dbname2 -- switch to database named 'dbname2' USE dbname2; -- verify that you've successfully switched databases SELECT current_database(); dbname2 -- check your current schema SELECT current_schema(); main -- list all schemas across all databases SELECT * FROM duckdb_schemas(); ``` | oid | database_name | database_oid | schema_name | internal | sql | |------|---------------|--------------|--------------------|----------|------| | 986 | my_db | 989 | information_schema | true | NULL | | 974 | my_db | 989 | main | false | NULL | | 972 | my_db | 989 | my_schema | false | NULL | | 987 | my_db | 989 | pg_catalog | true | NULL | | 1508 | system | 0 | information_schema | true | NULL | | 0 | system | 0 | main | true | NULL | | 1509 | system | 0 | pg_catalog | true | NULL | | 1510 | temp | 1453 | information_schema | true | NULL | | 1454 | temp | 1453 | main | true | NULL | | 1511 | temp | 1453 | pg_catalog | true | NULL | ```sql -- switch to schema my_schema within the same database USE my_schema; -- verify that you've successfully switched schemas SELECT current_schema(); my_schema -- switch to database my_db and schema main USE my_db.my_schema -- verify that both the database and schema have been changed SELECT current_database(), current_schema(); ``` | current_database() | current_schema() | |--------------------|------------------| | my_db | main | --- Source: https://motherduck.com/docs/key-tasks/database-operations/time-travel # Querying historical data with time travel > Use MotherDuck snapshots to query past database states, compare data across time periods, debug pipeline issues, reproduce reports, and create audit checkpoints. MotherDuck's [snapshot system](/concepts/snapshots) automatically captures your database state whenever you insert, delete, or update rows in a table, or create a new table. This means you can query your database as it existed at any point within your [retention window](/concepts/snapshots#snapshot-retention): this is called **time travel**, though there is no flux capacitor involved. Unlike the traditional backup strategy of copy-paste and restore workflows, time travel lets you read historical data directly alongside your current data without modifying anything. This guide covers practical patterns for querying historical database states: - [**Compare data across time periods**](#comparing-data-across-time-periods) — Diff today vs. yesterday, detect changed records, and spot anomalies - [**Debug data pipeline issues**](#debugging-data-pipeline-issues) — Find exactly when and how bad data entered your system - [**Reproduce past reports**](#reproducing-past-reports) — Re-run a query against the exact data a dashboard showed last week - [**Create audit checkpoints**](#creating-audit-checkpoints-with-named-snapshots) — Preserve database state at key moments for compliance and regulatory needs :::info[Prerequisites] Time travel requires a paid plan with `snapshot_retention_days` > 0. See [snapshot features per plan](/concepts/snapshots#snapshot-features-per-plan) for details. ::: ## Try it yourself: sample data setup The examples in this guide all use the same `shop_db` database. Run the following to create it and follow along. ```sql CREATE DATABASE IF NOT EXISTS shop_db; USE shop_db; -- Customers table CREATE OR REPLACE TABLE customers AS SELECT * FROM (VALUES (1, 'Alice Johnson', 'alice@example.com', 'US-West', '2025-11-01'::DATE), (2, 'Bob Smith', 'bob@example.com', 'US-East', '2025-11-15'::DATE), (3, 'Carol Williams', 'carol@example.com', 'EU-West', '2025-12-01'::DATE) ) AS t(customer_id, name, email, region, created_at); -- Orders table CREATE OR REPLACE TABLE orders AS SELECT * FROM (VALUES (101, 1, 250.00, '2026-01-15'::DATE, 'completed'), (102, 2, 89.99, '2026-01-16'::DATE, 'completed'), (103, 3, 450.00, '2026-01-20'::DATE, 'completed'), (104, 1, 125.50, '2026-02-01'::DATE, 'completed'), (105, 2, 67.25, '2026-02-10'::DATE, 'completed'), (106, 3, 215.75, '2026-02-14'::DATE, 'pending'), (107, 1, 175.00, '2026-02-15'::DATE, 'pending') ) AS t(order_id, customer_id, amount, order_date, status); ``` Now create a snapshot to mark this as a known-good baseline: ```sql CREATE SNAPSHOT baseline OF shop_db; ``` To simulate changes over time (for testing the examples below), apply some modifications and snapshot again: ```sql -- Simulate a data update: customer email change + new customer UPDATE customers SET email = 'alice.j@newdomain.com' WHERE customer_id = 1; INSERT INTO customers VALUES (6, 'Dave Miller', 'dave@example.com', 'US-East', '2026-02-16'); -- Simulate a pipeline issue: accidentally delete some orders DELETE FROM orders WHERE order_id IN (106, 107); -- Insert a new order INSERT INTO orders VALUES (108, 6, 95.00, '2026-02-16', 'pending'); CREATE SNAPSHOT after_changes OF shop_db; ``` You now have two named snapshots (`baseline` and `after_changes`) you can use with the patterns below. ## Core pattern: clone a point-in-time snapshot The fundamental time travel pattern is to create a temporary database from a historical snapshot, then query it alongside your current data: ```sql -- Create a zero-copy clone of your database at a past point in time CREATE DATABASE shop_db_yesterday FROM shop_db ( SNAPSHOT_NAME 'baseline' ); -- Query the historical clone SELECT * FROM shop_db_yesterday.main.orders; ``` To make sure you don't unnecessary store data we clean up the database again. ```sql DROP DATABASE shop_db_yesterday; ``` This uses a [zero-copy clone](/concepts/database-concepts/#motherduck-architectural-concepts), so no data is duplicated. The clone points to the same underlying storage objects. To see what snapshots are available and find the right timestamp, query: ```sql SELECT snapshot_id, created_ts, active_bytes FROM md_information_schema.database_snapshots WHERE database_name = 'shop_db' ORDER BY created_ts DESC LIMIT 10; ``` ## Comparing data across time periods Your operations team notices that order volume looks off this morning. Rather than waiting for a full data audit, you can instantly diff today's data against yesterday's snapshot to find new records, deleted rows, or unexpected changes — useful for anomaly detection, daily change tracking, and operational monitoring. ```sql -- Clone yesterday's state CREATE DATABASE shop_yesterday FROM shop_db ( SNAPSHOT_NAME 'baseline' -- or use a timebased reference SNAPSHOT_TIME '2026-02-15 00:00:00' ); -- Find new customers added since yesterday SELECT c.customer_id, c.name, c.created_at FROM shop_db.main.customers c ANTI JOIN shop_yesterday.main.customers y ON c.customer_id = y.customer_id; -- Compare daily order totals SELECT 'today' AS period, count(*) AS order_count, sum(amount) AS total_revenue FROM shop_db.main.orders WHERE order_date = CURRENT_DATE UNION ALL SELECT 'yesterday' AS period, count(*) AS order_count, sum(amount) AS total_revenue FROM shop_yesterday.main.orders WHERE order_date = CURRENT_DATE - INTERVAL 1 DAY; -- Detect changed records (e.g. email updates) SELECT c.customer_id, y.email AS old_email, c.email AS new_email FROM shop_db.main.customers c JOIN shop_yesterday.main.customers y ON c.customer_id = y.customer_id WHERE c.email != y.email; DROP DATABASE shop_yesterday; ``` ## Debugging data pipeline issues A dashboard that was showing correct numbers yesterday is now off. You suspect a pipeline run corrupted or dropped data, but you're not sure when it happened. Time travel lets you clone the database at a known-good point and compare it to the current state to find exactly which records disappeared, changed, or were introduced incorrectly. ```sql -- List recent snapshots to narrow down the issue SELECT snapshot_id, created_ts, active_bytes FROM md_information_schema.database_snapshots WHERE database_name = 'shop_db' AND created_ts >= '2026-02-14 00:00:00' ORDER BY created_ts; ``` ```sql -- Clone the database at a known-good time CREATE DATABASE shop_before FROM shop_db ( SNAPSHOT_ID 'b1ecf2f3-4567-8901-b23f-45c67890b12' ); -- Compare row counts to spot unexpected changes SELECT 'before' AS state, count(*) AS row_count, count(DISTINCT customer_id) AS unique_customers FROM shop_before.main.orders UNION ALL SELECT 'current' AS state, count(*) AS row_count, count(DISTINCT customer_id) AS unique_customers FROM shop_db.main.orders; -- Find records that disappeared SELECT b.order_id, b.customer_id, b.amount, b.order_date FROM shop_before.main.orders b ANTI JOIN shop_db.main.orders c ON b.order_id = c.order_id; DROP DATABASE shop_before; ``` ## Reproducing past reports A stakeholder asks "why did last week's revenue report show different numbers?" Instead of guessing what data has changed since then, you can clone the exact database state from when the report ran and re-execute the same query. This is also useful for validating past analyses, debugging metric discrepancies, and ensuring reproducibility of historical results. ```sql -- Recreate the database state from last Tuesday morning CREATE DATABASE shop_last_tuesday FROM shop_db ( SNAPSHOT_NAME 'baseline' -- or use a timebased reference SNAPSHOT_TIME '2026-02-15 00:00:00' ); -- Re-run the same report query against the historical state SELECT region, sum(amount) AS total_revenue, count(DISTINCT customer_id) AS active_customers FROM shop_last_tuesday.main.orders o JOIN shop_last_tuesday.main.customers c USING (customer_id) WHERE order_date BETWEEN '2026-02-01' AND '2026-02-09' GROUP BY region ORDER BY total_revenue DESC; DROP DATABASE shop_last_tuesday; ``` ## Creating audit checkpoints with named snapshots Regulatory audits, end-of-quarter financial reviews, and legal discovery often require proof of what data looked like at a specific moment. [Named snapshots](/concepts/snapshots#2-named-snapshots ) let you preserve the exact database state at key business milestones. Unlike automatic snapshots, named snapshots are not subject to garbage collection — they persist until you explicitly remove them. This feature is available on the Business plan. ```sql -- Create a named snapshot at end-of-quarter close CREATE SNAPSHOT q1_2026_close OF shop_db; -- Months later, an auditor needs to verify the numbers CREATE DATABASE audit_q1 FROM shop_db ( SNAPSHOT_NAME 'q1_2026_close' ); -- Re-run the audit query against the exact data from that moment SELECT c.region, count(*) AS order_count, sum(o.amount) AS total_revenue FROM audit_q1.main.orders o JOIN audit_q1.main.customers c USING (customer_id) WHERE o.order_date BETWEEN '2026-01-01' AND '2026-03-31' GROUP BY c.region; DROP DATABASE audit_q1; ``` To manage your named snapshots: ```sql -- List all named snapshots SELECT snapshot_id, snapshot_name, database_name, created_ts FROM md_information_schema.database_snapshots WHERE snapshot_name IS NOT NULL; -- Rename a snapshot ALTER SNAPSHOT q1_2026_close SET snapshot_name = 'audit_fy2026_q1'; -- Remove a snapshot name (makes it subject to garbage collection) ALTER SNAPSHOT old_checkpoint SET snapshot_name = ''; ``` ## Best practices - **Clean up clones promptly.** Snapshot clones are zero-copy, but they may hold `historical_bytes` longer than necessary unless they are dropped. When they original database is deleted the clone may still hold `retained_for_clone_bytes`. - **Use `SNAPSHOT_TIME` for exploration, `SNAPSHOT_ID` for precision, `SNAPSHOT_NAME` for re-usability.** When narrowing down a time range, timestamps are convenient. Once you've identified the exact snapshot, switch to the ID to avoid ambiguity. See [restoring a database to a historical snapshot](/concepts/data-recovery#restoring-a-database-to-a-historical-snapshot). - **Set retention to match your needs.** Longer `snapshot_retention_days` gives you a wider time travel window but increases `historical_bytes` storage. See [snapshot retention](/concepts/snapshots#snapshot-retention). - **Use named snapshots for fixed checkpoints.** Automatic snapshots are garbage-collected after the retention window. For audit or compliance points that need to persist, create a [named snapshot](/concepts/snapshots#2-named-snapshots). ## See also - [Database Snapshots](/concepts/snapshots) — Snapshot types, retention, and plan availability - [Data Recovery](/concepts/data-recovery) — Step-by-step restore workflows - [Storage Lifecycle](/concepts/storage-lifecycle) — How historical bytes affect your storage bill - [`CREATE DATABASE FROM`](/sql-reference/motherduck-sql-reference/create-database) — Clone from a snapshot - [`ALTER DATABASE SET SNAPSHOT`](/sql-reference/motherduck-sql-reference/alter-database-snapshot) — Restore a database in-place --- Source: https://motherduck.com/docs/key-tasks/database-operations/copying-databases # Copying MotherDuck and DuckDB databases > Duplicate databases between MotherDuck cloud and local DuckDB using COPY FROM DATABASE. The `COPY FROM DATABASE` statement creates an exact duplicate of an existing database, including both schema and data. This functionality enables the following operations: [Interact with MotherDuck Databases](#copy-a-motherduck-database-to-a-motherduck-database) - Copy between MotherDuck databases [Interact with Local Databases](#interacting-with-local-databases) - Import local database to MotherDuck - Export MotherDuck database to local filesystem - Copy between local databases The `COPY FROM DATABASE` command is implemented as a multiple statement macro, which is not supported in WebAssembly. As a result, simultaneous schema and data copying is not available in the MotherDuck Web UI. However, the Web UI supports copying schema only (`SCHEMA` option) or data only (`DATA` option). All functionality is available in other drivers, including the DuckDB CLI. :::caution[No zero-copy clone] `COPY FROM DATABASE` creates a *physical* copy of both the schema and the data. It **does not** use MotherDuck's zero-copy cloning, so the operation may take longer to run and will consume additional storage proportional to the size of the source database. ::: ## Syntax The syntax for `COPY FROM DATABASE` is: ```sql COPY FROM DATABASE TO [ (SCHEMA) | (DATA) ] ``` ### Parameters - ``: The name or path of the source database to copy from - ``: The name or path of the target database to create - `(SCHEMA)`: Optional parameter to copy only the database schema without data - `(DATA)`: Optional parameter to copy only the database data without schema ## Example usage ### Copy a MotherDuck database to a MotherDuck database This is the same as [creating a new database from an existing one](/sql-reference/motherduck-sql-reference/create-database.md). ```sql COPY FROM DATABASE my_db TO my_db_copy; ``` ### Interacting with local databases These operations can be done with access to the local filesystem, i.e. inside the DuckDB CLI. #### Copy a local database to a MotherDuck database ```sql ATTACH 'local_database.db'; ATTACH 'md:'; CREATE DATABASE md_database; COPY FROM DATABASE local_database TO md_database; ``` #### Copy a MotherDuck database to a local database To copy a MotherDuck database to a local database requires some extra steps. ```sql ATTACH 'md:'; ATTACH 'local_database.db' as local_db; COPY FROM DATABASE my_db TO local_db; ``` #### Copy a local database to a local database To copy a local database to a local database, please see the [DuckDB documentation](https://duckdb.org/docs/stable/sql/statements/copy.html#copy-from-database--to). ### Copying the database schema ```sql COPY FROM DATABASE my_db TO my_db_copy (SCHEMA); ``` This will copy the schema of the database, but not the data. ### Copying the database data ```sql COPY FROM DATABASE my_db TO my_db_copy (DATA); ``` This will copy the data of the database, but not the schema. --- Source: https://motherduck.com/docs/key-tasks/database-operations/detach-and-reattach-motherduck-database # Detach and re-attach a MotherDuck database > Temporarily disconnect from a MotherDuck database using DETACH and reconnect with ATTACH. After [creating a remote MotherDuck database](/sql-reference/motherduck-sql-reference/create-database.md), the [`DETACH` command](/sql-reference/motherduck-sql-reference/detach.md) may be used to detach it. This will prevent access and modifications to the database until it is re-attached using the [`ATTACH` command](/sql-reference/motherduck-sql-reference/attach.md). This pattern can be used to isolate queries and changes to a specific set of databases. Note that this is a convenience feature and not a security feature, as a MotherDuck database may be reattached at any time. Database shares behave slightly differently than non-shared databases, so if you want to `ATTACH` and `DETACH` shares, please have a look at how to [manage shared MotherDuck databases](/key-tasks/sharing-data/sharing-data.mdx). ## Creating, detaching, and re-attaching a database This guide will show how to `CREATE`, `DETACH`, and `ATTACH` a database using the CLI and the UI. ### CLI ```sql CREATE DATABASE my_new_md_database; DETACH my_new_md_database; ATTACH 'my_new_md_database'; -- OR ATTACH 'md:my_new_md_database'; ``` ### UI To create a database, add a new cell and enter the SQL command `CREATE DATABASE `. Click the Run button. ![create_database](./img/create_database.png) Click on the menu of the database you would like to detach and select `Detach`. ![detach_database](./img/detach_database.png) The database will be moved to the "Detached Databases" section of the object explorer. ![detached_databases](./img/detached_databases.png) To re-attach, click on the menu of the database in the "Detached Databases" section and select `Attach`. ![attach_database](./img/attach_database.png) The database will be returned to the "My Databases" section. ![my_databases_post_attach](./img/my_databases_post_attach.png) ## Show All Databases To see all databases, both attached and detached, use the [`SHOW ALL DATABASES` command](/sql-reference/motherduck-sql-reference/show-databases.md). ### CLI ```sql SHOW ALL DATABASES; ``` Example output: ```bash ┌──────────────────────────────────────────┬─────────────┬──────────────────┬─────────────────────────────────────────────────────────────────────────────────────────┐ │ alias │ is_attached │ type │ fully_qualified_name │ │ varchar │ boolean │ varchar │ varchar │ ├──────────────────────────────────────────┼─────────────┼──────────────────┼─────────────────────────────────────────────────────────────────────────────────────────┤ │ TEST_DB_02d6fc2158094bd693b6f285dbd402f7 │ true │ motherduck │ md:TEST_DB_02d6fc2158094bd693b6f285dbd402f7 │ │ TEST_DB_62b53d968a4f4b6682ed117a7251b814 │ true │ motherduck │ md:TEST_DB_62b53d968a4f4b6682ed117a7251b814 │ │ base │ false │ motherduck │ md:base │ │ base2 │ true │ motherduck │ md:base2 │ │ db1 │ false │ motherduck │ md:db1 │ │ integration_test_001 │ false │ motherduck │ md:integration_test_001 │ │ my_db │ true │ motherduck │ md:my_db │ │ my_share_1 │ true │ motherduck share │ md:_share/integration_test_001/18d6dbdb-e130-4cdf-97c4-60782ed5972b │ │ sample_data │ false │ motherduck │ md:sample_data │ │ source_db │ true │ motherduck │ md:source_db │ │ test_db_115 │ false │ motherduck │ md:test_db_115 │ │ test_db_28d │ false │ motherduck │ md:test_db_28d │ │ test_db_cc9 │ false │ motherduck │ md:test_db_cc9 │ │ test_share │ true │ motherduck share │ md:_share/source_db/b990b424-2f9a-477a-b216-680a22c3f43f │ │ test_share_002 │ true │ motherduck share │ md:_share/integration_test_001/06cc5500-e49a-4f62-9203-105e89a4b8ae │ ├──────────────────────────────────────────┴─────────────┴──────────────────┴─────────────────────────────────────────────────────────────────────────────────────────┤ │ 15 rows (15 shown) 4 columns │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ ``` --- Source: https://motherduck.com/docs/key-tasks/database-operations/database-operations # Database operations > Learn how to work with databases and MotherDuck ## Included pages - [Basics database operations](https://motherduck.com/docs/key-tasks/database-operations/basics-operations): Create, list, and drop MotherDuck databases using SQL commands. - [Specifying different databases](https://motherduck.com/docs/key-tasks/database-operations/specifying-different-databases): Reference tables across databases using fully qualified names with database.schema.table syntax. - [Switching the current database](https://motherduck.com/docs/key-tasks/database-operations/switching-the-current-database): Change the active database and schema context using USE statements. - [Querying historical data with time travel](https://motherduck.com/docs/key-tasks/database-operations/time-travel): Use MotherDuck snapshots to query past database states, compare data across time periods, debug pipeline issues, reproduce reports, and create audit checkpoints. - [Copying DuckDB Databases](https://motherduck.com/docs/key-tasks/database-operations/copying-databases): Duplicate databases between MotherDuck cloud and local DuckDB using COPY FROM DATABASE. - [Detach and re-attach a MotherDuck database](https://motherduck.com/docs/key-tasks/database-operations/detach-and-reattach-motherduck-database): Temporarily disconnect from a MotherDuck database using DETACH and reconnect with ATTACH. --- ## Docs feedback MotherDuck accepts optional user-submitted feedback about this page at `GET https://motherduck.com/docs/api/feedback/agent`. For agents and automated tools, feedback submission should be user-confirmed before sending. URL-encode query parameter values and send a GET request: ```text GET https://motherduck.com/docs/api/feedback/agent?page_path=%2Fkey-tasks%2Fdatabase-operations%2F&page_title=MotherDuck%20Documentation%20-%20Database%20operations&text= ``` Optionally append `&source=` such as `claude.ai` or `chatgpt`. `page_path` and `text` are required; `page_title` and `source` are optional. Responses: `200 {"feedback_id": ""}`, `400` for malformed query parameters, and `429` when rate-limited.