Skip to main content
Amazon Redshift is a fully managed, petabyte-scale cloud data warehouse from AWS, optimized for fast analytics on structured data. With BonData, you can connect to your Redshift cluster to read, enrich, and act on your warehouse data within Agent workflows.

​
Amazon Redshift Setup

Follow these steps to set up IAM credentials for BonData.

​
Step 1: Create an IAM User

  1. Go to AWS IAM Console
  2. Click Users → Create user
  3. Enter a name (e.g., bondata-redshift)
  4. Click Next → Attach policies directly

​
Step 2: Attach Permissions

Create a policy with these permissions:

​
Step 3: Create Access Keys

  1. Go to your new user → Security credentials
  2. Click Create access key
  3. Select Third-party service → Next
  4. Copy the Access Key ID and Secret Access Key

​
Step 4: Get Cluster Details

  • Cluster Identifier: Found in Redshift console (e.g., my-cluster)
  • AWS Region: The region of your cluster (e.g., us-east-1)
  • Workgroup: For Serverless Redshift only

​
Step 5: Grant Database Permissions

AWS IAM only controls access to the Redshift Data API — it does not grant access to your tables. The Db User you connect as also needs read permissions inside Redshift. For every schema you want to sync, grant the user USAGE on the schema and SELECT on its tables:
Repeat these statements for each schema you plan to sync, and run them as a user allowed to grant on those tables (the table owner or a superuser).
Schema USAGE alone makes tables visible in the picker but not readable. Without SELECT, a table still shows up in the list, but BonData can’t read its columns — so it offers only the synthetic _bondata_row_id primary key and sync will fail. If a table appears with no real columns to choose from, grant SELECT on it to the connecting user.

​
Tables built by dbt (or anything that rebuilds a table)

Grants live on the table object, not its name. If a table is produced by dbt — or any pipeline that recreates it on each run (a table materialization, a full refresh, CREATE TABLE AS, a create-then-swap) — the rebuild drops the old object and creates a new one with no grants. A one-time GRANT SELECT you ran by hand disappears on the very next run and the table becomes unreadable again.
This is the most common cause of a Redshift table that syncs fine at first and then later “loses” its columns. Neither statement above survives a rebuild by another account: GRANT SELECT ON ALL TABLES only affects tables that exist at that moment, and ALTER DEFAULT PRIVILEGES without a FOR USER clause applies only to tables created by the user who ran it — not the dbt/ETL service account that actually creates the table.
Pick one durable fix: 1. Grant from dbt (recommended). Add a grants config so dbt re-applies SELECT every time it rebuilds the table. In the model’s .sql file:
or for every model at once, in dbt_project.yml:
dbt reconciles the object’s grants to match this config after each build, so the permission persists across rebuilds. If BonData connects through a role or group, prefix the grantee: role:bondata_role or group:bondata_group. 2. Redshift scoped permissions. Grant on all current and future tables in the schema, no matter which user creates them — no dbt change required:
3. Default privileges scoped to the dbt user. If you use neither of the above, set default privileges for the account dbt runs as (not the admin), and grant on the existing tables once:

​
Step 6: Enter Credentials

Enter the Access Key ID, Secret Access Key, and cluster details in BonData.

​
Required Fields