BigQuery náklady 2026: Ako ušetriť 40–70 % na Editions, slotoch a storage

Aktualizované: 5. septembra 2026

Optimalizácia nákladov BigQuery v roku 2026 stojí na štyroch pilieroch: správnom výbere medzi Editions (Standard/Enterprise/Enterprise Plus) a on-demand modelom, kapacitných rezerváciách slotov, prechode na physical storage billing a systematickom partitioning + clustering. Ak tieto štyri veci nasadíte spolu a doplníte ich materialized views a analýzou INFORMATION_SCHEMA.JOBS, u typického analytického skladu viete reálne dosiahnuť úsporu 40–70 % bez toho, aby sa to dotklo latencie dashboardov. V nasledujúcom playbooku vás prevediem presne cez postup, ktorý som ladil na produkcii s workloadom niekoľko PB. Honestly, prekvapilo ma, ako často tie najdrahšie chyby robia inak skúsené tímy.

• Od júla 2023 nahradili BigQuery Editions starý flat-rate model a v 2026 sú v troch úrovniach: Standard (0,04 USD/slot-hodina), Enterprise (0,06 USD) a Enterprise Plus (0,10 USD). Výber závisí od potreby CMEK, cross-region a governance.
• On-demand cena je 6,25 USD za spracovaný TB (5 USD do 300 TB/mesiac po commite). Pre workload s pravidelným využitím nad ~2 slot-roky ročne je Editions vždy lacnejší.
• Physical storage billing je typicky 4 až 8× lacnejší ako logical (0,02 USD/GB aktívne vs 0,02 USD/GB pre logical + kompresia), pretože účtuje reálne uložené bajty po kompresii.
• Partitioning na časovej osi + clustering na najčastejšie filterované stĺpce znižuje bytes billed pri typickom dopyte o 60 až 90 %.
• Materialized views v 2026 podporujú aj joiny a agregácie s automatickým rewrite, takže drahé dashboard dopyty sa dajú incrementálne cache-ovať bez ETL kódu.
• Query INFORMATION_SCHEMA.JOBS_BY_PROJECT filter na total_bytes_billed odhalí top 20 dopytov, ktoré typicky generujú 80 % nákladov (zvyčajne 3 až 5 zle napísaných dashboardov).

Prečo BigQuery účet rastie exponenciálne

Vo väčšine tímov, s ktorými som pracoval, BigQuery faktúra nerastie preto, že by sa zdvojnásobil objem dát. Rastie preto, že sa zdvojnásobí počet dashboardov v Lookerovi alebo Looker Studio. Každý nový tile robí SELECT * nad tou istou 50 TB tabuľkou, každých 15 minút, a vy zrazu platíte 300 USD denne za jeden panel, ktorý si nikto neotvorí.

V BigQuery pricingu z novembra 2025 platia dve nezávislé osi: compute (spracovanie dopytov) a storage (uložené bajty). Compute sa účtuje buď per-TB spracovaných bajtov (on-demand) alebo per-slot-hodina (Editions). Storage má dva samostatné režimy, logical (nekompresované bajty) a physical (reálne bajty na disku po kompresii Capacitor formátu). K tomu prirátajte streaming inserts (0,05 USD/GB), storage API reads (1,10 USD/TB), BigQuery Omni cross-cloud transfers a v roku 2026 aj gen AI funkcie ML.GENERATE_TEXT účtované cez Vertex AI. Ak niektorú z týchto osí neriadite explicitne, faktúra vám každé Q rastie o 20 až 40 %.

V praxi ma najviac prekvapili tri vzory: (1) analytici, ktorí testujú dopyty na produkčnom datasete namiesto sample, (2) ETL pipeline, ktorá každú hodinu prepisuje kompletnú tabuľku namiesto MERGE, a (3) dashboardové autorefresh intervaly nastavené na 1 minútu, hoci nikto nesedí pri obrazovke o 3:00 v noci. Skôr než začnete ladiť sloty, tieto tri veci vyriešte na governance úrovni. Inak žiaden pricing model nezachráni situáciu.

BigQuery Editions vs on-demand: čo si vybrať v 2026

Od 5. júla 2023 Google zrušil klasický flat-rate model a nahradil ho troma úrovňami BigQuery Editions. V roku 2026 sú ceny stabilizované na týchto hladinách (us-central1, on-demand slot pricing bez commitmentu):

Vlastnosť	On-demand	Standard	Enterprise	Enterprise Plus
Jednotka účtovania	TB spracovaných	Slot-hodina	Slot-hodina	Slot-hodina
Cena (pay-as-you-go)	6,25 USD/TB	0,04 USD	0,06 USD	0,10 USD
1-ročný commitment	N/A	-20 %	-20 %	-20 %
3-ročný commitment	N/A	-40 %	-40 %	-40 %
Autoscaling slotov	N/A	áno	áno	áno
CMEK / VPC-SC	áno	nie	áno	áno
Cross-region replikácia	N/A	N/A	N/A	áno
Materialized views	áno	áno	áno	áno

Rozhodovacie pravidlo, ktoré používam: ak váš mesačný compute spend presiahne ~2 000 USD a máte relatívne predvídateľnú záťaž (denné ETL + dashboardy), Editions Standard s autoscalingom bude vždy lacnejší. Ak máte ad-hoc analytiku raz za týždeň, zostaňte na on-demand, platíte len za spracované bajty a nemáte fixný náklad.

Pozor na jednu pascu: Standard Edition nemá CMEK ani VPC Service Controls. Ak máte compliance požiadavku na custom encryption keys, potrebujete minimálne Enterprise. V regulovanom finsektore alebo verejnom sektore v SR/CZ toto býva blocker, o ktorom sa zabudne v RFP a potom sa musí meniť edition po pol roku. (Zažil som to. Neodporúčam.)

Praktický príklad: klient s 12 TB denne spracovanými pri on-demand platil ~2 250 USD/deň. Prechod na Enterprise Standard so 100 baseline slotmi a autoscalingom do 500 znížil compute na ~650 USD/deň. S 3-ročným commitmentom na 100 slotov (0,024 USD/slot-hodina) padol náklad na baseline kapacite na 172 USD/deň, autoscale slots pay-as-you-go dobiehali. Celková úspora: 68 %.

Ako fungujú sloty a kapacitné rezervácie v 2026

Slot je jednotka výpočtu. Google ho definuje ako približne 0,5 vCPU + ~0,5 GB RAM alokovaného na paralelnú fázu dopytu. Jeden dopyt môže dostať 100, 1000 aj 10 000 slotov zároveň, podľa toho, koľko má váš projekt alokovaných a či prebieha slot contention.

Reservations a assignments

V Editions modeli si kúpite capacity commitment (napr. 500 slotov na rok), z ktorého vytvoríte jednu alebo viac reservations (napr. etl-nightly = 300 slotov, bi-workload = 200 slotov). Cez assignments priradíte konkrétne projekty alebo folders k reservation. Toto vám dáva multi-tenant workload isolation bez toho, aby jeden runaway dopyt v marketingovom projekte spomalil finančný reporting.

-- Vytvorenie reservation s baseline 100 slotov a autoscalingom do 500
CREATE RESERVATION `my-project.region-us.bi-workload`
OPTIONS (
  slot_capacity = 100,
  edition = 'ENTERPRISE',
  autoscale_max_slots = 500,
  ignore_idle_slots = false
);

-- Priradenie projektu k reservation
CREATE ASSIGNMENT `my-project.region-us.bi-workload.bi-assignment`
OPTIONS (
  assignee = 'projects/analytics-prod',
  job_type = 'QUERY'
);

Idle slot sharing

Ak nastavíte ignore_idle_slots = false, nevyužité sloty z jednej reservation môže dočasne požičať iný workload v tej istej administration project. Toto je jeden z najpodceňovanejších trikov. U jedného klienta som týmto znížil potrebnú baseline kapacitu z 800 na 500 slotov, pretože nočný ETL a denný BI workload sú komplementárne.

Autoscaling za slot-second

Od Q3 2024 sa autoscale sloty účtujú per-second, nie per-minute. Ak vám autoscale pridá 200 slotov na 12 sekúnd počas špičky, platíte za 12 sekúnd × 200 slotov = 40 slot-seconds. Toto zásadne mení ekonomiku spiky workloadu, nemusíte overprovisionovať baseline.

Physical storage billing: prečo prepnúť už dnes

V roku 2022 Google spustil physical storage billing model a v 2026 je to jedna z najjednoduchších optimalizácií vôbec, často aj bez rizika. BigQuery interne ukladá dáta v stĺpcovom Capacitor formáte s agresívnou kompresiou (zvyčajne 4 až 10× v závislosti od typu dát). V logical režime však platíte za nekompresovanú veľkosť, teda za to, čo by tabuľka zaberala ako CSV.

Ceny v us-central1, november 2025:

• Logical storage: aktívne 0,020 USD/GB/mesiac, long-term (90+ dní bez zmeny) 0,010 USD/GB/mesiac
• Physical storage: aktívne 0,040 USD/GB/mesiac, long-term 0,020 USD/GB/mesiac + time travel a fail-safe

Cena za GB v physical modeli je 2× vyššia, ALE fyzická veľkosť po kompresii je typicky 4 až 10× menšia. Efektívna úspora: 50 až 80 %. Overte si to na svojom datasete cez INFORMATION_SCHEMA.TABLE_STORAGE view:

SELECT
  table_schema AS dataset,
  SUM(total_logical_bytes) / POW(1024, 4) AS logical_tib,
  SUM(total_physical_bytes) / POW(1024, 4) AS physical_tib,
  SAFE_DIVIDE(SUM(total_logical_bytes), SUM(total_physical_bytes)) AS compression_ratio,
  ROUND(SUM(total_logical_bytes) / POW(1024, 3) * 0.02, 2) AS monthly_logical_usd,
  ROUND(SUM(total_physical_bytes) / POW(1024, 3) * 0.04, 2) AS monthly_physical_usd
FROM `region-us`.INFORMATION_SCHEMA.TABLE_STORAGE
GROUP BY dataset
ORDER BY logical_tib DESC;

Ak compression_ratio vyjde vyššie ako 2,0, prepnutie sa oplatí. Prepínanie sa robí per-dataset príkazom ALTER SCHEMA a je jednosmerné počas 14 dní (potom môžete znova prepnúť). Testujte najprv na jednom staging datasete.

Partitioning a clustering: základ každej úspory

Toto je najbanálnejší, ale zároveň najúčinnejší tip. A stále to vidím zle nastavené u 70 % klientov. Partitioning rozdelí tabuľku na fyzicky separátne bloky podľa jedného stĺpca (typicky dátum), takže dopyt s WHERE date = '2026-09-01' číta iba 1/365 dát. Clustering zoradí dáta v rámci partitionu podľa až 4 stĺpcov, čo umožňuje ďalšie prefiltrovanie blokov.

Kedy použiť ktoré

• Partitioning: ak máte časovú os (event_time, created_at) a väčšina dopytov filtruje na časový rozsah. Alternatívy: integer range partitioning, ingestion time.
• Clustering: ak máte high-cardinality kategorický stĺpec (user_id, product_sku, region), na ktorý sa často joinuje alebo filtruje. Efekt: 30 až 70 % redukcia bytes billed nad rámec partitioning.

CREATE OR REPLACE TABLE analytics.events
PARTITION BY DATE(event_time)
CLUSTER BY user_id, event_name
OPTIONS (
  partition_expiration_days = 730,  -- automatické mazanie po 2 rokoch
  require_partition_filter = true    -- vynúti WHERE na partition stĺpec
)
AS SELECT * FROM analytics.events_staging;

require_partition_filter = true je jeden z najdôležitejších flagov, ktorý majte na produkčných tabuľkách zapnutý. Akýkoľvek dopyt bez WHERE na partition stĺpec zlyhá s errorom miesto toho, aby ticho zoscanoval 5 TB. Toto samotné mi u jedného klienta ušetrilo 8 000 USD za mesiac po tom, čo omylom skončil dashboard s WHERE date >= '2020-01-01'. (Áno, mal som ten mail v inbox-e ako varovanie na tvrdšie defaults.)

Partition pruning verifikácia

Vždy po zmene schémy overte v query plane, že sa naozaj deje pruning. V UI kliknite Execution details → sekcia Bytes billed vs Bytes processed. Ak Bytes billed = celková veľkosť tabuľky, partitioning nefunguje (typicky preto, že máte WHERE DATE(event_time) = ... namiesto WHERE event_time BETWEEN ... AND ...).

Materialized views, BI Engine a query cache

V 2026 sú materialized views v BigQuery výrazne mocnejšie ako v roku 2022. Podporujú joiny, väčšinu agregačných funkcií (COUNT DISTINCT cez HLL), a majú automatic refresh na základe base table changes. Query optimizer robí smart tuning a automaticky prepíše aj dopyty, ktoré priamo nereferenceujú view, ak sa dá odpoveď zložiť z MV.

CREATE MATERIALIZED VIEW analytics.daily_revenue_by_country
PARTITION BY event_date
CLUSTER BY country
OPTIONS (
  enable_refresh = true,
  refresh_interval_minutes = 30,
  max_staleness = INTERVAL 1 HOUR
)
AS
SELECT
  DATE(event_time) AS event_date,
  country,
  COUNT(DISTINCT user_id) AS unique_users,
  SUM(amount_usd) AS revenue_usd
FROM analytics.events
WHERE event_name = 'purchase'
GROUP BY 1, 2;

Kľúčové je max_staleness. Od Q1 2024 môžete povoliť staršie dáta a MV sa nemusí refreshnúť pri každom insertu do base tabuľky. Kombinácia refresh_interval_minutes = 30 + max_staleness = 1 hour dá dashboardom pocit real-time bez toho, aby ste platili za nepretržitý incremental refresh.

BI Engine: in-memory cache pre Looker Studio

BI Engine je in-memory columnar cache s 1 GB free tier a Enterprise pricingom 0,0416 USD/GiB-hodinu. Pre dashboard workload dokáže znížiť latenciu z 3 sekúnd na 200 ms a zároveň odbremeniť sloty. Ak máte v Looker Studio dashboard, ktorý sa denne otvára 500× nad tou istou 20 GB agregáciou, BI Engine s 32 GiB reservation vás bude stáť ~1 USD/deň a ušetrí desiatky slot-hodín.

Query results cache je zadarmo, využívajte ho

Každý deterministický dopyt sa cache-uje 24 hodín zadarmo. Ak však používate CURRENT_TIMESTAMP(), RAND() alebo external tables, cache sa invaliduje. Prepíšte WHERE event_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) na hodinovú granularitu (TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), HOUR)), aby sa cache trafila do rovnakej hodiny.

Analýza drahých dopytov cez INFORMATION_SCHEMA

Toto je štandardný prvý krok každého FinOps audit projektu. INFORMATION_SCHEMA.JOBS_BY_PROJECT (alebo _BY_ORGANIZATION pre celý enterprise view) obsahuje históriu 180 dní všetkých dopytov s presnými metrikami. Kompletnú schému nájdete v oficiálnej dokumentácii JOBS view.

-- TOP 20 najdrahších dopytov za posledných 7 dní
SELECT
  user_email,
  query,
  total_bytes_billed / POW(1024, 4) AS tib_billed,
  ROUND(total_bytes_billed / POW(1024, 4) * 6.25, 2) AS ondemand_cost_usd,
  total_slot_ms / 1000 / 3600 AS slot_hours,
  COUNT(*) OVER (PARTITION BY REGEXP_REPLACE(query, r'\d+', '')) AS occurrences,
  creation_time
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
  AND error_result IS NULL
ORDER BY total_bytes_billed DESC
LIMIT 20;

Pareto princíp platí bez výnimky. U každého klienta v top 20 nájdem 3 až 5 dopytov, ktoré generujú 60 až 80 % celého compute nákladu. Zvyčajne ide o Looker dashboard tile bez cache, ETL query, ktorý robí SELECT * namiesto stĺpcov, alebo o Airflow task, ktorý reprocessuje celú historickú tabuľku pri každom runu.

Detekcia data scan hotspotov

-- Ktoré tabuľky sú najviac skenované?
SELECT
  destination_table.dataset_id AS dataset,
  destination_table.table_id AS table_name,
  SUM(total_bytes_processed) / POW(1024, 4) AS tib_scanned,
  COUNT(*) AS query_count,
  APPROX_QUANTILES(total_bytes_processed, 100)[OFFSET(50)] / POW(1024, 3) AS p50_gib_per_query
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT,
UNNEST(referenced_tables) AS destination_table
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
GROUP BY dataset, table_name
ORDER BY tib_scanned DESC
LIMIT 30;

Tabuľky v top 10 sú kandidáti na (a) partitioning/clustering, (b) materialized view alebo (c) pre-aggregated summary tabuľku. Rovnaký princíp platí ako pri optimalizácii Snowflake warehouse credits, hot tabuľky sú vždy prvý cieľ.

8 anti-patternov, ktoré vám žerú BigQuery kredit

1. SELECT * na wide tabuľkách. BigQuery je stĺpcový sklad, vyberte len stĺpce, ktoré potrebujete. Rozdiel medzi SELECT * a SELECT id, name na 300-stĺpcovej tabuľke býva 100×.
2. WHERE DATE(timestamp_col) = '2026-09-01'. Obal DATE() zabráni partition pruningu. Použite WHERE timestamp_col BETWEEN '2026-09-01' AND '2026-09-02'.
3. Ne-partitioned append-only tabuľky. Ak máte event log bez partition, každý dopyt scanuje celú históriu. Migrujte cez CREATE TABLE ... PARTITION BY ... AS SELECT ....
4. Streaming inserts pre nekritické dáta. Streaming API je 0,05 USD/GB, teda 25× drahšie ako batch load. Ak nepotrebujete sub-minútovú latenciu, použite batch loading zdarma.
5. UDF v JavaScripte namiesto SQL. JS UDF sú 5 až 10× pomalšie a bránia predicate pushdown. Prepíšte na SQL UDF alebo built-in funkcie.
6. Cross-region JOINs. BigQuery neúčtuje network transfer v rámci regiónu, ale cross-region kopírovanie stojí 0,02 USD/GB. Držte súvisiace datasety v tom istom regióne.
7. Bez _TABLE_SUFFIX na sharded tabuľkách. Legacy wildcard tabuľky (events_*) bez filtra na _TABLE_SUFFIX scanujú všetky shardy. Radšej migrujte na jednu partitioned tabuľku.
8. Autorefresh dashboardov v noci. Nastavte Looker/Looker Studio refresh len na pracovné hodiny. Kombinujte s tagging stratégiou pre alokáciu cloudových nákladov pre lepšiu attribúciu tímom.

FinOps governance a alerty pre BigQuery

Optimalizácia bez governance je jednorazová akcia. O pol roka je faktúra späť. Odporúčam tri vrstvy:

1. Custom cost controls per projekt

V BigQuery môžete nastaviť maximum_bytes_billed na projekt aj user level. Ak analytik omylom pošle 500 TB dopyt, ten sa nespustí. Nastavte to cez bq CLI:

bq update --maximum_bytes_billed=1099511627776 my-project:analytics
# 1 TiB limit per query v datasete analytics

2. Budget alerty a anomaly detection

Cloud Billing Budgets s alertom na 50 %, 80 %, 100 % a 120 % prahoch. Kombinujte s Cost Anomaly Detection (v GA od 2024), ktorý pošle Pub/Sub notifikáciu, ak spend odbočí od baseline. Podrobný postup som opísal v článku o FOCUS špecifikácii pre multi-cloud fakturáciu. Rovnaké princípy platia pre BigQuery-only workloady.

3. Query approval workflow pre nové dashboardy

Pre teams s viac než 20 analytikmi zaveďte pravidlo: každý nový Looker dashboard alebo scheduled query musí prejsť review, ktorý overí (a) bytes billed pri typickom scope, (b) prítomnosť partition filtra, (c) alternatívu cez existujúci materialized view. Formalizovať sa to dá cez BigQuery projects.dryRun API v CI/CD pipeline pre LookML zmeny.

Často kladené otázky

Koľko stojí BigQuery za spracovaný TB v roku 2026?

On-demand cena je 6,25 USD za spracovaný TB v us-central1 (5 USD za TB po prekročení 300 TB/mesiac s committed use). Prvý 1 TB mesačne je zdarma. Ceny sa mierne líšia podľa regiónu, napr. europe-west3 (Frankfurt) je 7,50 USD/TB.

Aký je rozdiel medzi BigQuery Editions a on-demand pricingom?

On-demand účtuje 6,25 USD za spracovaný TB bez fixného nákladu, vhodné pre ad-hoc analytiku. Editions (Standard/Enterprise/Enterprise Plus) účtuje slot-hodiny (0,04 až 0,10 USD) a hodí sa pre pravidelné workloady s ročným commitmentom zľavou až 40 %.

Ako zistím, ktoré BigQuery dopyty stoja najviac?

Cez INFORMATION_SCHEMA.JOBS_BY_PROJECT filter na total_bytes_billed zoradený DESC za posledných 7 dní. Typicky 3 až 5 dopytov generuje 60 až 80 % nákladu, väčšinou dashboard tiles bez cache alebo ETL bez partition filtra.

Kedy sa oplatí prepnúť na physical storage billing?

Vždy, keď váš compression ratio (logical bytes / physical bytes) presiahne 2,0. To platí pre 90 % analytických tabuliek. Overte cez INFORMATION_SCHEMA.TABLE_STORAGE a prepnite cez ALTER SCHEMA ... SET OPTIONS (storage_billing_model = 'PHYSICAL').

Pomáha clustering, ak už mám tabuľku partitionovanú?

Áno. Clustering pridáva 30 až 70 % redukciu bytes billed nad rámec partitioning, hlavne pri filtroch alebo JOIN-och na high-cardinality stĺpce (user_id, product_sku). Kombinácia partitioning + clustering je štandard pre každú tabuľku nad 100 GB.

Ako nastavím limit, aby analytik nespustil 500 TB dopyt?

Cez bq update --maximum_bytes_billed=<bytes> na úrovni projektu, alebo priamo v query cez --maximum_bytes_billed flag. Dopyt nad limit sa nespustí a vráti error, čím ochránite faktúru pred omylom.