Amazon Redshift

This guide walks you through connecting 4MINDS to Amazon Redshift. 4MINDS supports both provisioned clusters and Redshift Serverless workgroups — they appear together in the same picker. The connection has two layers:

AWS-level authentication — how 4MINDS discovers which Redshift clusters and Serverless workgroups exist in your account. Uses IAM Role Federation (recommended) or Amazon Cognito, both shared with the rest of 4MINDS’s AWS integrations.
Database-level authentication — uses temporary Redshift credentials minted from the same AWS credentials used for discovery. Provisioned clusters use redshift:GetClusterCredentials; Serverless workgroups use redshift-serverless:GetCredentials. No long-lived database password is stored.

This two-layer model lets 4MINDS list your Redshift resources and connect to individual databases with a single set of AWS credentials — no long-lived database passwords to manage or rotate. For the generic IAM Role / Cognito setup (creating the OIDC provider, trust policy, Cognito user pool, etc.), see AWS Integrations. The steps below focus on what’s specific to Redshift.

Provisioned vs. Serverless

	Provisioned cluster	Redshift Serverless
Discovery API	`redshift:DescribeClusters`	`redshift-serverless:ListWorkgroups`
Credential API	`redshift:GetClusterCredentials`	`redshift-serverless:GetCredentials`
Database user	You choose the DB user (see Database User)	Derived automatically from the IAM identity — no DB user to configure
Default port	`5439`	`5439`
Shown in picker as	Node type + node count	`Serverless · <namespace>`

Both types are listed together when you browse Redshift in the import wizard. The difference is handled server-side; you don’t have to pick a mode.

Redshift IAM Permissions Policy

Whichever AWS auth method you use (IAM Role Federation or Cognito), attach this policy to the role. It covers both provisioned and Serverless. If you only use one, you can drop the statements for the other.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RedshiftProvisionedDiscovery",
      "Effect": "Allow",
      "Action": [
        "redshift:DescribeClusters"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftProvisionedCredentials",
      "Effect": "Allow",
      "Action": "redshift:GetClusterCredentials",
      "Resource": [
        "arn:aws:redshift:*:*:dbuser:*/*",
        "arn:aws:redshift:*:*:dbname:*/*"
      ]
    },
    {
      "Sid": "RedshiftServerlessDiscovery",
      "Effect": "Allow",
      "Action": [
        "redshift-serverless:ListWorkgroups"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftServerlessCredentials",
      "Effect": "Allow",
      "Action": "redshift-serverless:GetCredentials",
      "Resource": "*"
    }
  ]
}

Permission	Purpose
`redshift:DescribeClusters`	Lists provisioned clusters in the connected region so 4MINDS can populate the picker (also backs Test Connection)
`redshift:GetClusterCredentials`	Mints short-lived DB credentials for a provisioned cluster + DB user
`redshift-serverless:ListWorkgroups`	Lists Serverless workgroups in the connected region
`redshift-serverless:GetCredentials`	Mints short-lived DB credentials for a Serverless workgroup

Name the policy something memorable like 4MINDS-Redshift-Access — you’ll attach it when creating the IAM role (for Role Federation) or the Cognito authenticated role.

Note: GetClusterCredentials is authorized against both the dbuser: and dbname: resource ARNs. The wildcards above allow all clusters, DB users, and databases. To restrict, narrow the ARNs (e.g., arn:aws:redshift:us-east-1:123456789012:dbuser:my-cluster/fourminds_iam_user).

Least-Privilege: Restricting to Specific Resources

To expose only a subset of your Redshift resources, scope the discovery and credential ARNs:

{
  "Effect": "Allow",
  "Action": "redshift:GetClusterCredentials",
  "Resource": [
    "arn:aws:redshift:us-east-1:123456789012:dbuser:prod-analytics/fourminds_iam_user",
    "arn:aws:redshift:us-east-1:123456789012:dbname:prod-analytics/dev"
  ]
},
{
  "Effect": "Allow",
  "Action": "redshift-serverless:GetCredentials",
  "Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:workgroup/*"
}

Database Access & Grants

The IAM identity 4MINDS assumes must map to a database user that has read access to the tables you want to import.

How 4MINDS decides what you can browse: databases, schemas, and tables are listed through Redshift’s grant-aware system views (SVV_ALL_SCHEMAS, SVV_ALL_TABLES, SVV_ALL_COLUMNS). A schema or table appears only if the resolved DB user has been granted access to it — the user does not need to own it. Grant USAGE on each schema and SELECT on its tables (below) for every schema you want to browse, not just public; a schema the user has no grant on is silently omitted from the picker, and a table without a SELECT grant won’t appear even if its schema does. The same grants make external (Redshift Spectrum) and datashare tables browsable once they’re accessible to the user.

Provisioned clusters — the DB user

For a provisioned cluster, 4MINDS calls GetClusterCredentials with a DB username you configure (see Database User). That user must already exist in the cluster and have SELECT on the target tables. AutoCreate is not used — 4MINDS never creates users in your cluster.

-- run in the target database on your Redshift cluster
CREATE USER fourminds_iam_user PASSWORD DISABLE;
GRANT USAGE ON SCHEMA public TO fourminds_iam_user;
-- standing rule: covers existing AND future tables/views in the schema,
-- regardless of which role creates them
GRANT SELECT FOR TABLES IN SCHEMA public TO fourminds_iam_user;

Older Redshift versions: if GRANT ... FOR TABLES IN SCHEMA (scoped privileges) isn’t available on your cluster, use the equivalent snapshot pattern instead — but remember it only covers objects that exist now, so re-run it (or set default privileges per creating role) as pipelines add tables:
GRANT SELECT ON ALL TABLES IN SCHEMA public TO fourminds_iam_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO fourminds_iam_user;

The IAM policy’s dbuser: ARN must match this username (e.g., .../my-cluster/fourminds_iam_user).

Important — why newly-created tables can go missing (most common cause of “most of my tables don’t show up”):

GRANT SELECT ON ALL TABLES IN SCHEMA is a one-time snapshot. It grants access only to the objects that exist at the moment you run it. Any table, view, or materialized view created afterward is not covered and will silently be omitted from the browser until you re-grant. If a pipeline (e.g. dbt, an ETL job, or a nightly build) keeps adding objects to a schema, you’ll see the older objects but not the newer ones.

ALTER DEFAULT PRIVILEGES only applies to objects created by the role that runs it, going forward. Default privileges are scoped to the creating role. If your tables are created by a different role than the one that ran the ALTER DEFAULT PRIVILEGES statement (very common — e.g. tables created by a dbt_service role while you granted as an admin), the default grant does not apply and new objects stay invisible.

Fix: run ALTER DEFAULT PRIVILEGES as each role that creates objects in the schema. For example, if dbt writes as role dbt_service:
-- run while connected as (or SET SESSION AUTHORIZATION to) the creating role
ALTER DEFAULT PRIVILEGES FOR ROLE dbt_service IN SCHEMA dw_mdl
  GRANT SELECT ON TABLES TO fourminds_iam_user;
To immediately catch up existing objects the read user is still missing, re-run GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO fourminds_iam_user; once now.

Simpler fix — grant a standing rule for the whole schema. Redshift’s scoped-privileges syntax grants SELECT on existing and future tables and views in a schema in a single statement, regardless of which role creates them — so it avoids both the ALL TABLES snapshot gap and the creator-scoped limitation of ALTER DEFAULT PRIVILEGES:
GRANT SELECT FOR TABLES IN SCHEMA dw_mdl TO fourminds_iam_user;
This is the recommended one-shot fix when a customer reports that only some tables in a schema show up: it backfills the objects the read user is missing today and keeps new objects visible as pipelines add them, without having to run ALTER DEFAULT PRIVILEGES per creating role.

Serverless workgroups — IAM-derived user

Redshift Serverless GetCredentials does not accept a DB username — it derives the database user from the IAM identity making the call (returned as IAMR:<role-name> or IAM:<user-name>). To grant it access, create/grant that exact user in the database:

-- <role-name> is the IAM role 4MINDS assumes (Role Federation) or the
-- Cognito authenticated role. Redshift prefixes assumed roles with "IAMR:".
CREATE USER "IAMR:4MINDS-integration-role" PASSWORD DISABLE;
GRANT USAGE ON SCHEMA public TO "IAMR:4MINDS-integration-role";
-- standing rule: covers existing AND future tables/views (see provisioned note above
-- for the ON ALL TABLES + ALTER DEFAULT PRIVILEGES fallback on older Redshift versions)
GRANT SELECT FOR TABLES IN SCHEMA public TO "IAMR:4MINDS-integration-role";

Tip: If you’re unsure of the exact derived username, run a browse in 4MINDS and check the error message — a permission denied failure will name the DB user Redshift resolved, which you can then GRANT to.

Note: For Serverless, GetCredentials auto-creates the IAMR:<role> database user on first use, so the explicit CREATE USER above is optional — granting SELECT to PUBLIC (or to the resolved user after a first browse) is sufficient. Pre-creating the user is only needed if you want to grant privileges before the first connection.

Views (regular, late-binding, materialized)

4MINDS lists and imports views alongside tables — regular views, late-binding views (WITH NO SCHEMA BINDING), and materialized views all appear in the browser and import through the same reflect-and-SELECT path a table uses. Grant behavior (verified on Redshift):

GRANT SELECT FOR TABLES IN SCHEMA <schema> (and the older GRANT SELECT ON ALL TABLES IN SCHEMA <schema>) cover all three view types as well as tables — no separate grant is required for views or materialized views.
The standing-rule FOR TABLES IN SCHEMA grant covers future views and materialized views automatically. If you use the snapshot ON ALL TABLES form instead, pair it with ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES (per creating role) so view-backed datasets stay browsable as they’re added.
Reading a view needs SELECT on the view itself only — the DB user does not need SELECT on the view’s underlying base tables. This holds for regular, late-binding, and materialized views.
Browsing is consistent with preview: if a view appears in the picker, the resolved user can preview and import it. There’s no “shows in the list but fails to import” gap from grants.

If you grant table-by-table instead of using ALL TABLES, remember to include the specific views and materialized views you want browsable — otherwise they’re silently omitted just like an ungranted table:

GRANT SELECT ON <schema>.<view_name>             TO "<db_user>";
GRANT SELECT ON <schema>.<materialized_view_name> TO "<db_user>";

Connection Method 1: IAM Role Federation (Recommended)

Short-lived credentials minted per request through AWS STS — no long-lived AWS keys stored in 4MINDS.

Complete the one-time AWS setup in AWS Integrations → IAM Role Federation (OIDC provider + IAM role with trust policy).
Attach the Redshift IAM policy above to the role (Role Federation and Cognito can share the same role — just attach both service policies to it if you use multiple AWS integrations).
In 4MINDS, open Integrations → Amazon Redshift → click Configure (or Settings if already connected).
Keep the IAM Role tab selected.
Paste your IAM Role ARN (e.g., arn:aws:iam::123456789012:role/4MINDS-integration-role).
Leave the External ID field blank — it is not supported for IAM Role Federation (see AWS Integrations → Verify the Trust Policy).
Enter your AWS Region (e.g., us-east-1) — this must match the region of the Redshift resources you want to browse.
(Provisioned only) Enter a Database user — see Database User. Leave blank to use the default fourminds_iam_user.
Click Test Connection — success shows “Connection successful. Found N Redshift cluster(s).”
Click Save Credentials.

Connection Method 2: Amazon Cognito

Use this if your organization already authenticates against AWS through Cognito User Pools and Identity Pools.

Complete the one-time Cognito setup in AWS Integrations → Amazon Cognito (User Pool, App Client, Identity Pool, authenticated role).
Attach the Redshift IAM policy above to the Cognito authenticated role.
In 4MINDS, open Integrations → Amazon Redshift → click Configure.
Switch to the Cognito tab.
Fill in User Pool ID, App Client ID, App Client Secret (if configured), Identity Pool ID, Username, and Password.
Enter your AWS Region.
(Provisioned only) Enter a Database user if you’re not using the default.
Click Test Connection, then Save Credentials.

Database User

GetClusterCredentials (provisioned clusters only) authenticates as a specific database user. In the settings modal, the Database user field controls which user 4MINDS requests credentials for:

Defaults to fourminds_iam_user if left blank.
The user must already exist in the cluster with SELECT on the tables you want to import (see Database Access & Grants).
The value is stored once with your connection metadata and reused for every browse and import — you don’t re-enter it per request.
Ignored for Serverless — Serverless derives the user from the IAM identity, so this field has no effect on workgroups.

4MINDS Fields

Field	Required	Notes
AWS Region	Yes	Region where your Redshift resources are deployed. Must match the region of your Cognito resources (Cognito method)
IAM Role ARN	IAM Role method	Role with the Redshift IAM policy attached
External ID	No	Not supported for IAM Role Federation — leave blank
Database user	No	Provisioned clusters only. Defaults to `fourminds_iam_user`. Ignored for Serverless
Cognito fields	Cognito method	See AWS Integrations

Importing Data from Redshift

Once connected, open the Datasets page and click Add Source → Amazon Redshift (or pick Redshift from the data source bar inside an existing dataset). The import wizard walks you through the hierarchy: clusters/workgroups → databases → tables.

Step 1 — Pick a Cluster or Workgroup

4MINDS calls redshift:DescribeClusters and redshift-serverless:ListWorkgroups in your configured region and shows everything the role can see. Provisioned clusters show their node type and node count; Serverless workgroups are labeled Serverless with their namespace. Click one to continue.

If the Serverless permissions are missing, workgroups are simply omitted — provisioned clusters still list normally.

Step 2 — Browse Databases

4MINDS mints a short-lived credential (via GetClusterCredentials for a cluster, or GetCredentials for a workgroup), opens a live SQL connection to the endpoint over SSL, and lists databases through the grant-aware SVV_REDSHIFT_DATABASES catalog. This surfaces every database the resolved DB user can access — including datashare (shared) databases provided by other clusters or accounts — not just local databases. System databases (template0, template1, padb_harvest, rdsadmin, and the non-connectable sys:internal) are filtered out.

Step 3 — Select Tables

Click a database to list its tables and views — local, external/Spectrum, and datashare relations the DB user can access, including regular, late-binding, and materialized views. For each relation the browser shows:

Schema-qualified name (e.g., public.customers)
Column count
On-disk size (when available)

Check the tables you want to import and click Add Tables. Selected tables are staged into your dataset alongside files from any other source.

Note: Listing of views (regular, late-binding, and materialized) alongside tables requires the current 4MINDS release. Earlier releases listed base tables only; if views are missing from the browser and you’ve confirmed the grants above, verify you’re on the latest release.

During Import

At import time, 4MINDS runs a bulk fetch on each selected table:

Up to 50,000 rows per table (hard cap — larger tables are truncated and flagged).
Binary columns (BYTEA, VARBINARY, BINARY) are dropped from the export rather than base64-encoded.
Complex types (arrays, structured values) are serialized with json.dumps into a single cell.
Timeout is 120 seconds per table.

Each table lands in your dataset as a UTF-8 CSV with the original column names as headers.

Dataset Sync

Overview

Beyond one-time imports, 4MINDS can keep a Redshift-backed dataset up to date automatically. When you enable Dataset Sync on a dataset built from Redshift tables, 4MINDS re-exports the configured tables on a schedule — no manual re-imports. Unlike file-based sources (S3, Dropbox, Databricks volumes), Redshift is a table warehouse with no cheap per-table “last modified” signal. So Redshift sync follows the same full-snapshot model as BigQuery rather than incremental file diffing: each sync cycle re-exports the whole table (up to the 50,000-row cap) and replaces the previous snapshot. There is no row-level change detection — every run is a fresh point-in-time copy.

How to Set Up Sync

Import one or more Redshift tables into a 4MINDS dataset (using the import wizard above).
On the dataset, toggle Dataset Sync on.
Select a sync frequency (see table below).
From that point on, 4MINDS re-exports each configured table at the chosen interval.

A single sync configuration can span multiple clusters, workgroups, and databases — each table carries its own connection target (endpoint, port, serverless flag, schema), so tables from different Redshift sources can live in the same synced dataset.

Sync Frequencies

Frequency	Interval	Best For
Every minute	1 minute	Rapidly changing tables (Enterprise tier)
Hourly	1 hour	Frequently updated warehouse tables (Teams & Enterprise)
Daily	24 hours	Standard business reporting (All paid tiers)
Weekly	7 days	Slowly changing reference data
Monthly	30 days	Compliance snapshots, archival data

Because every Redshift sync is a full-table re-export, prefer less frequent intervals for large tables to control export cost and RPU/credit usage. Daily or weekly is a good default for warehouse tables.

How It Works Internally

Full snapshot, every cycle: Because Redshift exposes no per-table modification timestamp, the sync manifest records no modified_at for Redshift entries. As a result, the writer treats every configured table as changed on every run and re-downloads a fresh snapshot — the same semantic BigQuery uses. Stable table identity: Each table is tracked by a stable identifier of the form rs-<cluster>-<database>-<schema>-<table> (schema defaults to public). The manifest de-duplicates on this id, so re-running a sync replaces the prior snapshot of a table rather than accumulating duplicates. Export pipeline: On each cycle, for every configured table 4MINDS mints a short-lived Redshift credential (via GetClusterCredentials for a cluster, or GetCredentials for a workgroup), opens an SSL SQL connection, and exports the table to CSV bytes — up to 50,000 rows (the same cap as one-shot import; larger tables are truncated and flagged). Binary columns are dropped and empty tables are skipped. The CSV is uploaded to the user’s dataset storage and processed through the 4MINDS ETL pipeline. Concurrent processing: As with other sources, multiple dataset syncs run in parallel, each with its own isolated database session.

Authentication for Automated Sync

Dataset sync runs in the background with no user present, so 4MINDS replays the stored AWS connection to authenticate each cycle — exactly the same two-layer model used for interactive browsing:

The stored auth method (IAM Role Federation or Cognito) is resolved into fresh temporary AWS credentials for the run (STS AssumeRoleWithWebIdentity, or Cognito GetCredentialsForIdentity).
Those credentials mint a fresh temporary Redshift credential per table (GetClusterCredentials / GetCredentials).

No long-lived database password is ever stored. The IAM role (or Cognito authenticated role) must retain the Redshift IAM policy, and the resolved DB user must keep SELECT on the synced tables (see Database Access & Grants) — a revoked grant surfaces as a skipped table in the sync logs.

Networking Requirements

Redshift clusters and Serverless workgroups live inside a VPC. Only the 4MINDS backend opens SQL connections to Redshift — the browser app (app.4minds.ai) never connects to your database directly, so you only need to allow the backend’s egress IP. There is no frontend IP to allowlist. For 4MINDS to open a SQL connection, the endpoint must be reachable from the backend’s outbound network:

Allow the 4MINDS backend egress IP on the Redshift port (default 5439):
Environment Backend hostname Egress IP to allowlist
Production api.4minds.ai 20.7.240.218/32
Add it as an inbound rule on the security group attached to your cluster or Serverless workgroup. AWS CLI:
aws ec2 authorize-security-group-ingress \ --group-id <your-redshift-security-group-id> \ --protocol tcp --port 5439 \ --cidr 20.7.240.218/32
Or in the console: EC2 → Security Groups → your Redshift SG → Inbound rules → Edit inbound rules → Add rule, then set Type = Custom TCP, Port range = 5439, Source = 20.7.240.218/32.
Publicly accessible = Yes is the simplest path for temporary testing; for production, prefer a VPC peering / PrivateLink setup with 4MINDS support.
SSL — All connections use SSL (sslmode=require), as required for temporary-credential auth.

Environment	Backend hostname	Egress IP to allowlist
Production	`api.4minds.ai`	`20.7.240.218/32`

Private cluster behind a load balancer (Connection host override)

Endpoint discovery (redshift:DescribeClusters for a provisioned cluster, redshift-serverless:GetWorkgroup for a Serverless workgroup) returns the source’s internal endpoint. If your cluster or workgroup can’t be made publicly accessible (for example, its VPC has no internet gateway) but you expose a reachable path in front of it — such as a Network Load Balancer (NLB) — that internal endpoint won’t resolve or connect from the 4MINDS backend, and Test/browse will time out. For this case, set the optional Connection host field in the Redshift connection settings to your reachable hostname (e.g. my-cluster-nlb.elb.us-west-2.amazonaws.com). 4MINDS then opens the SQL connection to that host instead of the discovered endpoint, while still minting temporary IAM credentials against your Cluster identifier (provisioned) or Workgroup (Serverless) — so IAM auth is unchanged. This works the same way for provisioned clusters and Serverless workgroups. Requirements when using the override:

The host must forward TCP 5439 to your cluster or workgroup and present its certificate (SSL is still required). A Network Load Balancer with a TCP listener passes the TLS connection straight through, so the source’s own certificate reaches the backend.
The Cluster identifier / Workgroup, Region, and Database user must still match the real source so credential minting (GetClusterCredentials for a cluster, GetCredentials for a workgroup) succeeds.
The 4MINDS backend egress IP (20.7.240.218/32) must be allowed to reach the override host on port 5439.
One override applies per connection; it’s intended for a single private cluster or workgroup reached through a fixed hostname.

Note: If a connection still times out after allowlisting the IP above, the backend egress IP may have changed — contact 4MINDS support to confirm the current address before widening your rules.

If the SQL connection times out, the browser shows:

“Connection timed out. The backend may not be able to reach the Redshift endpoint — check VPC / security group rules (inbound port open from the backend’s network).”

Security Model

Credential	Where it lives	How long
AWS IAM Role ARN / Cognito config	4MINDS database (encrypted metadata)	Until you disconnect
Temporary AWS credentials (STS)	Request memory only	~1 hour, minted per call
Redshift DB credentials (`Get(Cluster)Credentials`)	Request memory only	~1 hour, generated per call

No database passwords are stored or transmitted. Each SQL operation mints a short-lived credential from the existing AWS credentials, opens a short-lived SQLAlchemy engine over SSL, runs one query, and disposes of the engine before returning.

Testing Your Connection

After saving credentials, the Test Connection button:

Resolves your auth method → AWS credentials (via STS AssumeRoleWithWebIdentity for Role Federation, or Cognito GetCredentialsForIdentity for Cognito).
Calls redshift:DescribeClusters with a 15-second timeout.
Returns “Connection successful. Found N Redshift cluster(s).” on success.

Database-level authentication is tested when you browse a cluster or workgroup in the import wizard — it uses the same AWS credentials to mint a temporary credential and verify SQL connectivity.

Troubleshooting

Issue	Solution
`AccessDenied` on Test Connection	The IAM policy isn’t attached to the role, or is missing `redshift:DescribeClusters`
Serverless workgroups don’t appear	The role is missing `redshift-serverless:ListWorkgroups`, or there are no workgroups in that region
`Invalid Access Key ID` / `Invalid Secret Access Key`	Wrong static credentials (only relevant if using legacy access-keys auth)
`Unrecognized client`	Wrong AWS region, or Redshift isn’t enabled in that region
`Could not resolve Redshift endpoint hostname`	The endpoint in the list is wrong, or DNS can’t resolve it from the backend
`Connection timed out` (SQL step)	Security group doesn’t allow inbound port `5439` from the 4MINDS backend egress IP (`20.7.240.218/32`) — see Networking Requirements
`Connection refused`	Port `5439` isn’t open on the security group, or the endpoint isn’t reachable and there’s no peering
`Connection timed out` on a private cluster or workgroup fronted by an NLB	The discovered endpoint is internal-only. Set the Connection host override to your reachable hostname — see Private cluster behind a load balancer
`Authentication failed`	The IAM policy is missing `redshift:GetClusterCredentials` / `redshift-serverless:GetCredentials`, or the resolved DB user lacks a login/grant. See Database Access & Grants
`permission denied for relation ...`	The DB user exists but lacks `SELECT` on the table — run the `GRANT` statements in Database Access & Grants
`SSL error connecting to Redshift`	Temporary-credential auth requires SSL — AWS-managed certificates work out of the box
Tables, views, or schemas are missing from the browser	4MINDS lists only what the resolved DB user can see via Redshift’s grant-aware `SVV_ALL_` catalog views. Grant `USAGE` on the schema and* `SELECT` on its tables/views — for every schema you want to browse, not just `public`. `SELECT ON ALL TABLES IN SCHEMA` also covers views and materialized views; if you granted table-by-table, add the specific views too. See Database Access & Grants

Debugging missing tables or schemas

4MINDS populates the picker from Redshift’s grant-aware SVV_ALL_* catalog views, so an object appears only if the DB user 4MINDS connects as has been granted access to it. When a customer connects successfully but sees fewer schemas or tables than expected, work through these checks as the same DB user 4MINDS connects with (fourminds_iam_user unless configured otherwise), in Redshift Query Editor v2, DBeaver, or psql. Step 1 — Confirm the user and database.

SELECT current_database(), current_user;

current_user should be the configured DB user, and current_database() the database the connection points at. A wrong user or database alone explains missing objects. Step 2 — See what this user can see in the schema, by object type. This is what the picker shows:

SELECT schema_name, table_type, count(*) AS object_count
FROM svv_all_tables
WHERE database_name = current_database()
  AND schema_name = 'dw_mdl'
GROUP BY schema_name, table_type
ORDER BY table_type;

Step 3 — Compare against the true object count (run as a superuser or the schema owner). If this privileged total is much larger than Step 2, the gap is grants:

SELECT c.relkind,            -- r = table, v = view, m = materialized view, f = external
       count(*) AS object_count
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'dw_mdl'
  AND c.relkind IN ('r','v','m','f')
GROUP BY c.relkind
ORDER BY c.relkind;

Fix a grants gap with the standing-rule grant (covers existing and future tables and views):

GRANT USAGE ON SCHEMA dw_mdl TO fourminds_iam_user;
GRANT SELECT FOR TABLES IN SCHEMA dw_mdl TO fourminds_iam_user;

Step 4 — Rule out cross-database scoping. Our table query is scoped to current_database(), so objects that resolve under a different database name (cross-database references, datashare-provided databases, or an external Glue/awsdatacatalog catalog) won’t appear:

-- what the picker sees:
SELECT count(*) FROM svv_all_tables
WHERE database_name = current_database() AND schema_name = 'dw_mdl';

-- same schema across ANY database_name:
SELECT count(*) FROM svv_all_tables
WHERE schema_name = 'dw_mdl';

If the second count is larger, some objects live under a different database name — point the connection at that database, or contact 4MINDS support with the datashare / external-schema details.

Whole schema missing vs. some tables missing: a schema that’s entirely absent from the picker means the user lacks USAGE on it (svv_all_schemas only returns schemas the user can enter). A schema that shows but is missing some tables is a SELECT gap — most often the ALL TABLES snapshot going stale as pipelines add objects. See Database Access & Grants.

Disconnecting

To remove the Redshift integration:

Open Integrations → Amazon Redshift → click Settings.
Click Disconnect.

This deactivates the stored AWS connection metadata on 4MINDS. Your AWS resources (IAM roles, OIDC providers, Cognito pools, policies, and Redshift DB users) are untouched — delete them in the AWS Console if they’re no longer needed.

Intro

Getting Started with 4Minds

Marketplace

4Minds Features

What's New in 4Minds

Key Terms and Concepts in 4Minds

Developer Tools

Amazon Redshift

Provisioned vs. Serverless

Redshift IAM Permissions Policy

Least-Privilege: Restricting to Specific Resources

Database Access & Grants

Provisioned clusters — the DB user

Serverless workgroups — IAM-derived user

Views (regular, late-binding, materialized)

Connection Method 1: IAM Role Federation (Recommended)

Connection Method 2: Amazon Cognito

Database User

4MINDS Fields

Importing Data from Redshift

Step 1 — Pick a Cluster or Workgroup

Step 2 — Browse Databases

Step 3 — Select Tables

During Import

Dataset Sync

Overview

How to Set Up Sync

Sync Frequencies

How It Works Internally

Authentication for Automated Sync

Networking Requirements

Private cluster behind a load balancer (Connection host override)

Security Model

Testing Your Connection

Troubleshooting

Debugging missing tables or schemas

Disconnecting

​Provisioned vs. Serverless

​Redshift IAM Permissions Policy

​Least-Privilege: Restricting to Specific Resources

​Database Access & Grants

​Provisioned clusters — the DB user

​Serverless workgroups — IAM-derived user

​Views (regular, late-binding, materialized)

​Connection Method 1: IAM Role Federation (Recommended)

​Connection Method 2: Amazon Cognito

​Database User

​4MINDS Fields

​Importing Data from Redshift

​Step 1 — Pick a Cluster or Workgroup

​Step 2 — Browse Databases

​Step 3 — Select Tables

​During Import

​Dataset Sync

​Overview

​How to Set Up Sync

​Sync Frequencies

​How It Works Internally

​Authentication for Automated Sync

​Networking Requirements

​Private cluster behind a load balancer (Connection host override)

​Security Model

​Testing Your Connection

​Troubleshooting

​Debugging missing tables or schemas

​Disconnecting

Provisioned vs. Serverless

Redshift IAM Permissions Policy

Least-Privilege: Restricting to Specific Resources

Database Access & Grants

Provisioned clusters — the DB user

Serverless workgroups — IAM-derived user

Views (regular, late-binding, materialized)

Connection Method 1: IAM Role Federation (Recommended)

Connection Method 2: Amazon Cognito

Database User

4MINDS Fields

Importing Data from Redshift

Step 1 — Pick a Cluster or Workgroup

Step 2 — Browse Databases

Step 3 — Select Tables

During Import

Dataset Sync

Overview

How to Set Up Sync

Sync Frequencies

How It Works Internally

Authentication for Automated Sync

Networking Requirements

Private cluster behind a load balancer (Connection host override)

Security Model

Testing Your Connection

Troubleshooting

Debugging missing tables or schemas

Disconnecting