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.