Google's recent update to BigQuery's free tier is a significant shift, moving from a time-based to a usage-based model. The old 10 GB of storage and 1 TB of processed queries per month for 90 days has been replaced with a perpetual **10 GB storage and 1 TB of query processing per month**. This change warrants a neutral, numbers-based analysis for teams evaluating their analytics cost structure.
On the surface, this appears beneficial: the free tier no longer expires after three months. However, the practical implications are nuanced:
* **For new projects & prototyping:** This is a clear win. The permanent allowance lowers the initial barrier to entry for startups and experimental projects.
* **For existing, low-volume production workloads:** Previously, these would have started incurring costs after 90 days. They can now run perpetually within the free tier, representing direct cost avoidance.
* **For cost forecasting:** The predictability improves. You now have a fixed, permanent monthly baseline to subtract from your usage, simplifying long-term TCO models.
The critical consideration is the **removal of the 90-day clock**. This changes the "land and expand" dynamic. Before, a vendor might absorb initial costs knowing charges would begin later. Now, any workload under these thresholds incurs no cost indefinitely, potentially reducing Google's customer acquisition revenue but locking in long-tail users.
From a vendor selection perspective, this makes BigQuery's pricing more transparent and comparable to competitors like Snowflake's perpetual free trial or AWS Redshift's free tier. When building your RFP, you should now model:
* Permanent deduction of 1 TB/month from your query volume.
* Scenarios where multiple small departmental workloads can exist independently, each within the free tier.
* The hidden cost shift: while storage remains free at this level, the focus for cost control moves almost entirely to query optimization and slot management for workloads exceeding the tier.
- Mark
independent eye
The removal of the 90-day clock is indeed the most impactful change here, but I'd add a practical caveat around the storage limit. 10 GB is deceptively small for any real-world workload that isn't purely ephemeral. If you're prototyping a data pipeline that lands raw logs, does a few transformations, and keeps a star schema for reporting, you'll saturate that 10 GB after maybe a few thousand rows of event data with moderate nesting. The free tier effectively forces you into a "query-once, discard" pattern unless you're very disciplined about expiring tables.
There's also a subtle trap for teams using the free tier to run scheduled Airflow jobs that re-query the same data. The 1 TB per month of query processing is a hard cap across all queries, not per job. A single daily aggregation that scans a few hundred MB of uncompressed data looks harmless, but over 30 days it accumulates quickly. I've seen projects blow through that limit in the first week because they were running ad-hoc explorations alongside the scheduled pipeline.
For anyone evaluating this for low-volume production, I'd recommend treating the free tier as a sandbox for testing query patterns and schema designs, then migrate to a dedicated billing project once you have a stable load. The perpetual aspect is nice, but it doesn't change the fact that BigQuery's value proposition scales with controlled caching and partitioning, not with free-tier allowances.
Data is the new oil – but only if refined