Connect Amazon Redshift to Contextflo

Create a read-only Redshift user, make your cluster reachable, and connect to Contextflo

Last updated: 8/19/2026

Connect your Amazon Redshift cluster to Contextflo with a dedicated read-only user. About 10 minutes. You create a read-only user, make sure Contextflo can reach your cluster, and enter the connection details. You never share your admin credentials, and the user you create can only read the schemas you choose. Works with both provisioned clusters and Redshift Serverless.

Prerequisites

  • Admin access to your Redshift cluster or workgroup
  • The schema (or schemas) you want to expose
  • Ability to edit the cluster's VPC security group

Step 1: Create a read-only user

Run this as an admin in your SQL client or the Redshift Query Editor v2. Update the password and schema before running.

Loading code sample...
  • Replace analytics with the schema (or schemas) you want to expose. It is SELECT-only, so Contextflo can never modify your data. A curated analytics schema is the right starting point; the raw landing zone usually is not.

GRANT SELECT ON ALL TABLES covers tables that exist right now. Anything created afterwards is invisible, and the symptom is a table that "does not exist" according to your LLM while sitting plainly in the console.

The fix is default privileges, but in Redshift these are scoped to the user who creates the object, so you have to name that user:

Loading code sample...

Run one of these per user or role that creates tables in the schema. If your dbt runs execute as dbt_user, granting defaults for yourself does nothing for the tables dbt builds.

Give AI queries their own WLM queue (optional)

Ad-hoc questions from an AI assistant are bursty and occasionally expensive. Putting contextflo_readonly in its own WLM query group with a concurrency limit and a query timeout means an exploratory question that scans a year of events can't slow down your ETL. On Redshift Serverless, the equivalent lever is the RPU ceiling on the workgroup.

Step 2: Make your cluster reachable

Contextflo connects from its servers, so your cluster has to be reachable. Pick one:

Option A - public endpoint (simplest)

  1. Turn on Publicly accessible:
    • Provisioned cluster: cluster Properties → Network and security.
    • Serverless: Workgroup configuration → Network and security → Edit.
  2. Add an inbound rule to the cluster's VPC security group: Type Redshift (TCP 5439), Source = Contextflo's connection IPs (Contextflo provides these).

Two things that trip people up:

  • "Publicly accessible" on its own is not enough. It only gives the cluster a routable address; the security group still decides who's allowed in. You need both.
  • The default VPC security group won't work as-is. Its one rule says "All traffic," but the source is the security group itself, so it only allows traffic from inside your VPC. You must add an explicit 5439 rule for Contextflo's IPs.

Option B - private cluster via SSH bastion

If you can't expose the cluster publicly, Contextflo can connect through an SSH bastion host in your VPC. The Redshift connection form has fields for the bastion host, port, and username. Coordinate the bastion details and key with the Contextflo team.

Connection Details for Contextflo

In Contextflo, add an Amazon Redshift connection under Data Sources and provide:

  • Connection Name: A friendly name (e.g., "Production Redshift")
  • Host: Everything before :5439 (Provisioned: Clusters; Serverless: Workgroups → General information), e.g. cluster.region.redshift.amazonaws.com
  • Port: 5439 (default)
  • Database: Your database name
  • Username: contextflo_readonly
  • Password: The password you set in the script
  • SSL: Enable if required
  • SSH bastion (Option B only): bastion host, port, and username

Click Test Connection, then save. You then choose exactly which tables to expose, every query runs as this read-only user, and each one is logged.

Security Notes

  • Read-only access: This setup only grants SELECT permissions. Contextflo cannot modify or delete your data.
  • Encrypted storage: Your credentials are encrypted at rest.
  • Scoped exposure: Grant only the schemas you actually want queried.

Troubleshooting

Cannot connect / timeout

  • Confirm both Publicly accessible is on and the security group has an explicit inbound 5439 rule for Contextflo's IPs
  • Verify the host (everything before :5439) and port

A table "does not exist" but is in the console

  • The table was created after the initial grant. Apply the ALTER DEFAULT PRIVILEGES FOR USER ... line for the user that creates tables in that schema.

Next Steps