Query BigQuery in Plain English

To report on daily orders stored in BigQuery, ask for a defined period and measure: “Count paid orders by day for August 2026.” Datarelix generates a GoogleSQL query, executes it as a validated read-only query and turns the result into a chart. You still need access to the dataset and a project allowed to run the job.

Know which project reads and which project pays

The data project contains the dataset. The billing project runs the query job; the two can differ. Ask the owner for the approved dataset, job location and authentication method. Datarelix supports Google OAuth, service-account JSON and service-account impersonation as described in the connection reference.

The querying identity needs permission to create jobs in the billing project and read the relevant data. A common arrangement is BigQuery Job User on the billing project and BigQuery Data Viewer on the selected dataset, rather than the entire data project. Existing organisation policies and finer-grained access rules still apply. BigQuery query permissions

Signing in to Datarelix with Google does not connect a BigQuery dataset. Authorise that connection separately and confirm the job location matches the data being queried.

Put a usable date filter in the question

This example assumes a table partitioned on a DATE column named order_date:

SELECT order_date, COUNT(*) AS paid_orders
FROM `example-project.sales.orders`
WHERE order_date >= DATE '2026-08-01'
  AND order_date < DATE '2026-09-01'
  AND status = 'paid'
GROUP BY order_date
ORDER BY order_date;

An excerpt might show 40 orders on August 1 and 55 on August 2. Those two days total 95; they are not the total for August. The query omits dates without matching rows, so request a complete calendar series if your chart must distinguish zero orders from missing data. The date range comes from the wording of the question, as how text-to-SQL generates database queries shows, so name the period explicitly.

A filter on the partitioning column can let BigQuery skip partitions. A condition on another date field may describe the right business period without pruning the partitions you expect. Ask a SQL reviewer to inspect the actual predicate when cost or required partition filters matter. Query partitioned tables

A per-query cap is not a spending budget

Datarelix’s BigQuery connector sets maximum_bytes_billed to 10 GiB per query. This is a query-job control, not a monthly allowance or a cap on all Google Cloud spending. Repeated questions and dashboard refreshes create additional jobs. Your billing model and other workloads determine the eventual bill.

For on-demand billing, BigQuery’s maximum-bytes setting can reject a query whose estimated billed bytes exceed the threshold. LIMIT on the returned rows is not a general way to reduce scanned bytes. Review selected columns and partition filters instead. BigQuery cost controls

Google Cloud charges remain separate from your Datarelix plan. For capacity-based projects, review reservations and capacity billing with the owner rather than treating scanned bytes as the whole cost model.

Choose the connection identity with the source owner

Google sign-in identifies your Datarelix account; BigQuery connection authorisation is a separate step. For OAuth, review the identity being authorised and its effective Google Cloud permissions. The consent scope and IAM permissions describe different controls; consent wording alone does not establish the data that identity may read.

A service-account key provides another connection method and needs an agreed owner and rotation process. Service-account impersonation depends on a configured backend identity arrangement; signing in with gcloud on your laptop does not configure the hosted service. Use the BigQuery connection reference for the requirements of each mode.

The connection can include selected allowed datasets. Confirm the fully qualified dataset names and compatible query location. A source can be readable in another project without being available in the job’s chosen region.

Partition dates and business dates can differ

An order can be placed on August 31 and loaded on September 1. A report by order date and a filter by ingestion date then answer different questions. When a table requires a partition filter, the analyst needs both a valid partition restriction and the intended business-period condition.

For a table partitioned by order_date, the example above puts a direct range on that column. For an ingestion-time partitioned table, inspect its partition pseudocolumn and loading pattern instead. Do not add a narrow ingestion filter that silently removes late-arriving orders from the business period.

Datarelix discovers partition metadata to help form queries. Review the generated predicate and refresh discovery when relevant table metadata changes. Metadata helps generation; it does not guarantee the correct reporting boundary or partition pruning for every query. BigQuery partition filters

Nested fields and joins need a row-level interpretation

BigQuery’s repeated fields can hold several items within one order. Expanding them with UNNEST changes the number of rows. If an order total appears on each expanded row, summing it multiplies the order’s contribution. Count distinct order IDs for an order count, or aggregate item amounts at item grain for an item measure.

Declared primary and foreign keys are not enforced by BigQuery. Check the data before relying on a relationship, and review inferred joins when no key is declared. A helpful description states what one row represents and whether several child records can match; keep such notes as schema context and business definitions. BigQuery key constraints

For a business user, clarify whether “orders” means orders, items or shipments. For an analyst, inspect the join or UNNEST and reconcile a known subtotal. The verification guide demonstrates why the final output count cannot reveal every duplicated amount.

Review a trial’s actual workload

Keep a small set of representative questions: a daily count, a monthly total, a segment breakdown and a join used in normal reporting. Record the query job information available to the project owner alongside the result. Compare queries over the same period when assessing the effect of selecting fewer columns or using an appropriate partition filter.

The owner can use project query controls and billing information to evaluate the wider workload. A successful question below a per-job limit says little about a month of repeated questions, retries and refreshes. Separate the cost of BigQuery execution from the Datarelix subscription and usage allowances.

Turn the answer into an analyst or business-user deliverable

For an investigation, retain the query and checked result with the exact period. For a recurring chart, decide whether dates should move with each refresh and how missing days should appear. If the source can receive late records, record the extraction date so another reader understands when the answer was current.

A chart exported for a colleague is a snapshot. Keep its measure, source and period in the title or accompanying notes. Analysts can preserve the SQL for reconciliation; business users can reuse the checked chart through the dashboard workflow without reconstructing the analysis each time.

Check and reuse the report

Compare a small date range with a known order count. Confirm that “paid” reflects the intended statuses and that each row represents one order before using COUNT(*). A table with one row per order line needs a different calculation.

Ask for a line chart, then add the reviewed result to a private dashboard. Refresh is manual and reruns the saved query; fixed August dates continue to report August. The dashboard guide shows the complete workflow.