Data sources, connectors & refresh
How this is scored
Which data the product can reach and how it stays current: native connectors to databases and warehouses (PostgreSQL, MySQL, SQL Server, BigQuery, Snowflake), to business applications (accounting, ERP, CRM, shop, help desk, ad platforms) and to files and spreadsheets (Excel, CSV, Google Sheets), live queries versus imported extracts, scheduled and incremental refresh with its minimum interval, joining data from several sources, light data preparation, access to databases behind a firewall (gateway, SSH tunnel, IP allow-list), and a generic REST or custom connector for what is not listed.
0 — Not a reporting product, or data can only be typed or pasted in by hand.
3 — Spreadsheet and file uploads plus a handful of named connectors; refresh schedules, live queries and blending sources are basic or not described.
5 — A published connector list covering the common databases, warehouses, spreadsheets and several named business applications, scheduled refresh with its interval stated, live queries or extracts at the customer's choice, data from two sources combined in one report, and a documented way to reach a database behind a firewall.
8 — Hundreds of maintained connectors or a full SQL layer over every major warehouse, incremental refresh and caching explained, a built-in data preparation or modelling step, a gateway or agent for on-premise sources, a generic REST or custom connector SDK, and connector limits (rows, API calls, history) stated per plan.
10 — Connectivity an organisation can standardise on: every source reachable live or by extract with the trade-offs documented, refresh down to minutes with lineage from report back to source, source changes detected and reported, and connector behaviour, quotas and failure handling published.
The Managing Director
The connector story is the strongest part: a published list naming PostgreSQL, MySQL, SQL Server, Oracle, Snowflake, Redshift, MongoDB and BigQuery alongside Google Ads, Google Analytics 4 and Google Sheets, custom SQL, a REST API for anything not listed, and refresh from every minute down to once a day with the per-plan speed (4-hour, 1-hour, 15-minute, up-to-the-minute) spelled out. Blending several sources in one widget, an aggregate-first approach, and documented IP allow-listing to reach a database behind a firewall are all evidenced, though the captured pages give different figures for the service count (130+, 200+, hundreds). We found no public information on incremental refresh, caching behaviour, or per-plan row and API quotas. 5 11 18 6 1