FAQs

​

Why can I only see tables from the public schema?

Table discovery is scoped to the public schema on purpose. When a table is picked for a data source, Adriel lists every table in public for which the connecting database user holds SELECT privilege, and it hides everything else. Tables in other schemas, and tables the user cannot read, do not appear in the list. To report on a table that lives in another schema, expose it in public as a view and bind the view. Because a view behaves like a table to the connector, its columns are discovered and typed the same way. One Adriel data source binds to exactly one table (or view), so a view is also the way to combine several tables into a single reportable object. Full discovery rules are in the Postgres data reference.

​

Do I need to allowlist Adriel’s IP addresses for my database?

Yes. Queries reach the database through Adriel’s database proxy rather than from a rotating set of servers, so the database only needs to accept connections from the proxy’s egress address, 52.79.160.224. That address has to be permitted by the network firewall (or the cloud provider’s security group) and by the host-based rules in pg_hba.conf. When direct exposure is not an option, an SSH tunnel to the database works as well. A read-only role is recommended: the connector only issues SELECT statements, so granting SELECT on the target table (or view) is enough. Step-by-step connection setup lives in How to connect Postgres.

​

Why does my widget show “Unknown” as a breakdown value?

When a column used as a breakdown contains NULL (or empty values), those rows are grouped under the literal label Unknown rather than being dropped. This keeps the group visible instead of silently removing rows from the widget, so an Unknown bucket usually means the underlying column has missing values for those records. Filtering on Unknown matches those same missing rows: a filter value of Unknown also matches IS NULL. To remove the bucket, populate the column in the source database, or filter the widget to the values that should appear.

​

Why are my Postgres numbers not adding up?

The most common cause is a column that looks numeric but is treated as text. Any column whose name ends in _id or ID is forced to text so it behaves as a breakdown rather than a metric, even when its native type is a number. Identifier columns are meant for grouping, not for summing, so placing one in a metric slot will not produce a total. Field roles otherwise follow the column’s native type. Numeric types (integer, decimal, and similar) map to Number and can be summed; dates map to Date; every other type — including boolean, uuid, and text — maps to Text and is combined with string aggregation instead of arithmetic. To count records rather than sum a value, use the built-in Row count field. The full type-mapping and aggregation rules are in the Postgres data reference.

​

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

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

​

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

Widget filters on Postgres 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 available as widget filters, and one data source binds to exactly one table. Both gaps are handled the same way, with a Postgres 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 like a table, keeping the heavier logic in the database runs it closest to the data. For a database that uses a form-driven column pre-filter instead of a view-based approach, see the MongoDB data source.

​

Related