Questions and Best Practices for Transferring Database Ownership to a Dedicated Service Account

Hi Greg,

To address your points in order:

Is ownership transfer of a database between accounts in the same org supported?

There's no inherent 'ownership transfer' functionality, but there are two workaround approaches depending on your goal: • Clone for independent work If the new account wants their own writable copy of the database, you can create a share, which the new account then attaches. The new database can be created from an attached share by name or by using the share URL. Here is an example of creating a zero-copy clone of sample_data:


-- attach to sample_data if not already attached
ATTACH IF NOT EXISTS 'md:_share/sample_data_db/9900037d-113c-4c34-be55-841596e3b7a3' AS sample_data;
-- create new db called my_sample_data
CREATE DATABASE my_sample_data FROM sample_data;

• Shared service account Create a service account (SA), move the database to it (using the instructions above), and have all writers authenticate using that SA access token. You can also impersonate this SA through the UI. This lets multiple people write to the same database without tying ownership to any one person's login.

Have we missed an alternative? Is there any way to grant write access to a non-owner account without transferring ownership?

Generally speaking, only the database owner account has write access to the database (single-writer architecture), so the approaches above are the only way to circumvent it.

What happens to existing shares when ownership moves? Do the shares + grants survive, do recipients need to re-ATTACH, and do the share URLs change?

Unfortunately, everything will have to be recreated; the share URLs will change, and recipients would need to reattach.

Is the transfer atomic? Is the DB still readable/writable during it? Rough duration for a database in the tens of GB?

Both depend on the 'transfer' approach you will be using. Zero-copy clone via CREATE DATABASE new_db FROM share is a metadata-only operation - it completes almost instantly regardless of database size. During the copy, the source remains readable and writable, but the operation is not atomic.

Is it reversible (can we transfer ownership back if needed)?

Yes, but in the same way you 'transferred' it originally.

One of the databases is a BYOB DuckLake catalog on Cloudflare R2. Does the new owner need its own R2 storage secret, and does anything about the DuckLake metadata or data paths need to change? (We’ve already learned that shares don’t convey the storage credential — consumers can read catalog metadata fine but 404 on the underlying parquet without their own r2 secret.)

Yes, the new owner will need their own R2 storage secret (CREATE SECRET with their R2 credentials scoped to DuckLake's DATA_PATH). Shares do not convey storage credentials, as you've noted.

However, the standard CREATE DATABASE FROM share zero-copy clone path is designed for MotherDuck native databases and does not natively support DuckLake databases in the same way. For a BYOB DuckLake, the data paths and metadata structure are different, and the share-to-clone workflow won't work. The best way would be to create a new DuckLake on the new SA, and then load the parquet data from the bucket you control (with this function). It's a metadata-only operation, but you will need to do it manually.

We have the database/lake ownership transfer tracked as a feature request internally, and can get back to you when there's a dedicated feature for that!

Would this answer your questions? I'd be happy to elaborate further!

Questions and Best Practices for Transferring Database Ownership to a Dedicated Service Account

2 comments

Questions and Best Practices for Transferring Database Ownership to a Dedicated Service Account

2 comments