Contextflo Blog

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.

June 12, 20267 min readVivek Sah

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.

Claude connected to an Amazon Redshift cluster through a context layer

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_v2 and 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_ro credentials
  • 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
SetupMinutes, per personWeeks, custom build~15 minutes, once
Schema contextNoneYou build itGenerated, then reviewed
Access controlsNoneIAM, complexPer-user table scoping
Audit trailNoneCloudWatch raw logsEvery question and query
Metric definitionsNoneYou build itDefined once, shared
Best forOne engineer exploringTeams with platform capacityTeams 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.

Get started for free, or talk to the founder.