LEAST-PRIVILEGE PREREQUISITES

Source discovery reads information_schema.tables; extraction is a plain SELECT of the pruned columns. information_schema is readable by every role and already filters itself to objects the role can see, so no extra metadata grant is needed.

GRANT CONNECT ON DATABASE analytics TO dvt_reader;
GRANT USAGE ON SCHEMA public TO dvt_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dvt_reader;

-- so tomorrow's tables are covered too
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO dvt_reader;

Sling creates and loads the landed table; DVT sends a `drop table if exists … cascade` before a full refresh and `drop table` / `drop view` on retract. CREATE on the schema is enough because the role then owns everything DVT made — dropping is an ownership right, not a grant. TRUNCATE is what a plain `dvt seed` uses.

GRANT CONNECT ON DATABASE analytics TO dvt_target;
GRANT USAGE, CREATE ON SCHEMA analytics TO dvt_target;

-- only if DVT must load into tables it did not create
GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE
  ON ALL TABLES IN SCHEMA analytics TO dvt_target;

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT INSERT, UPDATE, DELETE ON analytics.orders TO dvt_target;

There is no warehouse-side staging area. Rows land through the connection itself; the only staging DVT owns is local Parquet under the project's .dvt/tmp.

Discovery reads information_schema.tables — never SHOW, never SNOWFLAKE.ACCOUNT_USAGE, so no ACCOUNTADMIN-adjacent grant appears. A warehouse is a required connection field even for pure reads, which makes USAGE ON WAREHOUSE a genuine read-tier prerequisite.

GRANT USAGE ON WAREHOUSE dvt_wh TO ROLE dvt_reader;
GRANT USAGE ON DATABASE analytics TO ROLE dvt_reader;
GRANT USAGE ON SCHEMA analytics.raw TO ROLE dvt_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.raw TO ROLE dvt_reader;
GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics.raw TO ROLE dvt_reader;

The role creates the landed table and therefore owns it, which covers the insert, the replace and the retract drop. Nothing at database or account level is required beyond USAGE.

GRANT USAGE ON WAREHOUSE dvt_wh TO ROLE dvt_target;
GRANT USAGE ON DATABASE analytics TO ROLE dvt_target;
GRANT USAGE, CREATE TABLE, CREATE VIEW
  ON SCHEMA analytics.marts TO ROLE dvt_target;

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT INSERT, UPDATE, DELETE, TRUNCATE
  ON TABLE analytics.marts.orders TO ROLE dvt_target;

Bulk loads travel through a Snowflake internal stage. Given CREATE STAGE on the schema, DVT mints its own per-run stage — `create stage if not exists <db>.<schema>.dvt_staging_<12 hex>` — and drops it wholesale when the run ends, so the staging tree is DVT's by construction and leaves nothing behind. Reading and writing the files in that stage is a separate permission from the DDL grant: a role that may create a stage but not write to it will fail at the first file.

-- let DVT mint and drop its own per-run stage
GRANT CREATE STAGE ON SCHEMA analytics.marts TO ROLE dvt_target;

-- if CREATE STAGE is off the table, point DVT at one you own:
GRANT USAGE ON STAGE analytics.marts.dvt_staging TO ROLE dvt_target;
GRANT READ, WRITE ON STAGE analytics.marts.dvt_staging TO ROLE dvt_target;

Without it: The load still runs. DVT logs the missing grant by name, once, and falls back to the loader's shared default stage — which it cannot drop wholesale. Staging residue then accumulates in that shared location instead of disappearing with the run.

Unverified: Read from the loader's source, not measured against a live Snowflake account. The privilege names are Snowflake's own and are verified; what is unproven here is the end-to-end run under exactly this grant set.

Discovery queries the dataset's own INFORMATION_SCHEMA.TABLES, and extraction runs a query — so the identity needs both the data role on the dataset and the right to run jobs in the project.

# dataset-scoped read
gcloud projects add-iam-policy-binding PROJECT \
  --member='serviceAccount:dvt@PROJECT.iam.gserviceaccount.com' \
  --role='roles/bigquery.jobUser'

bq add-iam-policy-binding \
  --member='serviceAccount:dvt@PROJECT.iam.gserviceaccount.com' \
  --role='roles/bigquery.dataViewer' \
  PROJECT:analytics

dataEditor covers creating, replacing and deleting the dataset's tables plus writing their data. Nothing at organisation or folder level is involved.

bq add-iam-policy-binding \
  --member='serviceAccount:dvt@PROJECT.iam.gserviceaccount.com' \
  --role='roles/bigquery.dataEditor' \
  PROJECT:marts

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

DVT never sets a GCS staging location on the BigQuery connection, so the load falls through to whatever the loader does by default. If that turns out to be a GCS-staged load, the identity will also need object create and delete on the bucket it picks.

Unverified: BigQuery is a supported adapter, not one of the engines standing in DVT's live verification suite — so this cell is a reading of the code path, not an observed run. Treat it as: grant the two roles above, run a load, and read the error if there is one.

Discovery reads information_schema.tables — no SVV_* system views, no catalog-admin grant. Redshift's own ACCESS CATALOG system permission is not needed.

GRANT USAGE ON SCHEMA public TO dvt_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dvt_reader;

Same shape as PostgreSQL, with Redshift's explicit DROP privilege: the full-refresh pre-drop is a CASCADE drop and retract drops tables and views.

GRANT USAGE, CREATE ON SCHEMA analytics TO dvt_target;
GRANT SELECT, INSERT, UPDATE, DELETE, DROP, TRUNCATE
  ON ALL TABLES IN SCHEMA analytics TO dvt_target;

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT INSERT, UPDATE, DELETE ON analytics.orders TO dvt_target;

DVT maps Redshift over the PostgreSQL wire protocol and configures no S3 bucket, so loads do not go through COPY. There is no bucket policy to write and no ASSUMEROLE grant to make — and, honestly, no COPY-speed bulk load either: large loads travel over the wire.

Discovery reads the catalog's own information_schema.tables — never the system.* tables, which is what keeps this off metastore-admin territory. USE CATALOG and USE SCHEMA grant no data by themselves; SELECT does.

GRANT USE CATALOG ON CATALOG main TO `dvt_reader`;
GRANT USE SCHEMA ON SCHEMA main.raw TO `dvt_reader`;
GRANT SELECT ON SCHEMA main.raw TO `dvt_reader`;

The loader creates the landed table and merges into it; MODIFY is Unity Catalog's insert/update/delete privilege. Dropping on retract follows from owning what was created.

GRANT USE CATALOG ON CATALOG main TO `dvt_target`;
GRANT USE SCHEMA, CREATE TABLE ON SCHEMA main.marts TO `dvt_target`;
GRANT SELECT, MODIFY ON SCHEMA main.marts TO `dvt_target`;

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT MODIFY ON TABLE main.marts.orders TO `dvt_target`;

The load stages files in a Unity Catalog volume and then runs COPY INTO. Given CREATE VOLUME on the schema, DVT mints its own per-run volume — `create volume if not exists <catalog>.<schema>.dvt_staging_<12 hex>` — and drops it when the run ends. Watch the second half: the file cleanup does not go through SQL at all. It calls the workspace Files API with the connection's token, so that token needs write and delete on the volume's files in addition to the SQL grant. This is the trap — a principal with perfect SQL grants and no file access fails halfway through.

-- the SQL half: let DVT mint and drop its own per-run volume
GRANT CREATE VOLUME ON SCHEMA main.marts TO `dvt_target`;

-- the file half, required either way
GRANT READ VOLUME, WRITE VOLUME ON SCHEMA main.marts TO `dvt_target`;

-- if CREATE VOLUME is off the table, scope the file grants to one volume you own
GRANT READ VOLUME, WRITE VOLUME
  ON VOLUME main.marts.dvt_staging TO `dvt_target`;

Without it: The load still runs. DVT logs the missing grant by name, once, and falls back to the loader's shared default volume — which it cannot drop wholesale, so staging residue accumulates there instead of leaving with the run.

Unverified: Read from the loader's source, not measured against a live workspace. The Unity Catalog privilege names are Databricks' own and are verified; the end-to-end run under exactly this grant set is not.

Discovery reads information_schema.tables, whose rows MySQL already filters down to objects the account has a privilege on — so SELECT is the whole grant.

CREATE USER 'dvt_reader'@'%' IDENTIFIED BY '…';
GRANT SELECT ON analytics.* TO 'dvt_reader'@'%';

The loader creates and replaces the landed table; retract drops tables and views. A plain `dvt seed` truncates rather than dropping, which DELETE covers.

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER
  ON analytics.* TO 'dvt_target'@'%';

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT INSERT, UPDATE, DELETE ON analytics.orders TO 'dvt_target'@'%';

No warehouse-side staging area — rows land through the connection.

MariaDB rides the MySQL adapter and the MySQL wire protocol, so the grant is identical: SELECT, with information_schema filtering itself.

GRANT SELECT ON analytics.* TO 'dvt_reader'@'%';

Same as MySQL.

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER
  ON analytics.* TO 'dvt_target'@'%';

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT INSERT, UPDATE, DELETE ON analytics.orders TO 'dvt_target'@'%';

No warehouse-side staging area.

Discovery reads INFORMATION_SCHEMA.TABLES, and the Explorer's key discovery reads TABLE_CONSTRAINTS and KEY_COLUMN_USAGE. SQL Server shows catalog rows only for objects the principal has a permission on, so db_datareader carries the metadata too.

CREATE USER dvt_reader FOR LOGIN dvt_reader;
ALTER ROLE db_datareader ADD MEMBER dvt_reader;

-- only if your instance has revoked default metadata visibility
GRANT VIEW DEFINITION ON SCHEMA::dbo TO dvt_reader;

ALTER on the schema is what lets the account create and drop objects inside it; db_datawriter covers the loaded rows.

ALTER ROLE db_datareader ADD MEMBER dvt_target;
ALTER ROLE db_datawriter ADD MEMBER dvt_target;
GRANT CREATE TABLE TO dvt_target;
GRANT ALTER, SELECT, INSERT, UPDATE, DELETE
  ON SCHEMA::analytics TO dvt_target;

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT INSERT, UPDATE, DELETE ON analytics.orders TO dvt_target;

No blob staging is configured on this connection — rows land over the connection.

Fabric goes through the same T-SQL surface as SQL Server, and DVT runs the same INFORMATION_SCHEMA discovery against it. The identity is an Entra principal with read access to the warehouse plus SELECT on the objects.

-- once the Entra principal has warehouse access
GRANT SELECT ON SCHEMA::dbo TO [dvt-reader@contoso.com];

Unverified: The T-SQL syntax is Fabric's documented surface, but Fabric is a supported adapter that does not stand in DVT's live verification suite — the item-level Fabric permission that must sit underneath the T-SQL grant is workspace configuration we have not exercised.

The SQL Server shape, with an Entra principal instead of a SQL login.

GRANT CREATE TABLE TO [dvt-target@contoso.com];
GRANT ALTER, SELECT, INSERT, UPDATE, DELETE
  ON SCHEMA::analytics TO [dvt-target@contoso.com];

Unverified: Same reason as the read tier — not exercised in the verification suite.

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

Unverified: Not exercised in the verification suite.

DVT sets no blob staging location on this connection; loads go over the T-SQL connection like SQL Server.

Discovery reads ALL_TABLES and ALL_USERS; the catalog and the Explorer read ALL_TAB_COLUMNS, ALL_CONSTRAINTS and ALL_CONS_COLUMNS. Those views are granted to PUBLIC on a stock database and show only what the account may already see, so the grant list is just the session and the tables.

GRANT CREATE SESSION TO dvt_reader;
GRANT SELECT ON app.customers TO dvt_reader;
GRANT SELECT ON app.orders    TO dvt_reader;

The account creates the landed table in its own schema, so it owns the drop. The quota is the part people forget — without it, creating a segment fails no matter what was granted.

GRANT CREATE SESSION, CREATE TABLE, CREATE VIEW TO dvt_target;
ALTER USER dvt_target QUOTA UNLIMITED ON users;

Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT INSERT, UPDATE, DELETE ON analytics.orders TO dvt_target;

No staging area — rows land through the connection.

DuckDB has no user model. The privilege boundary is the operating system: whoever can read the database file can read every table in it.

DVT creates, replaces and drops tables in the file, so the process needs write on the file and on the directory holding it.

Same boundary — there is nothing finer to grant. If a DuckDB file must be read-only to DVT, make it read-only to the OS user running DVT.

DuckDB is where federation compute already happens; there is nothing to stage.

Discovery reads system.tables and the catalog reads system.columns. ClickHouse filters system-table rows by the account's SHOW privileges, so SELECT plus SHOW is the read tier.

GRANT SELECT ON analytics.* TO dvt_reader;
GRANT SHOW TABLES, SHOW COLUMNS ON analytics.* TO dvt_reader;

The loader creates and replaces the landed table; incremental deltas apply as ALTER UPDATE / ALTER DELETE rather than a MERGE, which is why ALTER is on this list.

GRANT SELECT, INSERT, ALTER, CREATE TABLE, DROP TABLE, TRUNCATE
  ON analytics.* TO dvt_target;

ClickHouse expresses updates and deletes as mutations, so an Explorer edit or a hook lands as an ALTER. Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

GRANT INSERT, ALTER UPDATE, ALTER DELETE ON analytics.orders TO dvt_target;

No object-store staging area — rows land through the connection.

Trino has no portable GRANT: authorization lives in a system access control plugin — the built-in read-only or file-based rules, Ranger, or OPA — evaluated before any connector-level check. Discovery reads information_schema.tables, so the rules must allow SELECT and the metadata reads on the catalogs and schemas you want federated.

To land results, the same rules must permit creating, inserting into and dropping tables in the target catalog and schema. Scope that to one writable catalog and leave the rest read-only.

Whether UPDATE and DELETE exist at all is the connector's decision, not a privilege: several Trino connectors accept inserts but reject row-level updates and deletes outright. The Explorer grid editor and `dvt exec` fail loudly on those, whatever the rules say.

DVT configures no staging area for Trino. Where the underlying connector writes its files, and which object-store credential it uses, is the cluster's configuration.

No user model. Discovery reads sqlite_master and the Explorer reads pragma_table_info — both are inside the file, so file permissions are the whole story.

SQLite writes a journal alongside the database, so the directory must be writable, not just the file.

Same boundary as the target tier.

Nothing to stage.

Athena is the one engine where DVT passes object-store locations explicitly — the data location and the staging location from the connection. A read identity needs the Athena query actions, Glue Data Catalog reads for the metadata, S3 read on the data prefix, and S3 write on the query-results prefix, because Athena writes every result set there.

Unverified: The three permission families are Athena's documented requirements. The exact action list belongs to your workgroup and Glue setup, and Athena does not stand in DVT's live verification suite — so this page names the families rather than publishing a policy document that would be wrong for half of readers.

As a default target Athena creates tables through Glue and writes their files to the data prefix, so the identity needs Glue create/update/delete on that database plus S3 write and delete on the prefix.

Unverified: Same reason — Athena is supported, not verified in the suite.

Row-level updates and deletes depend on the table format underneath. Whatever the statement itself requires on the object it touches — on whichever connection the hook, the exec or the write endpoint names. DVT does not narrow it in code.

Unverified: Not exercised in the verification suite.

The staging location on the connection is a real prefix that Athena writes to on every query. Point it at a prefix DVT owns, with a lifecycle rule, and grant read, write and delete there.

Source discovery is a recursive listing of the prefix, and extraction reads the objects. Scope ListBucket to the prefix with a condition rather than granting it on the whole bucket.

{
  "Effect": "Allow",
  "Action": ["s3:ListBucket"],
  "Resource": "arn:aws:s3:::my-lake",
  "Condition": {"StringLike": {"s3:prefix": ["raw/*"]}}
},
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-lake/raw/*"
}

Landing results in a bucket writes objects under the target prefix. Nothing else on the bucket is touched.

{
  "Effect": "Allow",
  "Action": ["s3:PutObject"],
  "Resource": "arn:aws:s3:::my-lake/marts/*"
}

DVT refuses the DML lane on buckets and filesystems outright — hooks, `dvt exec`, the grid editor and the write endpoints cannot address a bucket connection. A bucket is rewritten, never updated in place.

`dvt retract` deletes the objects it landed. If you never run retract against this connection, leave DeleteObject off entirely.

{
  "Effect": "Allow",
  "Action": ["s3:DeleteObject"],
  "Resource": "arn:aws:s3:::my-lake/marts/*"
}

Unverified: One unverified edge: large uploads may go multipart, which also wants s3:AbortMultipartUpload. Add it if a big landing fails on cleanup.

Listing the prefix and reading the objects — nothing more.

gcloud storage buckets add-iam-policy-binding gs://my-lake \
  --member='serviceAccount:dvt@PROJECT.iam.gserviceaccount.com' \
  --role='roles/storage.objectViewer'

Creating objects under the target prefix.

gcloud storage buckets add-iam-policy-binding gs://my-lake \
  --member='serviceAccount:dvt@PROJECT.iam.gserviceaccount.com' \
  --role='roles/storage.objectCreator'

The DML lane refuses bucket connections.

Deleting landed objects needs storage.objects.delete — roles/storage.objectAdmin carries it, or use a custom role if you would rather not grant the rest.

Listing and reading blobs in the container. The connection takes a storage account key, which is worth reading twice: an account key is an account-wide credential, so container-level scoping is not expressible in the connection itself.

Writing blobs under the target prefix, and deleting them on retract.

The DML lane refuses bucket connections.

Contributor covers the delete that retract performs.

Discovery walks the configured root, so the account needs to list directories under it and read the files. Ordinary POSIX permissions, or the server's own chroot.

Landing results writes files into the configured path.

The DML lane refuses file connections.

`dvt retract` does not delete SFTP objects — it says so and skips. Files DVT landed on an SFTP target are yours to remove, which also means the account never needs delete permission.

The privilege model is the operating system's, evaluated as the user running DVT.

Landing results writes files; the directory must be writable.

The DML lane refuses file connections.

Retract removes the files it landed.