Skip to main content

​
Introduction

Amazon Redshift is AWS’s cloud data warehouse. Customers store analytics, event, and business data in Redshift tables and query it with standard SQL. The Adriel Redshift connector binds one Adriel data source to one Redshift table, discovers that table’s columns from the schema at runtime, and lets those columns be used as metrics and breakdowns in widgets. When a widget loads, the connector auto-generates a SQL statement from the widget configuration, executes it against the cluster, and returns the result. As a database connector, the available fields are not a fixed catalog — they are derived from the schema of the bound table. Data types are mapped from native Redshift types to Adriel field types: numeric columns become metrics, while text, boolean, and date columns can serve as either a metric or a breakdown. Because Redshift is Postgres-derived, schema discovery and type mapping closely follow the PostgreSQL connector, with some Redshift-specific differences in filtering and result aggregation noted throughout this page. To connect this data source, see How to connect Redshift to Adriel.

​
Data refresh strategy

Redshift data is fetched on demand. There is no incremental sync — every dashboard, widget, or report load issues a live query against the bound table, so results always reflect the latest committed data in the cluster. Result cache. To reduce redundant scans, queries run with caching enabled through the shared query proxy: identical SQL issued in quick succession is served from cache rather than re-executed against Redshift. Schema cache. The table’s column list is memoized for 5 minutes per data source (cache key sql-fields-{assetId}, guarded by a distributed lock). New columns added on the Redshift side become visible after the cache refreshes. The connector’s deleteCache() is a no-op — the cache expires on its own TTL.

​
Architecture levels

Cluster (or Redshift Serverless workgroup) → Database → Table. Discovery walks these levels through Redshift’s pg_* / information_schema system tables:
  1. Database — the single database named in the connection.
  2. Tables — every table the connecting user has SELECT privilege on, excluding system schemas.
One Adriel data source binds to one Redshift table. To expose a second table, create a second data source. For Redshift Serverless, the connection points at a workgroup endpoint instead of a cluster endpoint; behavior is otherwise identical.

​
Date range limits

There is no platform-imposed date range limit. Query bounds are set by the widget’s date-range control combined with the date column mapped in Blend Data settings. The end date is incremented by one day so the range filter is inclusive. If a non-date column (for example, a text field whose name contains “name”) is mapped as the date field, the query raises INCORRECT_BLEND_DATA_SETTINGS_FOR_DATE.

​
Query model

Widget queries are auto-generated by the shared SQL query service in the Redshift flavor (SqlFlavor.redshift) and executed through the query proxy against the cluster. Each request produces one SQL statement of the form:
Key rules applied by the query builder:
  • Schema validation. Before execution, the query is validated so that every requested metric and breakdown exists in the bound table’s schema; unknown fields are rejected.
  • LIMIT 1000. Rows are capped at 1,000. Unlike BigQuery, this limit is hardcoded and cannot be raised per data source.
  • Inclusive date range. Date-range filtering compiles to field >= 'from' AND field < 'to', with the to date incremented by one day.
  • Field prefix. Fields are exposed and parsed back with a redshift: prefix.
Queries execute through the shared database proxy rather than a direct HTTP call.
Pre-aggregate for granular dataBecause the 1,000-row cap is fixed, widgets that need more granular data should be backed by a table that is already rolled up on the Redshift side. Pre-aggregate in Redshift and bind the summarized table as the data source. Pairing a mapped date column with tight widget filters keeps each query small and fast.

​
Filters

Widget filters translate into Redshift WHERE conditions using a restricted operator set.

​
Supported filter operators

Only two operators are enabled for widget filters on Redshift data sources:
  • IN
  • LIKE
IN applies to text, date/time, integer, and boolean columns: values are quoted for STRING, DATE, TIMESTAMP, and DATETIME columns, cast numerically for integers, and inserted as-is for booleans. LIKE wraps the value as '%value%' and is valid only on text columns — applying it to a non-text column raises FILTER_UNSUPPORTED. All other operators (EQUAL, GREATER_THAN, LESS_THAN, STARTS_WITH, ENDS_WITH, REGEXP, and the boolean combinators) are disabled and do not appear in the widget filter UI.
Narrower than the PostgreSQL connectorThe PostgreSQL connector exposes the full Postgres operator set. Redshift is intentionally limited to IN and LIKE because it is a data warehouse: these two operators cover the common cases (select specific values, pattern match) while avoiding WHERE clauses that scan large tables. Notably, REGEXP — available on BigQuery — is not supported on Redshift.

​
Data-source pre-filters

Redshift does not expose data-source-level pre-filter modes. The customFilters (free-form WHERE) and filterColumn (form-driven) pre-filter options documented for BigQuery are not available on Redshift. (Inference — based on the absence of these settings on the Redshift connector; confirm.) To narrow the scan before widget filters apply, expose a filtered view on the Redshift side or bind a pre-aggregated table.

​
Date-range filtering

Date-range filtering is applied automatically to the column mapped as the date field in Blend Data settings. The end date is incremented by one day for inclusive-range semantics (see Date range limits).

​
Field type mapping

Redshift has no fixed metric or breakdown catalog. The available fields are the columns of the bound table, resolved at query time from information_schema.columns.
How to read the columnsThe Data type column uses the platform’s ten-value vocabulary: Number, Currency, Percentage, Ratio, Duration, Date, Text, URL, Array, Boolean. The Field role column indicates whether the field can serve as a metric, a breakdown, or both.
Each native Redshift type maps to an Adriel field type as follows. Columns whose type maps to STRING, INTEGER, DATE, DATETIME, TIMESTAMP, or BOOLEAN are eligible to be breakdowns; purely numeric columns (FLOAT / REAL / DOUBLE PRECISION) are metric-only. Float columns are surfaced with a full-precision numeric display type.

​
Adriel-added fields

Unlike BigQuery, the Redshift connector adds no synthetic fields. There is no rowCount metric — only the columns of the bound table are exposed. To count rows, add a count column to a Redshift view or pre-aggregated table.

​
Aggregation defaults

When no explicit aggregation is set on a field, the query builder chooses one based on the Redshift type:
No CAST(... AS STRING) on RedshiftThe single-value collapse (single_or_nothing) intentionally omits the CAST(... AS STRING) wrap that other flavors use — Redshift raises type string does not exist for that cast, so it falls back to MAX() (or BOOL_AND() for booleans). For non-deterministic columns this returns the maximum value rather than failing, so watch for unexpected ordering when a breakdown collapses multiple distinct values.

​
Limitations

Based on the current connector:
  • 1,000-row cap per widget query, hardcoded. Unlike BigQuery, the row limit cannot be raised per data source. For more granular data, pre-aggregate in Redshift and bind the rolled-up table.
  • One table per data source. Multi-table joins are not supported — pre-join into a Redshift view.
  • Filter operator whitelist. Only IN and LIKE are available in widget filters; REGEXP and comparison operators are disabled.
  • LIKE is text-only. Applying LIKE to a non-text column raises FILTER_UNSUPPORTED.
  • No synthetic row-count metric. The rowCount field available on BigQuery is not added for Redshift.
  • 5-minute field-metadata cache. New columns added on the Redshift side become visible only after the field cache refreshes (up to 5 minutes). deleteCache() is a no-op on this connector.
  • No OAuth or token refresh. Authentication uses direct cluster credentials; refreshConnection() is a no-op. If the credentials change on the Redshift side, the connection must be re-entered (see the paired how-to).
  • Network reachability required. The Redshift cluster’s security group must allow inbound traffic from Adriel’s egress IPs on the cluster port (typically 5439); most connection timeouts trace back to this.
  • Date field must be a real date column. Mapping a non-date column (for example, a text field) as the Blend Data date field raises INCORRECT_BLEND_DATA_SETTINGS_FOR_DATE.

​
API references (AWS)

​
See also