FAQs

​

Why does my Snowflake widget stop at 50,000 rows?

Every Snowflake widget query is capped at 50,000 rows, and that cap is fixed — 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 warehouse, so a widget that would otherwise return more rows is truncated to the first 50,000. The reliable way around the cap is to hand Snowflake less to return. Pre-aggregate the data on the Snowflake 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 also keeps every query small, which matters because each load runs live against the warehouse and consumes compute. The full query model is in the Snowflake data reference.

​

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

Field roles follow each column’s native Snowflake type, and the mapping is deliberately narrow: only numeric types (such as NUMBER, INTEGER, DECIMAL, and FLOAT) map to Number and are summed when placed in a metric slot. Every other native type — strings, dates and timestamps, booleans, semi-structured VARIANT / OBJECT / ARRAY, binary, and geography — maps to Text. Placing a Text column in a metric slot does not produce a total. Two behaviors surprise people most often:

• ID columns are not summed. A numeric column whose name ends in _id or ID is treated as an identifier for grouping, not a measure. Instead of a total, it returns a short list of up to five distinct values, with “and more” appended when a group holds additional values.
• Text columns collapse to a distinct-value list. Any non-numeric column aggregates the same way — up to five distinct values rather than arithmetic — so text is best used for grouping rather than summing.

There is also no built-in row-count field on Snowflake, so counting records means adding a count column to a Snowflake view or pre-aggregated table and binding that. The complete type-mapping and aggregation rules are in the Snowflake data reference.

​

Why can’t I break my Snowflake data down by day, week, or month?

Snowflake data sources have no automatic date breakdown. Unlike a marketing connector, the connector does not offer day, week, or month grouping over a date column. A date or timestamp column can still be mapped as the data source’s date field so the widget date-range control filters against it, and it can be used as an ordinary breakdown, but each distinct value becomes its own group rather than being rolled up into a period. To group by a period, derive that period in Snowflake — for example, a view that adds a truncated date column — and use the derived column as a breakdown. Because dates and timestamps surface as Text rather than a dedicated Date type, a purpose-built period column also reads more predictably in the widget. The date-range and breakdown rules are covered in the Snowflake data reference.

​

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

Widget filters on Snowflake data sources use a fixed operator set — EQUAL, IN, LIKE, STARTS_WITH, ENDS_WITH, REGEXP, and EXIST, which can be combined with AND, OR, and NOT. Greater-than and less-than comparisons are not applied inside the warehouse query; when used, they fall back to filtering the returned rows after the fact, which is far less efficient. One Adriel data source also binds to exactly one table or view. Both gaps are handled the same way, with a Snowflake 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 Snowflake runs it closest to the data and keeps each widget query under the row cap. Each data source can also carry an optional connection-level row filter that pre-filters rows before aggregation; see the Snowflake data reference. For the Postgres-family connector this one most closely mirrors, see the PostgreSQL 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 Snowflake 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 in the object. 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 Snowflake data reference.

​

Why does connecting Snowflake require a private key instead of a password?

The Snowflake connector authenticates with key-pair (JWT) authentication only. The connection needs a Snowflake account identifier, a username, and a PEM-formatted private key; password authentication and OAuth are not supported. This is why the connection form asks for a private key rather than a password. The key can be pasted as a single line or across multiple lines — it is normalized to valid PEM format before use. Step-by-step setup lives in How to connect Snowflake.

​

Related