How to Set Up Amazon Redshift with Paradime: A Security-First Guide for dbt™ Teams

Connecting Amazon Redshift to a dbt™ platform shouldn't mean scattering credentials across developer laptops or sharing a single production login over Slack. Paradime gives your team a centralized, security-first path to wire up Redshift for both development and production—with per-user isolation, IAM authentication options, and a clear separation of concerns between your Code IDE and Bolt Scheduler environments.

This guide walks you through every step—from prerequisites and network prep to validating queries in the SQL Scratchpad. Each section is written to be crisp and actionable, following least-privilege principles throughout.

Why Set Up Redshift via Paradime?

Avoid Local Credential Sprawl

When every developer manages their own profiles.yml locally, credentials inevitably leak into dotfiles, chat logs, and unsecured repos. Paradime stores all connection secrets in HashiCorp Vault within a logically separated, single-tenant architecture. Each developer gets an isolated Kubernetes pod—no developer can access another's credentials or file system.

This means:

• Zero local credential files to rotate or accidentally commit.

• Per-user schema and credential isolation enforced at the platform level.

• Admin-only production access—developers never touch prod credentials.

Standardize Dev/Prod Runs with Bolt

Without a centralized scheduler, production dbt™ runs often rely on cron jobs on someone's EC2 instance or a fragile Airflow DAG. Paradime's Bolt Scheduler provides a purpose-built orchestration layer that:

• Uses a dedicated production connection separate from development.

• Supports cron scheduling, event triggers, and SLA alerting out of the box.

• Offers Slack, email, and MS Teams notifications for failures and SLA breaches.

Figure: Paradime centralizes credential management—developers interact through the Code IDE while Bolt handles production runs, both backed by Vault-secured secrets.

Prerequisites

Before creating connections in Paradime, gather the following from your AWS and database teams.

Cluster/Serverless Endpoint Details

Tip: If you're on Redshift Serverless, note that the hostname format differs: my-workgroup.account-id.region.redshift-serverless.amazonaws.com.

Database, Schema, and User/Role Strategy

Plan your schema and user strategy before touching Paradime:

Create the production user in Redshift with least-privilege grants:

For development users, repeat a similar pattern scoped to their individual schema:

Network Access (VPC, Security Groups)

Paradime needs network connectivity to your Redshift cluster. You have two options:

1. Public endpoint — Allowlist Paradime's static IPs in your Redshift cluster's VPC security group on port 5439.

2. AWS PrivateLink — For clusters that must not be exposed to the public internet. Contact support@paradime.io and provide your cluster name, AWS account ID, and region. Paradime will provision the VPC endpoint and share the private endpoint URL.

Figure: Two connectivity paths—public IP allowlisting or AWS PrivateLink for fully private connections.

Create the Redshift Connection in Paradime

Settings → Connections

1. Click Settings in the top menu bar of the Paradime interface.

2. In the left sidebar, click Connections.

3. You'll see two sections: Code IDE (development) and Bolt Schedules (production).

4. Click Add New next to the appropriate section and select Redshift.

Important: Only workspace admins can create connections. Workspace-level fields (host, port, profile name) are set once by the admin. User-level fields (username, password, schema) are set individually by each developer.

Auth Options (User/Pass vs IAM) and Recommendations

Paradime supports two authentication methods for Redshift:

Option A: Username & Password (Simpler setup)

Option B: IAM Authentication (Recommended for production)

When you select IAM, the admin provides a Profile Configuration block instead of individual host/port fields:

For Redshift Serverless with IAM, use environment variables to avoid hardcoding keys:

Security recommendation: Use IAM authentication for production (Bolt) to eliminate long-lived passwords. For development, username/password is acceptable since each developer's credentials are Vault-secured and pod-isolated.

TLS/SSL Settings

Redshift connections in dbt™ use SSL by default—there are no separate SSL toggle fields to configure. Amazon Redshift enforces SSL for connections from most clients. If your cluster's parameter group has require_ssl set to true (recommended), all connections—including from Paradime—will automatically use encrypted transport.

Verify your cluster's SSL enforcement:

Set Up Development (Code IDE)

Per-Developer Schemas

Each developer should build dbt™ objects into their own isolated schema. This prevents collisions and makes it easy to audit who created what.

In your dbt_project.yml, use the target schema variable:

When developer John connects with schema dbt_john, all models materialize into dbt_john (or dbt_john_ if custom schema names are used in model configs).

Figure: Each developer targets their own schema while sharing read-only access to source data.

Default search_path Considerations

Redshift's search_path determines which schema is queried when you reference unqualified table names. By default, it's set to '$user', public.

Key considerations for dbt™ on Redshift:

• dbt™ always uses fully qualified names (schema.table) when building models, so search_path has minimal impact on dbt™ runs.

• However, if you write ad-hoc queries in the SQL Scratchpad or reference macros that use unqualified names, search_path matters.

• Recommendation: Set each developer's search_path to include their dev schema:

This ensures ad-hoc queries in the Scratchpad resolve to the developer's own schema by default.

Set Up Production (Bolt Scheduler)

Prod Schema + Permissions

1. Navigate to Settings → Connections in Paradime.

2. Click Add New next to the Bolt Schedules section.

3. Select Redshift and fill in the production fields:

Reminder: Redshift doesn't automatically grant privileges on newly created schemas. After each dbt™ run that creates new schemas, you may need to re-grant access to downstream consumers:

Consider automating this with a dbt™ on-run-end hook:

Scheduling + Alerting Expectations

Once the connection is saved, create your first Bolt schedule:

1. Navigate to Bolt from the Paradime home screen.

2. Click + New Schedule → + Create New Schedule.

3. Configure the schedule:

Figure: A typical Bolt production schedule lifecycle—trigger, execute, test, and alert.

Validate with SQL Scratchpad

After configuring both environments, use Paradime's SQL Scratchpad to verify everything works. The Scratchpad is a gitignored, temporary environment—perfect for validation queries without affecting your project files.

Open the Scratchpad from the Code IDE → Command Panel → Data Explorer.

Current User/Schema Checks

Run these queries to confirm you're connected with the right identity and schema:

Expected results:

• current_user should return your dev username (e.g., dev_john).

• current_database() should return analytics.

• Your dev schema (e.g., dbt_john) should appear in the schemas list.

Permission Check Query

Verify that your user has the required grants:

Expected results:

If can_create is false for your dev schema, ask your admin to run:

Troubleshooting

Connection Timeouts (Network)

Symptoms: Connection hangs, then fails with a timeout error.

Checklist:

1. Security group rules — Verify that Paradime's IPs are allowlisted on port 5439 in your Redshift cluster's VPC security group. Find Paradime IPs at docs.paradime.io/app-help/developers/ip-restrictions.

2. Cluster status — Confirm your Redshift cluster is in available state (not paused or resizing).

3. PrivateLink — If using AWS PrivateLink, confirm the VPC endpoint is in available status and the endpoint URL matches what Paradime provided.

4. Enhanced VPC routing — If enabled, ensure your VPC route tables allow traffic to the Redshift subnet.

If this times out, the issue is network-level, not credential-level.

Permission Denied Errors

Symptoms: permission denied for schema dbt_prod or permission denied for relation my_table.

Fix:

Common pitfall: Redshift does not support GRANT ... ON FUTURE SCHEMAS. After each dbt™ run that creates new schemas, you must re-grant permissions. Automate this with on-run-end hooks as shown earlier.

Schema Not Found / search_path

Symptoms: schema "dbt_john" does not exist or models materialize in the wrong schema.

Fix:

1. Verify the schema exists:

2. Create it if missing:

3. Check your Paradime connection — Ensure the Schema field in Settings → Connections matches the schema you created in Redshift.

4. Check dbt™ custom schema behavior — If you're using custom schema names in model configs, dbt™ concatenates them: dbt_john_staging instead of just staging. This is expected default behavior. Override it by adding a custom generate_schema_name macro if needed:

This macro writes to clean schema names (e.g., staging) in production while keeping developer-prefixed names (e.g., dbt_john_staging) in development.

Wrapping Up

Setting up Redshift in Paradime is a one-time investment that pays off every day your team avoids credential sprawl, misconfigured local profiles, and ad-hoc production scripts. Here's a quick recap of the security-first principles covered:

For additional details, visit the Paradime Redshift connection docs for development, the Bolt Scheduler environment docs for production, and the dbt™ Redshift permissions reference for the complete list of required grants.