BigQuery sandbox: free limits, setup and what happens when you upgrade

What the sandbox limits are

Google’s sandbox page (read in October 2026) lists these limits:

• All BigQuery quotas and limits apply. The sandbox is not a smaller engine; it is the same BigQuery with extra caps.
• Storage: a lifetime limit of 10 GiB. Google adds that this quota “is not refunded upon data deletion”. Loading 8 GiB, deleting it and loading it again does not work: you have used 8 of your 10.
• Compute: 1 TiB of processed query data each month, the same as the BigQuery free tier.
• Expiration: every dataset has a default table expiration, and all tables, views and partitions expire after 60 days.
• Not supported: streaming data, data manipulation language (DML) statements, and the BigQuery Data Transfer Service.

The last line has two effects most guides skip. No DML means no INSERT, UPDATE, DELETE or MERGE; you build tables with CREATE TABLE ... AS SELECT or by loading files instead. And no Data Transfer Service means no scheduled queries, because Google’s scheduled queries page (read in October 2026) says scheduled queries “use features of BigQuery Data Transfer Service”.

How far 1 TiB of free queries goes

BigQuery bills on-demand queries by the bytes read in the columns you select. The fastest way to use up the sandbox is SELECT *. Google’s own sandbox tutorial queries the NYC Citi Bike trips table in the public datasets, so here is that table, counting trips per start station:

SELECT
  start_station_name,
  COUNT(*) AS num_trips
FROM `bigquery-public-data.new_york.citibike_trips`
GROUP BY start_station_name
ORDER BY num_trips DESC
LIMIT 5;

The job processed 699,461,121 bytes and billed 700,448,768 (668 MiB). The table holds 33,319,019 rows and 4,916,537,671 bytes; the query read one column of fifteen. Here is what the same table costs with different queries, measured with a dry run:

Two rules fall out of that table:

1. LIMIT does not reduce the bytes on an ordinary table, as the dry runs above show. Google’s pricing page (read in October 2026) notes one exception: on a clustered table, LIMIT can reduce the bytes scanned.
2. Selecting all columns cost seven times more than selecting one, for ten rows of output.

The query editor shows the estimate before you run it, next to a check mark. In the sandbox, read it every time.

Small queries have a floor. Google charges a minimum of 10 MB per table referenced and per query. A week of the public GA4 sample:

SELECT
  event_date,
  COUNT(*) AS events,
  COUNT(DISTINCT user_pseudo_id) AS users
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210107'
GROUP BY event_date
ORDER BY event_date;

It processed 7,518,449 bytes and billed 10,485,760: the 10 MB minimum. Without the _TABLE_SUFFIX filter the dry run reads 131,761,313 bytes for the whole sample, about 17 times more.

How to track what you have used this month

To see how much of the 1 TiB you have used, query the jobs view. Run this in your sandbox project, changing region-us to the location of your data:

SELECT
  COUNT(*) AS queries,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 3) AS tib_billed,
  ROUND(100 * SUM(total_bytes_billed) / POW(1024, 4), 1) AS pct_of_free_tib
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE job_type = 'QUERY'
  AND creation_time >= TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), MONTH);

That result is from our own test project between 1 and 16 October 2026: 2,084 queries had used 52.9% of a terabyte. The view covers one project in one region; on a billed account the free 1 TiB is counted per billing account, so add up every project on it.

How to start the sandbox

These steps follow Google’s sandbox page as read in October 2026.

1. Open BigQuery Studio at https://console.cloud.google.com/bigquery.
2. Sign in with a Google account, or create one.
3. On the welcome page, pick your Country, tick the Terms of Service box, optionally tick Email updates, and click Agree and continue.

4. Click Create project. On the New Project page, enter a Project name. For Organization, choose one or No organization; accounts managed by a school or company must choose their organization. If asked for a Location, click Browse and pick one.

5. Click Create. You return to BigQuery, and a sandbox notice appears at the top of the page.

There is no separate “sandbox login”. The sandbox is a state of a project: any project without billing is in it. Public datasets are already visible in the bigquery-public-data project, so you can run the queries above straight away. To bring your own data, load a CSV or a Google Sheet as a table; it counts against the 10 GiB and expires in 60 days.

What the GA4 export does in a sandbox

Google Analytics 4 can write its BigQuery export to a sandbox project. Google’s Set up BigQuery Export page (read in October 2026) says you can export “to the BigQuery sandbox free of charge (sandbox limits apply)”. Those limits change what you get:

• Daily export only. Google’s export schema page says that in the sandbox “there is no intraday import of events”. The streaming export, which fills events_intraday_YYYYMMDD, needs an upgraded project.
• 60 days of history at most. Each events_YYYYMMDD table is a table in the sandbox, so it expires 60 days after it is created, and the export does not send past days again, so expired days are gone.
• The 10 GiB cap stops the export. Google lists “Cloud project over quota” as a reason export tables stop populating and notes the quota “is small for free projects (10GB)”. It also warns that switching the project from free to paid can make the export fail if the project is already over 10 GB.

For a site you want to analyse for longer than two months, enable billing before linking GA4. How to link the property and read the tables is in the GA4 BigQuery Export guide and querying GA4 event data.

Sandbox, free tier and free trial

Sources, read in October 2026: Google’s BigQuery pricing page for the free tier, which it says is available “during and after the free trial period”, and Google’s free features page for the trial. Beyond the free tier, on-demand queries cost $6.25 per TiB on the pricing page; more on that in BigQuery pricing.

The difference that matters most is storage. On a billed account the 10 GiB is free each month; in the sandbox it is a one-time allowance.

How to upgrade, and the expiration trap

Google’s upgrade instructions are two lines: enable billing for the project, then choose a pricing model. In the console, per the Cloud Billing docs (read in October 2026):

1. Open the My projects page in the Billing section of the Google Cloud console. A sandbox project shows “Billing is disabled”.

2. In the project’s row, open the Actions menu and choose Change billing.

3. Pick a billing account and click Set account.

The project is now out of the sandbox. Your existing tables are not safe yet. Google’s sandbox page says you “should update the default expiration times” after upgrading, and its dataset docs (read in October 2026) explain why: when you change a dataset’s default, “any tables that already exist expire according to the original table expiration setting”. Changing the dataset protects new tables only. Every old table still has a date on it.

Clear the dataset defaults first. This statement was validated by dry run, not run:

ALTER SCHEMA your_dataset
SET OPTIONS (
  default_table_expiration_days = NULL,
  default_partition_expiration_days = NULL
);

Then clear each existing table and view. Rather than typing them, generate the statements from INFORMATION_SCHEMA. Shown here against the public new_york dataset so the output is visible; replace it with your dataset:

SELECT
  FORMAT('ALTER %s `%s.%s` SET OPTIONS (expiration_timestamp = NULL);',
         IF(table_type = 'VIEW', 'VIEW', 'TABLE'), table_schema, table_name) AS statement
FROM `bigquery-public-data.new_york.INFORMATION_SCHEMA.TABLES`
ORDER BY table_name
LIMIT 3;

Views need ALTER VIEW: in our dry run, ALTER TABLE on a view failed with “ALTER TABLE SET OPTIONS only supports setting options for tables”. Both forms passed the dry run on the right object type. For partitioned tables, also check the table’s own partition_expiration_days option, since the sandbox applies the 60 days to partitions too.

Do this soon after upgrading. A table created on day one of a sandbox project is deleted on day 60 whether or not billing is on. Before you do, set a budget alert on the billing account; the free tier still applies after the upgrade, but nothing stops a SELECT * on a large table from passing it.

When you outgrow the sandbox

The sandbox is good for learning SQL, testing a public dataset and checking whether BigQuery fits. It stops being enough on the day a query result has to reach someone else on a schedule: there are no scheduled queries, and the tables behind a report vanish after 60 days.

After the upgrade, the usual next step is to export a result to a spreadsheet by hand, which works until the second request. In OWOX Data Marts, you publish the query once as a Data Mart and deliver it to Google Sheets, Data Studio, Excel, email or Slack on a schedule, with one data model behind every report. OWOX Data Marts runs your SQL as written, in your own BigQuery project, and does not transform the data. The function families you will use in that SQL are mapped in the BigQuery functions overview.

Google BigQueryHow to Load Data into BigQuery: Every Method and When to Use ItOctober 6, 2026→Google BigQueryIs BigQuery a Data Warehouse or a Data Lake? A Marketing GuideOctober 6, 2026→Google BigQueryBigQuery Aggregate Functions: COUNT, SUM, STRING_AGG, ARRAY_AGG and MoreOctober 16, 2026→

See all articles →