Amazon Redshift
The Redshift connector connects to one database on your cluster. Redshift speaks the Postgres wire protocol, so the connection details look like PostgreSQL — with Redshift's default port and Redshift-specific discovery behavior underneath.
Connection settingsDirect link to Connection settings
| Field | Required | Notes |
|---|---|---|
host | Yes | Your Redshift endpoint hostname (or an IPv4 literal). Schemes, paths, and raw IPv6 literals are rejected. |
port | No | Defaults to 5439. |
database | Yes | The database to discover — one database per connector. |
user | Yes | The user the sync connects as. |
ssl | No | Defaults to true. |
password | Yes | Stored in Supabase Vault; decrypted only in the sync worker and never shown again after saving. |
Testing the connection runs a short, idempotent probe and reports a redacted pass/fail.
What gets discoveredDirect link to What gets discovered
- The connected database, as the catalog database.
- Its schemas (system schemas excluded).
- Base tables and views.
- Columns, with data type and nullability.
Metadata is read from information_schema in deterministic, bounded pages, so large clusters sync with predictable memory use.
Two Redshift-specific caveats:
- Comments are not read. Redshift does not reliably surface table or column comments through
information_schema, so the connector reads none. - Spectrum external tables are not discovered yet. Discovery currently covers the objects
information_schemareports; external tables defined through Redshift Spectrum are a tracked follow-up.
After a passed test, choose the schemas and tables to sync in the scope picker — see the connectors overview.
NetworkDirect link to Network
Connections to private, loopback, or link-local addresses are refused, for literal IPs and for every address your hostname resolves to. Your cluster endpoint must be reachable at a public address; the connector cannot reach a cluster that is only routable inside your VPC.