Point it at Amazon Redshift.
Walk away with insights.
DecisionBox connects to your Amazon Redshift in a few minutes — Serverless or Provisioned, no JDBC driver, no schema migration, no pipeline to build. The agent reads your tables in place, runs read-only queries against them, and surfaces validated insights from what's already in your warehouse.
Three things to know on day one.
Read-only, scoped by IAM policy
The agent connects with a small set of Redshift Data API permissions and the matching credentials lookup — enough to run queries and read the results, and nothing else. The IAM policy attached to the principal is the access boundary.
One setup. Serverless or Provisioned.
Same provider, same config flow, whether you run Redshift Serverless or a Provisioned cluster. Fill in the Workgroup Name for Serverless or the Cluster ID and Database User for Provisioned — the agent picks the right path automatically.
Reads your schemas in place
No tables to refactor, no data pipeline to stand up, no warehouse-side changes. Point DecisionBox at a database and a schema, and the agent picks up your tables on its first run — and re-checks them on every run after. System tables (pg_*, stl_*, svv_*) are skipped automatically.
However your team already authenticates to AWS.
3 options to authenticate. Pick the one that matches how the rest of your AWS stack already works — DecisionBox uses the standard AWS SDK underneath all three, so whatever your security team has approved for other services applies here too.
IAM Role
Pick this when DecisionBox runs inside AWS — EKS with a pod role, EC2 with an instance profile, or anywhere the AWS SDK can find credentials in the environment. Nothing pasted, no keys to rotate.
Access Keys
Pick this when DecisionBox runs outside AWS — on GCP, Azure, on-prem, or a developer laptop. Paste an ACCESS_KEY_ID:SECRET_ACCESS_KEY pair scoped to the Redshift Data API permissions above.
Assume Role
Pick this when DecisionBox lives in one AWS account and Redshift lives in another. Provide the target Role ARN — and an External ID if the role's trust policy requires one — and DecisionBox calls STS to assume the role on every run.
All three flow through the standard AWS SDK. If your security team has already approved how the rest of your stack talks to Redshift, they've already approved DecisionBox.
Connects through the AWS APIs your account already trusts.
DecisionBox doesn't reach Redshift over a JDBC connection. It calls the Redshift Data API — the same AWS service your IAM policies, audit logs, and CloudTrail already cover. There's no driver to install on the agent, no security-group rule to open between two networks, no persistent connection to monitor.
The agent calls ExecuteStatement, polls DescribeStatement until the query finishes, then reads from GetStatementResult. Standard async pattern, standard AWS auth, standard CloudTrail logging.
Open source, and not Redshift-only.
Open source, AGPL v3
Every line of the Redshift integration — the IAM-shaped auth flow, the Data API calls, the SQL the agent writes — is in the public repo. Anyone can read and audit it before turning it on.
View the Redshift provider on GitHubNot locked to Redshift
The same agent runs against any of them. If your warehouse moves, your DecisionBox install moves with it.
Try it on your Redshift, in two minutes.
Clone the repo, run docker compose up, and point it at a Redshift workgroup or cluster. Read-only credentials are all the agent ever needs.