Redshift.
Connect Orchid to a Redshift cluster or a Redshift Serverless workgroup. Both speak the PostgreSQL wire protocol — Orchid talks to them natively.
Requirements
- A Redshift cluster or Serverless workgroup with a public or VPC-accessible endpoint.
- A database user with
USAGEon the schema andSELECTon tables. - Your machine's IP allowed in the cluster's security group, or a working SSH tunnel.
Connect
- Open Integrations → + Add connection → Redshift.
- Fill in:
- Endpoint — e.g.
my-cluster.abc123.us-east-1.redshift.amazonaws.com - Port —
5439by default - Database — typically
devfor new clusters - User / Password — database credentials
- Endpoint — e.g.
- Click Test connection → save.
Optional settings
IAM auth
For temporary credentials via IAM, pick IAM as the auth method and provide your IAM user / role and a region. Orchid calls GetClusterCredentials (provisioned cluster) or GetCredentials (Serverless) and uses the returned short-lived password.
SSH tunnel
For clusters in private VPCs, set up an EC2 bastion in the same VPC and use the SSH tunnel toggle in the connection settings. Provide bastion host, user, and private key.
AWS PrivateLink
If your security policy disallows public Redshift endpoints, you can use AWS PrivateLink to expose the cluster privately to a VPC endpoint that your VPN reaches. Orchid sees this as a regular hostname — the connection is identical, you just point at the PrivateLink endpoint instead of the public one. PrivateLink only works for the provisioned cluster (not Serverless) and requires the cluster to be on RA3 or DC2 nodes with public access disabled.
Cluster type notes
RA3 vs DC2
Redshift has two provisioned cluster families and one Serverless option:
- RA3 — separates compute from storage. You can pause/resume to save costs, and Redshift Spectrum reads work especially well. Recommended for new clusters.
- DC2 — older fixed-storage architecture. Cheaper for small fixed workloads, but you pay for full uptime even if idle. Slowly being phased out.
- Serverless — pay per RPU-hour, no infrastructure to manage. Great for spiky workloads; cold starts ~10s.
Orchid doesn't care which you're on — the wire protocol is identical. But your cost and latency behaviour differs: a Serverless workgroup that sat idle overnight will feel slower on the first cell of the day than a DC2 cluster that's always warm.
Redshift Spectrum (external tables)
Spectrum lets you query Parquet, ORC, JSON, and CSV directly out of S3 without loading into Redshift first. From Orchid's point of view they're just tables — they appear in the schema browser under their external schema.
-- One-time: register the external schema (run by an admin)
CREATE EXTERNAL SCHEMA spectrum_logs
FROM DATA CATALOG
DATABASE 'spectrum_db'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole'
CREATE EXTERNAL DATABASE IF NOT EXISTS;
-- Then query the external table like any other table
SELECT date_trunc('day', request_time) AS day,
count(*) AS requests
FROM spectrum_logs.access_logs
WHERE request_time > current_date - 7
GROUP BY 1
ORDER BY 1;
Spectrum charges per TB scanned. Same partition-filter discipline applies as BigQuery — always include a filter on the partition column (typically year, month, day).
Redshift can spin up extra clusters for read-heavy workloads automatically (if concurrency scaling is enabled on the workload). Long-running queries from Orchid don't block your team's queries.
Common gotchas
- Timeout when connecting — security group doesn't allow your IP. Add your public IP to the cluster's inbound rules on port 5439, or use the SSH tunnel.
- "FATAL: password authentication failed" — Redshift master user password was reset, you're using the wrong database, or IAM auth credentials expired.
- Slow first query — Serverless workgroups have a cold start of ~10 seconds after inactivity. RA3 nodes resume from pause similarly.
- "ERROR: Spectrum Scan Error" — Spectrum query failed against S3. Check IAM role permissions and that the S3 prefix exists.
- Concurrency limit hit — Redshift has a max of 500 concurrent connections per cluster. If you're hitting that, you have bigger problems than Orchid.
- Sort key not used — your query is slow despite obvious filters. Run
EXPLAINand look at the scan; if it's not range-restricted, your sort key doesn't match the query pattern. Consider adding/changing the sort key.
Example queries
-- Current user / database
SELECT current_user, current_database();
-- Tables in the public schema with size
SELECT "table" AS table_name, size AS megabytes
FROM SVV_TABLE_INFO
WHERE schema = 'public'
ORDER BY size DESC;
Where to go next
For more on writing SQL cells, see SQL cells.