BigQuery Sandbox: Is BigQuery Free, and What the Free Tier Actually Covers

The BigQuery sandbox is free in the way people actually mean when they ask. No credit card, no billing account on the project, no trial countdown, and no surprise invoice at the end of the month, because there is no payment method for Google to charge. You sign in with a Google account, create a project, and run queries.

The allowance is the same one every BigQuery account gets: 1 TiB of query processing and 10 GiB of active storage per month. Those limits are permanent, not promotional. What makes the sandbox different is that you get them without attaching a payment method, which means you cannot accidentally spend money while you are still deciding whether the product is right for you.

So the honest answer to "is BigQuery free" is: yes for evaluation and yes for genuinely small workloads, with two catches that nobody mentions until you hit them. One is a set of three disabled features. The other is a 60-day timer on everything you build.

What you get in the BigQuery sandbox

That storage number is worth pausing on, because 10 GiB is more generous than it sounds for evaluation. BigQuery stores data column by column and compresses it hard. A CSV export that occupies 40 GB on your laptop frequently lands in single-digit gibibytes once loaded.

What the BigQuery sandbox does not support

Google lists three unsupported features, and each one blocks a specific kind of work:

• Data manipulation language statements. No INSERT, UPDATE, DELETE or MERGE. You can create tables and load data into them, but you cannot modify rows in place afterwards. Anything shaped like an incremental pipeline is off the table, and so is a straightforward correction to one bad row.
• Streaming data. The Storage Write API is unavailable, so no real-time ingestion. Batch loading from Cloud Storage or a local file still works fine, which covers most evaluation work.
• BigQuery Data Transfer Service. The managed connectors that pull from Google Ads, YouTube, Cloud Storage on a schedule and various SaaS sources are all off. You load data yourself, or you move it in from your other apps and APIs with a pipeline that sits outside BigQuery.

Read together, these define what the sandbox is for. It is an excellent place to analyze data and a poor place to maintain data. Loading a snapshot and querying it hard is exactly the intended path. Building anything that updates on a schedule is not.

The 60-day expiration is the real trap

This is the part that catches people, and it is worth stating plainly: every dataset created in the sandbox carries a default table expiration, so all tables, views and partitions inside it are deleted automatically 60 days after creation.

There is no warning email. There is no recovery. Two months after you build a proof of concept that convinced your team to adopt BigQuery, the tables underneath it are simply gone, and if the load script lived in someone's terminal history rather than in version control, so does the work.

The defense is boring and effective. Keep the SQL that creates and loads every table in a file in your repository, so any table is one script away from existing again. Treat sandbox tables as a cache of something reproducible, never as the only copy. If a piece of work matters beyond two months, that is the signal to enable billing rather than to fight the expiry.

You can update the default expiration times for datasets, tables, views and partitions, but the cleanest fix for anything long-lived is to stop using the sandbox for it.

Sandbox, free tier, and free trial are three different things

These get used interchangeably and they are not the same, which is why cost estimates for BigQuery vary so wildly across the internet.

The important line is the middle one. The free tier does not disappear when a trial ends and it does not disappear when you attach a payment method. A production BigQuery project with a card on file still gets its first 1 TiB of scanning and first 10 GiB of storage free every single month. Plenty of small teams run real workloads and never see a bill.

What happens when you run out

The two modes behave completely differently, and this is the strongest argument for starting in the sandbox.

In the sandbox, hitting the limit stops your queries. That is the whole consequence. You wait for the calendar to turn over and the allowance refills. It is a hard ceiling, which is precisely what you want while you are learning what a query costs.

With billing enabled, nothing stops. You cross into paid rates at $6.25 per TiB scanned and $0.023 per GiB per month for active storage, and you find out on the invoice. One SELECT * against a large unpartitioned table can burn through the free TiB in a single execution, because BigQuery charges for bytes read off disk rather than rows returned. Before you enable billing it is worth setting custom query quotas and getting into the habit of capping ad-hoc query spend. The full rate card, including the Editions slot pricing and the storage figure most guides get wrong, is on our BigQuery pricing page.

When to leave the sandbox

Four signals, any one of which is enough:

1. You need DML. The moment you want to correct a row rather than reload a table, the sandbox is fighting you.
2. Something must survive 60 days. A dashboard other people rely on cannot sit on tables with a timer.
3. You want scheduled ingestion. No Data Transfer Service means no managed connectors and no scheduled loads.
4. You are near the allowance. If you routinely finish the month unable to query, you have outgrown it, and the first paid month is usually a rounding error anyway.

Upgrading is one action: enable billing on the project. DML, streaming and the Data Transfer Service switch on, and new datasets stop carrying the automatic expiration. Datasets you already created keep their expiry settings, so fix those explicitly rather than assuming the upgrade cleaned up after itself.

Getting more out of the free TiB

Since the sandbox limit is bytes scanned rather than queries run, everything that lowers scan volume directly buys you more evaluation. Name your columns instead of using SELECT *, because a columnar store only reads what you ask for and this alone is often a ten-fold reduction. Partition tables by date and filter on the partition column. Use the dry-run estimate in the console, which shows expected bytes processed before you execute and costs nothing to check. And query a small sample table while you are iterating on logic, then point the finished query at the full dataset once.

The other quiet drain is the exploratory loop: not knowing which table holds the answer, so running six variations to find out. Each one is a full scan against your allowance. That is the specific problem turning a plain-English question into SQL solves, and it is why we show the generated SQL every time rather than hiding it. You see what is about to run, and how much it is about to read, before it reads anything.

The verdict

The BigQuery sandbox is one of the more honest free tiers in cloud analytics. There is no card, no clock, and no dark pattern waiting to charge you. It is genuinely enough to load a real dataset, ask hard questions of it, and reach a defensible decision about whether BigQuery belongs in your stack.

Just write down the 60 days somewhere you will see it, keep your load scripts in version control, and do not build anything you would be upset to lose. Within those lines, it costs nothing and it will answer the question you came to answer. When you are ready to connect it to something, see how Agentsql connects read-only to BigQuery.