> ## Documentation Index > Fetch the complete documentation index at: https://docs.adriel.com/llms.txt > Use this file to discover all available pages before exploring further. # Data reference > Query model, field type mapping, refresh cadence, and limits for the Redshift data source in Adriel. ## 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-sources/o-z/redshift/how-to-connect). ## 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: ```sql theme={null} SELECT , FROM WHERE GROUP BY ORDER BY LIMIT 1000 ``` 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 data** Because 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 connector** The 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 columns** The **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. | Native Redshift type | Adriel field type | Data type | Field role | | ------------------------------------------------- | ----------------- | --------- | --------------------------------------------------------------------------------- | | `INTEGER`, `BIGINT`, `SMALLINT` | `number` | Number | Metric | | `DECIMAL` / `NUMERIC`, `REAL`, `DOUBLE PRECISION` | `number` | Number | Metric | | `VARCHAR`, `CHAR` (character varying) | `string` | Text | Metric or breakdown | | `BOOLEAN` | `boolean` | Boolean | Metric or breakdown | | `DATE`, `TIMESTAMP`, `TIMESTAMPTZ` | `date` | Date | Metric or breakdown; used for date-range filtering when mapped through Blend Data | | `SUPER` | `string` | Text | Semi-structured JSON-like data, serialized to text | | Any other Redshift type | `string` | Text | Metric or breakdown | 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: | Native Redshift type | Default aggregation | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `INTEGER`, `NUMERIC`, `FLOAT`, `REAL`, `DOUBLE PRECISION` | `SUM(x)` | | `STRING` | Single-value collapse — returns the value when only one distinct value exists in the group (`CASE WHEN COUNT(DISTINCT x) = 1 THEN MAX(x) ELSE '' END`). | | `BOOLEAN` | Single-value collapse using `BOOL_AND(x)` when one distinct value exists, otherwise NULL. | | `DATE`, `TIMESTAMP`, and other non-numeric types | Single-value collapse using `MAX(x)` when one distinct value exists, otherwise NULL. | **No `CAST(... AS STRING)` on Redshift** The 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) * [Amazon Redshift documentation](https://docs.aws.amazon.com/redshift/) * [Amazon Redshift SQL reference](https://docs.aws.amazon.com/redshift/latest/dg/cm_chap_SQLCommandRef.html) * [Data types](https://docs.aws.amazon.com/redshift/latest/dg/c_Supported_data_types.html) * [Querying the system catalogs (`information_schema` / `pg_*`)](https://docs.aws.amazon.com/redshift/latest/dg/c_join_PG.html) * [Amazon Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-whatis.html) ## See also * [How to connect Redshift](/data-sources/o-z/redshift/how-to-connect) (paired how-to) * [Google BigQuery data reference](/data-sources/g-n/google-bigquery/data-reference) — alternative cloud data warehouse * [PostgreSQL data reference](/data-sources/o-z/postgres/data-reference) — the Postgres-family SQL connector Redshift most closely mirrors * [MySQL data reference](/data-sources/g-n/mysql/data-reference) — alternative SQL database * [MongoDB data reference](/data-sources/g-n/mongodb/data-reference) — alternative database connector