BigQuery

The full reference for Flynt's BigQuery connection: credentials, how queries run, caching, row limits, and parameters. For the quick walkthrough, see Connect BigQuery.

Credentials

Flynt authenticates with a Google Cloud service account. Your Google Cloud admin creates one with permission to run queries (for example the BigQuery Job User and Data Viewer roles) and downloads its JSON key; an Architect (T6) or above pastes that JSON on the Connections page along with:

• Project ID -- where query jobs run.
• Location -- where your data lives (for example EU or US).
• Default dataset (optional) -- lets SQL reference bare table names without the project.dataset. prefix.

Flynt validates the JSON is a service-account key, stores it server-side with restricted access, and never displays it again -- only the service-account email is shown back so you can confirm which identity is in use. An organisation has exactly one BigQuery connection; saving again replaces it, and the next query immediately uses the new credentials.

Test connection runs SELECT 1 against your project and reports either success or the underlying BigQuery error verbatim.

How queries run

Dataset SQL and card SQL are sent to BigQuery as query jobs under your service account, in your project and location. Compute is therefore billed to your Google Cloud project, and your existing BigQuery access controls apply -- Flynt can only read what the service account can read. Query errors come back with BigQuery's own message plus the SQL that was sent, so debugging happens in one place.

Result caching

Flynt is built to query BigQuery rarely and serve everyone from cache:

• Datasets cache their result for a configurable TTL (default 300 seconds). Within the TTL, every card on the dataset shares the cached rows. Viewers never trigger a run -- they always get cached data.
• Cards with direct SQL can cache a parameter-free base query and have it refreshed on a schedule, so dashboards open instantly without touching the warehouse. See Cache windows.

Editing a dataset's SQL clears its cache.

Row limits

Context	Limit
Dataset runs	configurable per dataset; default 50,000 rows, ceiling 200,000
Live card SQL	10,000 rows
Cached card base queries	org guardrail, default 10,000 rows

A dataset run that fills its limit fails with an explicit error rather than silently truncating -- the fix is to aggregate further in SQL or raise the dataset's limit. The limits exist because Flynt is an aggregation-first tool: cards visualise summaries, not raw extracts.

Query parameters

SQL can declare placeholders with curly-brace syntax -- {start_date}, {region} -- which dashboard filters and run-time inputs fill in. Values are typed (date, datetime, text, number, select) and are passed to BigQuery as bound query parameters, never spliced into the SQL text, so user input cannot alter the query's structure. A run with missing parameter values is rejected before anything reaches the warehouse.

How parameters connect to dashboard filters is covered in Datasets and SQL.