The right BigQuery pricing model depends on a fundamental distinction: On-Demand charges for data scanned, while Editions charge for compute time. It determines whether you’re optimizing for I/O efficiency or CPU efficiency, and getting it wrong can mean paying 2-3x more than necessary.

Google deprecated flat-rate pricing in July 2023, introducing three Editions tiers with slot-based autoscaling. Simultaneously, the on-demand price increased 25% to $6.25 per TiB. Understanding these models (and knowing when to switch between them) has become essential knowledge for anyone managing BigQuery costs at scale.

This guide provides the concrete numbers, SQL queries, and decision framework you need to evaluate your own situation. Whether you’re scanning 5 TiB monthly for ad-hoc analysis or running 50 TiB daily ETL pipelines, you’ll leave with a clear answer for your workload.

How On-Demand Billing Actually Works

On-Demand pricing charges $6.25 per TiB of data scanned across most regions, with the first 1 TiB free monthly per billing account. This seems straightforward, but several mechanics significantly impact your actual costs.

BigQuery uses columnar storage, meaning you’re charged only for columns referenced in your SELECT statement, not the entire table. A query running SELECT user_id, created_at FROM events scans only those two columns, even if the table has fifty. This makes column pruning one of the most effective cost optimization techniques: selecting only needed columns can reduce costs by 90% or more on wide tables.

The minimum billing threshold is 10 MB per table referenced and 10 MB per query overall. Running thousands of tiny queries against small tables still accumulates meaningful costs. Cached results incur no charge, and queries returning errors aren’t billed.

Partitioning and clustering provide the other major cost lever. Queries filtering on partition columns scan only relevant partitions. A query against a date-partitioned table requesting a single day’s data pays for one day, not the entire table history. Clustering enables block pruning within partitions, allowing BigQuery to skip irrelevant data blocks based on filter predicates.

One counterintuitive behavior: LIMIT clauses don’t reduce costs on non-clustered tables. Running SELECT * FROM table LIMIT 10 still scans entire columns because BigQuery must read all data to identify which rows to return.

Regional pricing remains consistent at $6.25/TiB across US, EU, and most Asia-Pacific regions. BigQuery Omni for querying AWS S3 or Azure Blob Storage costs $9.125/TiB (a 46% premium for cross-cloud analytics).

Free Tier Details

The free allocation resets monthly per billing account, not per project. You receive 1 TiB of queries processed free monthly, 10 GiB of storage free monthly, and 2 TiB of Storage Write API ingestion free monthly. Batch loading using the shared slot pool is always free.

BigQuery Sandbox provides the same limits without requiring a credit card, though tables expire after 60 days and streaming ingestion is disabled. For learning and experimentation, Sandbox removes the billing barrier entirely.

Understanding the Three Editions Tiers

BigQuery Editions replaced flat-rate pricing with three tiers differentiated by features, SLAs, and commitment options. All three use slot-based pricing, where a slot represents one virtual CPU used to execute queries. Unlike On-Demand’s per-TiB model, you’re paying for compute capacity regardless of how much data you scan.

The Slot-Based Model Explained

A slot is a unit of computational capacity. BigQuery automatically determines how many slots a query needs based on query complexity and size. Simple queries might use 10 slots; complex joins across large tables might consume hundreds.

With Editions, you configure two parameters: a baseline (guaranteed minimum slots, always charged whether used or not) and a maximum (upper bound including autoscale capacity). The autoscaler dynamically adjusts between these values based on workload demand.

Autoscaling operates in 50-slot increments with a 60-second minimum billing window before scaling down. If your workload needs 101 slots, you’re billed for 150. If a query uses 200 slots for 5 seconds, you’re billed for 200 slots × 60 seconds minimum. This behavior makes autoscaling most cost-effective for sustained workloads rather than sporadic queries.

Standard Edition: $0.04/slot-hour

Standard Edition targets development workloads and ad-hoc analysis. At $0.04 per slot-hour, it’s the cheapest Editions tier but carries significant limitations.

The hard cap is 1,600 slots maximum per reservation. You cannot purchase more capacity even if you need it. No commitment discounts are available; you pay the full rate regardless of usage duration. The SLA is 99.9% monthly uptime, lower than other tiers.

More critically, Standard Edition lacks features many analytics engineers consider essential. BigQuery ML is unavailable (no CREATE MODEL statements for training regression, clustering, or forecasting models). BI Engine query acceleration is disabled. You can query existing materialized views but cannot create new ones or benefit from smart tuning optimizations. Security features including customer-managed encryption keys (CMEK), VPC Service Controls, column-level access control, and row-level security all require higher tiers.

Standard Edition works well for development environments where you need predictable costs and don’t require advanced features. It’s not suitable for production workloads with security requirements or ML use cases.

Enterprise Edition: $0.06/slot-hour

Enterprise Edition provides production-ready capabilities at $0.06 per slot-hour pay-as-you-go, with substantial commitment discounts: $0.048 for one-year commitments (20% savings) and $0.036 for three-year commitments (40% savings).

The feature set is comprehensive. BigQuery ML enables in-database machine learning with linear regression, logistic regression, k-means clustering, time series forecasting, matrix factorization, and TensorFlow model imports. BI Engine accelerates dashboard queries by caching data in memory for sub-second response times. Continuous queries enable real-time event processing with export to Pub/Sub or Bigtable.

Security features include CMEK for customer-managed encryption, VPC Service Controls for network isolation, column-level and row-level security, and dynamic data masking. Enterprise also supports BigQuery Omni for multi-cloud analytics against AWS S3 and Azure Blob Storage.

The SLA increases to 99.99% monthly uptime. For production workloads requiring reliability, security, or advanced analytics capabilities, Enterprise Edition is typically the right choice.

Enterprise Plus: $0.10/slot-hour

Enterprise Plus adds capabilities for regulated industries and disaster recovery requirements at $0.10 per slot-hour, with commitment discounts to $0.08 (one-year) and $0.06 (three-year).

The unique features are managed disaster recovery with cross-region replication and Assured Workloads compliance certifications including FedRAMP, CJIS, IL4, and ITAR. If you’re operating in government, healthcare, or financial services with strict compliance requirements, Enterprise Plus may be mandatory.

One notable exception: Enterprise Plus does not support BigQuery Omni. If you need multi-cloud analytics, Enterprise Edition is your only Editions option.

The Autoscaling Tax

Theoretical slot-hour costs rarely match actual bills due to autoscaling behavior. The 50-slot increments and 60-second minimum billing window create overhead that compounds across many queries.

A practical rule of thumb: apply a 1.5× multiplier to theoretical slot-hour costs when estimating real-world autoscaling expenses. Short queries and burst patterns incur significant overhead from the minimum billing window. A workload theoretically requiring $1,000/month in slot-hours often costs $1,400-1,600 in practice.

This multiplier decreases for sustained workloads running continuously and increases for sporadic patterns with many short queries. If your workload consists of thousands of 5-second queries, the multiplier might be 2× or higher. If you’re running 4-hour ETL jobs, it might be closer to 1.2×.

Feature Comparison: What You Actually Get

The feature gap between pricing models is larger than the pricing suggests. This matrix summarizes what’s available at each tier:

On-Demand maintains feature parity with Enterprise Plus for most capabilities except continuous queries and managed disaster recovery. Organizations using On-Demand can access BQML, BI Engine, security features, and materialized views without switching to Editions.

This means the choice between On-Demand and Editions is primarily about cost optimization, not feature access. Standard Edition, conversely, trades features for lower slot-hour pricing, a tradeoff that only makes sense for specific use cases.

The Breakeven Framework

The fundamental question (On-Demand versus Editions) reduces to comparing I/O costs against CPU costs for your specific workloads. Heavy data scanning with simple aggregations favors On-Demand; complex transformations on smaller datasets favor Editions.

Calculating Your Breakeven Point

Run this query against your own INFORMATION_SCHEMA data to compare costs directly:

WITH cost_analysis AS (
  SELECT
    DATE_TRUNC(creation_time, MONTH) AS month,
    SUM(total_bytes_billed) / POW(1024, 4) * 6.25 AS on_demand_cost,
    SUM(total_slot_ms) / 1000 / 3600 * 0.04 * 1.5 AS standard_edition_cost,
    SUM(total_slot_ms) / 1000 / 3600 * 0.06 * 1.5 AS enterprise_edition_cost
  FROM `region-us`.INFORMATION_SCHEMA.JOBS
  WHERE
    creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
  GROUP BY month
)
SELECT
  month,
  ROUND(on_demand_cost, 2) AS on_demand_usd,
  ROUND(standard_edition_cost, 2) AS standard_usd,
  ROUND(enterprise_edition_cost, 2) AS enterprise_usd,
  ROUND(enterprise_edition_cost / NULLIF(on_demand_cost, 0) * 100, 1) AS editions_pct_of_ondemand
FROM cost_analysis
ORDER BY month DESC;

The 1.5x multiplier accounts for autoscaling overhead. Interpret the editions_pct_of_ondemand column as follows: if it exceeds 75%, On-Demand remains more cost-effective (the savings from switching don’t justify sacrificing flexibility). Below 50%, Editions likely provides meaningful savings. Between 50-75% is a gray zone where other factors (concurrency, predictability, features) should drive the decision.

Concrete Scenarios with Real Numbers

Scenario A: Daily ETL processing 50 TiB

Consider a data team running nightly ETL jobs that process 50 TiB of raw data into analytics-ready tables. The jobs run for approximately 4 hours using sustained compute.

On-Demand cost: 50 TiB × $6.25 × 30 days = $9,375/month

Enterprise Edition with 500 baseline slots running 4 hours nightly: 500 slots × 4 hours × 30 days × $0.06 = $3,600/month

Savings with Editions: 62%

This represents Editions’ sweet spot: sustained, compute-heavy workloads running predictable schedules. The ETL jobs use slots continuously during their run window, minimizing autoscaling overhead.

Scenario B: Ad-hoc BI queries totaling 5 TiB monthly

A small analytics team runs exploratory queries throughout the day, scanning approximately 5 TiB monthly across various tables. Queries are sporadic, dozens of short queries per day rather than sustained processing.

On-Demand cost: 5 TiB × $6.25 = $31.25/month (4 TiB after free tier)

Standard Edition with 100-slot maximum, assuming 8 hours of active querying daily: 100 slots × 8 hours × 20 days × $0.04 = $640/month

Winner: On-Demand by 20×

Sporadic, exploration-focused workloads almost always favor On-Demand pricing. The 60-second minimum billing window makes Editions expensive for workloads with many short queries.

Scenario C: Mixed production workload

A mature data platform runs scheduled dbt models (compute-heavy, predictable timing), serves Looker dashboards (high concurrency, sporadic), and supports analyst ad-hoc queries (unpredictable, exploratory).

The optimal approach is hybrid: Enterprise Edition for scheduled ETL with committed slots during the transformation window, On-Demand for ad-hoc queries and low-priority dashboard refreshes. Assign different projects to different pricing models based on workload characteristics.

Beyond Pure Cost Calculations

Several factors beyond breakeven math influence the decision:

Concurrency limits differ significantly. On-Demand allows roughly 100 concurrent queries sharing up to 2,000 slots from the shared pool. Editions provide dedicated capacity without artificial concurrency limits, which is critical for organizations running dashboards serving hundreds of simultaneous users. If you’ve experienced query queuing during peak hours, Editions’ dedicated capacity solves that problem.

Query performance consistency favors Editions for production workloads. On-Demand slots are “hot” and instantly available but shared across all Google Cloud customers. During peak periods (month-end, holidays, global events), you may receive fewer slots than expected. Editions reservations guarantee your configured baseline capacity regardless of what other customers are doing.

Cost predictability matters for budgeting. On-Demand costs fluctuate with usage patterns; a runaway query or unexpected data volume can spike bills unexpectedly. Editions provide fixed baseline costs plus bounded autoscaling expenses. Finance teams often prefer the predictability of slot-based commitments, even if the total cost is slightly higher.

Autoscaler latency introduces approximately 10-second delay when scaling up from zero or from baseline to maximum. On-Demand queries start immediately with whatever capacity is available. For latency-sensitive ad-hoc queries where users expect instant results, this difference can impact perceived performance.

Self-Assessment SQL Queries

Before making any pricing decision, understand your current consumption patterns. These INFORMATION_SCHEMA queries provide the data you need.

Identify Your Most Expensive Queries

SELECT
  user_email,
  job_id,
  SUBSTR(query, 1, 200) AS query_preview,
  ROUND(total_bytes_billed / POW(1024, 4) * 6.25, 2) AS estimated_cost_usd,
  ROUND(total_slot_ms / 1000 / 3600, 3) AS slot_hours,
  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
ORDER BY total_bytes_billed DESC
LIMIT 25;

This reveals optimization opportunities. Expensive queries often benefit from partitioning, clustering, or query restructuring regardless of which pricing model you choose. Fixing the top five queries might reduce your bill by 30% without changing pricing models at all.

Estimate Slot Requirements from History

WITH hourly_slots AS (
  SELECT
    TIMESTAMP_TRUNC(period_start, HOUR) AS hour,
    SUM(period_slot_ms) / 1000 / 3600 AS slots_consumed
  FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
    AND (statement_type != 'SCRIPT' OR statement_type IS NULL)
  GROUP BY hour
)
SELECT
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(50)]) AS p50_slots,
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(75)]) AS p75_slots,
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(90)]) AS p90_slots,
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(99)]) AS p99_slots,
  ROUND(MAX(slots_consumed)) AS max_slots
FROM hourly_slots;

P90 provides a reasonable starting point for maximum slot configuration. Your baseline should cover sustained load, typically 60-80% of P50 if you want to minimize autoscaling overhead while maintaining cost efficiency.

User-Level Cost Attribution

SELECT
  user_email,
  COUNT(*) AS query_count,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS tib_processed,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 6.25, 2) AS estimated_cost_usd,
  ROUND(SUM(total_slot_ms) / 1000 / 3600, 2) AS total_slot_hours,
  ROUND(AVG(TIMESTAMP_DIFF(end_time, start_time, SECOND)), 1) AS avg_query_duration_sec
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
GROUP BY user_email
ORDER BY estimated_cost_usd DESC
LIMIT 20;

This query enables chargeback reporting and identifies which users or service accounts drive the most cost. Often, a single scheduled job or a few power users account for 80% of spend.

Analyze Query Patterns by Hour

SELECT
  EXTRACT(HOUR FROM creation_time) AS hour_of_day,
  COUNT(*) AS query_count,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS tib_processed,
  ROUND(AVG(total_slot_ms) / 1000, 1) AS avg_slot_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
GROUP BY hour_of_day
ORDER BY hour_of_day;

Understanding when queries run helps size Editions reservations. If 80% of compute happens between 2-6 AM during ETL windows, you might use a smaller baseline with aggressive autoscaling rather than paying for capacity that sits idle twenty hours daily.

Monitor Slot Contention Post-Migration

After switching to Editions, use this query to identify queries waiting for capacity:

SELECT
  job_id,
  user_email,
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS contention_pct,
  MAX(period_estimated_runnable_units) AS max_queued_units,
  ROUND(SUM(period_slot_ms) / 1000 / 3600, 3) AS slot_hours
FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
GROUP BY job_id, user_email
HAVING contention_pct > 50
ORDER BY contention_pct DESC
LIMIT 20;

High contention_pct indicates queries spending significant time waiting for slots, a signal to increase baseline or maximum capacity. If contention is consistently above 30%, your reservation is undersized for the workload.

Common Migration Mistakes

Migration anti-patterns consistently appear in practitioners’ experiences. Avoiding these mistakes can save thousands of dollars and significant frustration.

Over-Provisioning Maximum Slots

The autoscaler aggressively scales toward the configured maximum to prioritize query speed. Setting max_slots to 1,600 because “peak workloads occasionally need it” often results in routine queries consuming far more slots than necessary.

One engineering team reported their experience: when they configured max_slots = 1600, BigQuery frequently scaled to 1,600 slots even for queries that would complete reasonably with 400. The autoscaler optimizes for speed, not cost. Only the 99th percentile of their queries actually required that much capacity.

Start conservative. Set maximum slots to your P90 historical usage, not P99 or peak. The autoscaler handles occasional bursts acceptably; you don’t need permanent headroom for every possible spike. You can always increase the maximum later. Increasing is instant, while commitments require careful planning.

Ignoring the 60-Second Minimum Billing Window

A 100-slot query completing in 5 seconds is billed for 100 slot-minutes, not 8.3 slot-seconds. This makes Editions relatively expensive for workloads consisting of many short queries.

If your pattern is thousands of sub-minute operations (interactive BI tools, data exploration, API-driven micro-queries), the 60-second minimum dramatically inflates costs compared to theoretical calculations. Either batch small queries together, stay on On-Demand for that workload, or accept the overhead as the cost of dedicated capacity.

Migrating Without Optimizing Queries First

Inefficient queries consuming excessive slots don’t magically improve with Editions. They just consume your reserved capacity faster. A query scanning 10 TiB when it could scan 100 GiB with proper partitioning wastes slots just as it wastes bytes.

Implement partitioning, clustering, and column pruning before switching. Reducing bytes processed also reduces slots required. The query optimization work pays dividends regardless of pricing model, but it’s especially important with Editions where you’re paying for compute capacity whether it’s used efficiently or not.

Purchasing Commitments Before Testing

One-year and three-year commitments offer substantial discounts (20% and 40% respectively), but they lock you into configurations that might not match actual needs. A commitment purchased based on estimated requirements often proves wrong in practice.

Start with pay-as-you-go autoscaling for 30+ days. Monitor actual slot consumption patterns across different workload types and times. Identify your true baseline (sustained minimum) versus burst requirements. Only then purchase commitments based on observed data.

If your analysis shows you need 200 baseline slots with bursts to 600, commit to 150-200 slots and let autoscaling handle the rest. The commitment discount on baseline slots plus pay-as-you-go for bursts often beats committing to peak capacity you rarely use.

Running All Workloads Through One Reservation

ETL jobs, BI dashboards, and ad-hoc exploration have fundamentally different characteristics. ETL runs on predictable schedules with sustained compute. Dashboards need low latency but sporadic capacity. Ad-hoc queries are unpredictable in timing and resource requirements.

Separate projects by workload type to apply appropriate pricing models. Consider On-Demand for ad-hoc queries where sporadic patterns favor per-TiB pricing, and Enterprise Edition with committed slots for scheduled ETL where sustained compute favors slot-based pricing.

You can also create multiple reservations within Editions, assigning different maximum slots and priorities to different workload types. This prevents an expensive ETL job from starving interactive dashboard queries.

Testing Editions Without Commitment

Standard Edition provides a zero-commitment testing path. Create a reservation with 0 baseline and a modest maximum, assign a test project, and run representative workloads for 2-4 weeks:

-- Create autoscaling-only reservation for testing
CREATE RESERVATION `my-project.region-us.test-reservation`
OPTIONS (
  edition = 'STANDARD',
  slot_capacity = 0,
  autoscale_max_slots = 200
);

-- Create assignment linking test project to reservation
CREATE ASSIGNMENT `my-project.region-us.test-reservation.test-assignment`
OPTIONS (
  assignee = 'projects/my-test-project',
  job_type = 'QUERY'
);

Assignments take approximately 5 minutes to activate. Queries submitted during this window may fall back to On-Demand billing, so wait for propagation before running tests.

Monitor costs and performance during the test period. Compare actual slot consumption against your pre-migration estimates. Identify any workloads that perform worse with slot-based pricing.

Rollback Procedure

Rollback is straightforward. Delete the assignment and the project immediately returns to On-Demand:

DROP ASSIGNMENT `my-project.region-us.test-reservation.test-assignment`;

The change takes effect within minutes. There’s no penalty for removing assignments, making testing essentially risk-free.

Forcing On-Demand Explicitly

For organizations where a parent organization has Editions reservations but specific projects need On-Demand pricing (perhaps for cost allocation or workload isolation), assign to the special none reservation:

CREATE ASSIGNMENT `my-project.region-us.reservations/none.explicit-ondemand`
OPTIONS (
  assignee = 'projects/exempt-project',
  job_type = 'QUERY'
);

This explicitly opts the project out of any organizational reservations, ensuring On-Demand billing regardless of parent configurations.

Using the Console Slot Estimator

The BigQuery Console includes a Slot Estimator tool (Capacity Management → Slot Estimator) that models how different max slot configurations would affect historical workload performance. Input your desired maximum slots and commitment level; the tool shows estimated costs and performance impact based on your actual query history.

This provides data-driven guidance without requiring trial-and-error testing. Use it to validate your slot requirements before creating reservations.

Recent Changes Affecting Your Decision

Several 2024-2025 developments impact pricing strategy for BigQuery users.

Flat-Rate Deprecation Timeline

The flat-rate deprecation completed as of July 5, 2023. No new flat-rate, monthly, or flex slot purchases are possible. Existing annual commitments convert to Enterprise Edition at renewal with equivalent slot capacity.

Organizations still on legacy flat-rate should plan their transition carefully. The converted Enterprise Edition provides additional features (BQML, BI Engine, security controls) but may have different cost characteristics depending on your workload patterns. The slot counts transfer directly, but autoscaling behavior differs from legacy flat-rate.

200 TiB Daily Quota (September 2025)

A 200 TiB default daily quota for on-demand projects takes effect September 1, 2025. Projects without custom quotas will be hard-limited to 200 TiB of query processing daily.

For most organizations, this limit is generous (200 TiB daily is substantial). But high-volume workloads, particularly those with inefficient queries scanning large tables repeatedly, could hit this ceiling. The change provides another motivation to evaluate Editions for heavy usage patterns where slot-based pricing removes per-TiB limits entirely.

You can request quota increases through Google Cloud support, but the default will change. Review your daily query volumes to understand if this affects your workloads.

Cloud Storage Fees for External Tables (February 2025)

Starting February 2025, Google began charging previously unmetered Cloud Storage fees when querying external tables. This includes retrieval fees for Nearline, Coldline, and Archive storage classes, plus inter-region network transfer fees when data and BigQuery are in different regions.

External table queries against cold storage tiers may become significantly more expensive than historical patterns suggested. If you’re using external tables extensively, particularly against archived data, recalculate your cost models with these new fees included.

Decision Algorithm Summary

The choice between On-Demand and Editions depends on three factors: workload volume, workload characteristics, and organizational requirements. Here’s a decision tree:

Step 1: Check your monthly volume

If you process less than 10 TiB monthly, stay on On-Demand. The free tier covers the first TiB, and sporadic usage patterns favor pay-per-query economics. Editions overhead from the 60-second minimum makes it uneconomical at low volumes.

Step 2: Run the cost comparison query

For workloads between 10-50 TiB monthly, run the breakeven query against your INFORMATION_SCHEMA data. If the editions_pct_of_ondemand ratio exceeds 75%, stay on On-Demand. If below 50%, evaluate Editions further. Between 50-75%, consider other factors like concurrency needs and cost predictability.

Step 3: Evaluate feature requirements

If you need BQML, BI Engine, or security features (CMEK, VPC-SC, row/column security), note that On-Demand provides these but Standard Edition does not. You’ll need Enterprise Edition or higher to combine slot-based pricing with advanced features.

Step 4: Assess workload patterns

For workloads exceeding 50 TiB monthly with predictable patterns (scheduled ETL, regular batch processing), Editions likely provides meaningful savings, often 40-60% for compute-intensive jobs. Sporadic patterns with many short queries favor On-Demand regardless of volume.

Step 5: Consider hybrid approaches

Mixed workloads often benefit from combining pricing models. On-Demand for ad-hoc exploration and development projects where usage is unpredictable; Editions with committed slots for production ETL and BI workloads where patterns are stable and volume is high.

Final Checklist Before Switching

Before migrating to Editions, verify these steps:

• Ran cost comparison query against 90+ days of INFORMATION_SCHEMA history
• Applied 1.5x multiplier for realistic autoscaling cost estimates
• Identified P50/P75/P90 slot requirements for baseline and maximum configuration
• Tested with Standard Edition pay-as-you-go for 30+ days on representative workloads
• Optimized expensive queries (partitioning, clustering, column pruning) before migration
• Validated feature requirements (BQML, BI Engine, security controls) against Edition capabilities
• Confirmed that workload patterns favor sustained compute over sporadic short queries
• Established monitoring for slot contention and autoscaling costs post-migration

Quick Reference

Pricing Summary (US Region)

Key INFORMATION_SCHEMA Views

For job analysis and cost attribution:

• INFORMATION_SCHEMA.JOBS: Current project’s job history
• INFORMATION_SCHEMA.JOBS_BY_PROJECT: Explicit project scope
• INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION: Organization-wide view
• INFORMATION_SCHEMA.JOBS_TIMELINE: Second-by-second slot consumption

For reservation management:

• INFORMATION_SCHEMA.RESERVATIONS: Reservation configurations
• INFORMATION_SCHEMA.ASSIGNMENTS: Project-to-reservation mappings
• INFORMATION_SCHEMA.CAPACITY_COMMITMENTS: Active slot commitments

Autoscaling Rules of Thumb

• Minimum billing: 60 seconds per scaling event
• Scaling increments: 50 slots
• Scale-up latency: ~10 seconds
• Cost multiplier for estimates: 1.5× theoretical slot-hours
• Recommended max_slots starting point: P90 of historical usage
• Recommended baseline: 60-80% of P50 for cost-optimized configurations

The best pricing model is the one validated by your actual usage patterns, not industry benchmarks or theoretical calculations. Run the queries, test with real workloads, and let the data guide your decision.