A governed analytics portal over Snowflake and BigQuery

The BI request that never ends

Sales leadership wants a portal: pipeline by region, revenue by segment, a drill-down into the underlying facts, and the ability to ask a question nobody thought to build a chart for. The data is already in Snowflake and BigQuery. It is modelled, it is clean, it is correct.

And yet the portal takes a quarter, because the warehouse solves exactly one of the four problems. It has the answers. It has policies for who may see which rows and columns — administered by warehouse admins, in warehouse terms, per warehouse. What it does not have is any of that expressed in your application's roles, a spend ceiling on a query one of your users typed, or a surface a regional manager will actually open. An unbounded SELECT * typed at 4pm on a Friday can still bill four figures.

Two read paths, two different guarantees

This is the part most worth understanding before you design the portal, because the two paths differ in exactly one crucial way: whether the platform can safely inject a tenant filter.

Four caps on every query

Warehouse compute is billed by the warehouse. Supero's caps are designed to fail a runaway query loudly rather than quietly scan a terabyte.

• BigQuery additionally enforces maximumBytesBilled, on by default, so an unbounded SELECT * cannot produce a surprise bill even if you never configured a cap. Override per connector with maximum_bytes_billed (0 removes it explicitly).
• ClickHouse: if your role already constrains max_result_rows or max_result_bytes, Supero drops the specific cap the error names and retries once, keeping the other as a backstop — your source-side constraint stays the effective limit instead of the read failing.
• Redshift has no native per-query byte cap and takes no pushed-down statement timeout, so your own LIMIT and narrow filters are doing the work — the 90-second deadline bounds Supero's wait, not Redshift's compute. Filter on partitioned or clustered columns and scope date ranges narrowly.

How to build it on Supero

// Snowflake
{ "plugin": "database", "config": {
    "db_type": "snowflake", "account": "ORG-ACCOUNT", "warehouse": "COMPUTE_WH",
    "database": "ANALYTICS", "schema": "PUBLIC", "role": "READER",
    "username": "SVC_SUPERO", "private_key": "-----BEGIN PRIVATE KEY-----...",
    "query_type": "table", "table_names": ["ORDER_FACTS", "CUSTOMERS"] } }

// BigQuery
{ "plugin": "database", "config": {
    "db_type": "bigquery", "project_id": "my-gcp-project", "dataset": "analytics",
    "location": "US", "service_account_json": { "...": "..." },
    "query_type": "table", "table_names": ["orders"] } }

POLICIES = [
    PolicyDef(role="tenant_admin", default_access="full", rules=[]),

    # Managers: facts and customers, but never the margin columns.
    PolicyDef(role="tenant_user", default_access="none", rules=[
        PolicyRule(entity="order_facts", can_read=True,
                   hidden_fields=["unit_cost", "gross_margin"]),
        PolicyRule(entity="customers",   can_read=True,
                   hidden_fields=["lifetime_discount"]),
    ]),

    PolicyDef(role="viewer", default_access="none", rules=[
        PolicyRule(entity="order_facts", can_read=True,
                   hidden_fields=["unit_cost", "gross_margin"]),
    ]),
]

curl -X POST https://api.supero.dev/api/v1/connectors/CONNECTOR_ID/run_query \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sql": "SELECT region, COUNT(*) AS orders, SUM(amount) AS total FROM order_facts WHERE order_date >= ? GROUP BY region ORDER BY total DESC",
    "params": ["2026-01-01"],
    "row_limit": 200
  }'

What a warehouse connector will not do

• No sync mode — there is no whole-warehouse copy into Supero.
• No live_readwrite, and no reverse-ETL back into the warehouse.
• Writes fail (403/405/409/400 depending on the path). If you need write access to the same system, point a regular database connector at it instead.
• Latency is your warehouse's latency, and repeated reads mean repeated warehouse compute. There is no staleness window — that is the trade.
• run_query returns raw columns with no identity envelope, so it does not feed drill-downs, references or the agent. Use structured reads for those.
• Microsoft Fabric ships for structured live reads, but it speaks T-SQL over TDS and is routed through the SQL Server reader rather than the shared warehouse driver — so the SQL console (run_query) is not available on Fabric.

Time to deliver

When you should just buy a BI tool instead

Be honest about the alternative, because for a lot of teams it is the right one. If what you need is exploration by analysts who already write SQL, dashboards that change weekly, and a semantic layer several teams share, buy the BI tool. It is better at that than this is, and it always will be.

Reach for this instead when the consumers are not analysts. A portal your customers log into, a regional manager who will never open a BI seat, an app that needs warehouse facts alongside its own operational data, an AI agent answering in the asker's own permissions — those are application problems that happen to read from a warehouse, and a BI tool is the wrong shape for all four.

Your warehouse already knows the answers. What it does not have is those answers expressed in your application's roles, a spend ceiling on a query a user typed, an identity per row so a drill-down works, or a UI a regional manager will open.