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:
.png){kind=logo}
-- 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!
Unfortunately, that would not be possible at the moment 😔 I can flag it as a feature request, though, would you like me to?
Good luck! If you have any questions in the meantime, feel free to drop them here too 🙂↕️
Hi, that sounds strange indeed! To start off, is there anything different about the two .txt files that ended up empty after import? Are said files definitely non-empty? One other thing to check: are you using relative paths or absolute paths in the import script? Did the script's working directory change between when it worked (18 tables) and when it didn't (2 tables)? One common gotcha with DuckDB is that if a file path doesn't resolve to anything, the import can load zero rows without erroring.
rishabh t. thanks for your patience! We experienced a partial service disruption between 12:50 and 12:59 UTC today, affecting database catalogs of some customers. This may have surfaced as an error attaching new databases or as column does not exist. The disruption has been resolved, and services are fully functional, but please do not hesitate to contact us if you encounter any further issues!
Happy to hear! We experienced a partial service disruption between 12:50 and 12:59 UTC today, affecting database catalogs of some customers. This may have surfaced as an error attaching new databases or as column does not exist. The disruption has been resolved, and services are fully functional, but please do not hesitate to contact us if you face any further issues!
Hi, thanks for the detailed write-up! We're taking a look.