How to use Claude with Redshift
Connect Claude or ChatGPT to Amazon Redshift: the read-only user to create, the default-privileges gotcha that breaks it a week later, and how the direct MCP server compares to a governed layer.
Redshift is where most AWS shops end up, and it is the warehouse most poorly served by AI tooling. Snowflake has Cortex Analyst. BigQuery has Conversational Analytics. Redshift has a handful of MCP servers and a fragmented set of AWS AI services.
Which is fine, because the connection is not the hard part. Here is how to get your team actually querying Redshift through Claude, starting with the database setup that everything else depends on.

First: create a read-only user
Every option below assumes this, and it is the part worth getting right once.
CREATE USER contextflo_ro PASSWORD '<a strong generated password>';
GRANT USAGE ON SCHEMA analytics TO contextflo_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO contextflo_ro;
The one that bites a week later. 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 Claude 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:
ALTER DEFAULT PRIVILEGES FOR USER dbt_user IN SCHEMA analytics
GRANT SELECT ON TABLES TO contextflo_ro;
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.
Scope this to the schemas you actually want exposed. A curated analytics schema is the right starting point; the raw landing zone usually is not.
Give AI queries their own WLM queue
Ad-hoc questions from an AI assistant have a different profile to your scheduled loads: bursty, unpredictable, occasionally expensive. Putting contextflo_ro in its own WLM query group with a concurrency limit and a query timeout means an exploratory question that scans a year of events cannot slow down your ETL.
This takes ten minutes and is the difference between "we tried AI on the warehouse and it caused problems" and nobody noticing it is there.
If you are on Redshift Serverless, the equivalent lever is the RPU ceiling on the workgroup rather than WLM queues.
Option 1: the Redshift MCP server, direct
AWS publishes an official Redshift MCP server supporting cluster discovery, metadata exploration and read-only query execution. Community alternatives exist on GitHub.
// claude_desktop_config.json
{
"mcpServers": {
"redshift": {
"command": "uvx",
"args": ["awslabs.redshift-mcp-server@latest"],
"env": {
"AWS_PROFILE": "your-profile",
"AWS_REGION": "us-east-1"
}
}
}
}
This gives Claude tools to list clusters, explore schemas and run SQL. For a data engineer poking at a schema they already know, it is genuinely good and you should just use it.
For a team, here is what it does not do:
- No schema context. Claude sees
stg_events_v2and column names, and guesses what they mean. Sometimes it guesses well. - No shared definitions. "Active user" and "MRR" resolve differently depending on how each person phrases the question.
- Per-person setup. Everyone configures their own connection and holds their own AWS credentials.
- No access controls. Anyone with the connection reaches everything the user can see. No way to give marketing campaign tables but not payroll.
- No audit trail. No record of what was asked or what SQL ran.
Those are all team problems. If you are one person, none of them apply.
Option 2: AWS-native (Amazon Q, Bedrock)
AWS has the pieces: Amazon Q for BI, Bedrock for model access, Redshift ML for in-warehouse prediction. What it does not have is a single "ask your Redshift data questions in English" product.
You can assemble one from Bedrock plus Lambda plus the Redshift Data API. That is a real engineering project, and at the end of it you own the context layer, the access controls and the query pipeline as internal software.
Reasonable if you have a platform team and a reason to keep everything in AWS. A multi-week build if you do not.
Option 3: Redshift plus Claude via Contextflo
Contextflo connects with the read-only user you created above, reads the schema plus any source code and docs you point it at, and generates context for every table and column. That context is served to Claude over MCP.
Setup, once, for the whole team:
- Add the connection: host, port, database, and the
contextflo_rocredentials - Pick which schemas and tables to include
- Review the generated context and correct what is wrong
- Invite your team — they connect Claude to Contextflo, not to Redshift
That third step is the one that matters. Generated descriptions get structure right and business meaning wrong often enough that someone who knows the data should read them once. A couple of hours there is what separates a tool people trust from one they abandon after the first bad number.
Side by side
| Redshift MCP (direct) | AWS-native (Q + Bedrock) | Contextflo | |
|---|---|---|---|
| Setup | Minutes, per person | Weeks, custom build | ~15 minutes, once |
| Schema context | None | You build it | Generated, then reviewed |
| Access controls | None | IAM, complex | Per-user table scoping |
| Audit trail | None | CloudWatch raw logs | Every question and query |
| Metric definitions | None | You build it | Defined once, shared |
| Best for | One engineer exploring | Teams with platform capacity | Teams who need it working this week |
Which one
The Redshift MCP server if you are a data engineer who wants Claude against a schema you already understand. Fast, free, and the five gaps above are not your problem.
AWS-native if you have a platform team, a compliance reason to stay inside AWS, and a quarter to spend.
Contextflo if several people need to ask questions and get consistent, controlled answers, and nobody is going to own an internal analytics product.
Free for one user and one data source. Setup takes about 15 minutes.