FAQs

​

Why is my Redshift widget limited to 1,000 rows?

Every Redshift widget query is capped at 1,000 rows, and that cap is fixed — unlike some other warehouse connectors, it cannot be raised per data source. The connector auto-generates one SQL statement per widget and appends the limit before the query runs against the cluster, so a widget that would otherwise return more rows is truncated to the first 1,000. The reliable way around the cap is to hand Redshift less to return. Pre-aggregate the data on the Redshift side into a rolled-up table or view and bind that summarized object as the data source, so each group arrives as a single row. Pairing a mapped date column with tight widget filters keeps every query small and fast. The full query model is in the Redshift data reference.

​

Why does my Redshift connection time out or fail to connect?

Most Redshift connection failures trace back to network reachability. Adriel reaches the cluster through its database proxy, so the cluster’s security group has to allow inbound traffic from the proxy’s egress address, 52.79.160.224, on the cluster port — Redshift’s default is 5439. If that address is not permitted by the security group, or if the cluster’s host-based access rules reject it, the connection times out or is refused before any query runs. A few related checks help isolate the cause:

• Confirm the host name resolves and is reachable. A wrong or non-resolving endpoint fails the same way an unreachable cluster does. For Redshift Serverless, use the workgroup endpoint in place of a cluster endpoint.
• Grant the connecting user SELECT on the target table only. The connector issues read queries exclusively, so a read-only role is enough.
• If the bound table is later renamed or dropped, the data source is marked disconnected because the query can no longer find the relation. Recreating or repointing to an existing table restores it.

Step-by-step connection setup lives in How to connect Redshift.

​

Why did my Redshift date breakdown return an error?

Date-range filtering is applied to the column mapped as the date field in Blend Data settings. When the mapped column is not actually a date — most often a text column such as one whose name contains “name” — the query is rejected rather than run against the wrong column, which is why the widget surfaces an error instead of data. This is a guard against mapping a label column where a date column belongs. The fix is to map a genuine date column (a DATE, TIMESTAMP, or TIMESTAMPTZ type) as the date field. If the table has no such column, add one on the Redshift side or expose a view that derives it, then remap the date field. The date-range and Blend Data rules are covered in the Redshift data reference.

​

How do I filter by a range, or combine multiple tables?

Widget filters on Redshift data sources use a deliberately narrow operator set — only IN and LIKE are available. IN works on text, date, integer, and boolean columns; LIKE matches a substring and is valid on text columns only. Greater-than and less-than comparisons and regular-expression matching are not offered as widget filters, and one Adriel data source binds to exactly one table. Both gaps are handled the same way, with a Redshift view:

• For a numeric or date range, define a view that applies the range predicate, then bind the view as the data source.
• For data that spans several tables, pre-join the tables into a view and bind that view.

Because a view is discovered and typed exactly like a table, keeping the heavier logic in Redshift runs it closest to the data. The narrower operator set is intentional for a data warehouse: it keeps widget filters from compiling into scans over very large tables. For the Postgres-family connector with the fuller operator set, see the PostgreSQL data reference.

​

Why are my Redshift numbers or text values not what I expect?

Field roles follow each column’s native Redshift type. Integer and decimal columns map to Number and are summed when placed in a metric slot; date columns map to Date; text, boolean, and other types map to Text. Placing a text column in a metric slot does not produce a total — text and boolean columns are combined with a single-value collapse instead of arithmetic, which returns the value only when a group holds one distinct value and otherwise falls back to the maximum value in the group. That fallback can surface an unexpected value when a breakdown collapses several distinct rows, so text is best used for grouping rather than aggregation. There is also no built-in row-count field on Redshift, so counting records means adding a count column to a Redshift view or pre-aggregated table and binding that. The complete type-mapping and aggregation rules are in the Redshift data reference.

​

Why don’t columns I just added to my table show up?

The connector remembers each table’s column list for a short interval, so a column added on the Redshift side is not visible the instant it is created — it appears once the field-metadata cache next refreshes, and the same refresh drops columns that no longer exist. This affects only which columns are selectable; row values are read live on every widget load and are never cached. For the exact caching interval, see the Redshift data reference.

​

Related