BigQuery: rezerwacje slotów vs on-demand w 2026 – jak zoptymalizować koszty analityki w GCP

Zaktualizowano: 14 września 2026

Rezerwacje slotów BigQuery zaczynają się opłacać w momencie, w którym Twoje miesięczne wydatki na zapytania on-demand przekraczają ok. 2 000 USD przy przewidywalnym profilu obciążenia; powyżej tej wartości commitment Enterprise (1-year) daje od 20% do 40% oszczędności, zwłaszcza jeśli włączysz autoscaling. W 2026 roku, po całkowitym wygaszeniu starego flat-rate na rzecz modelu BigQuery Editions, decyzja „sloty czy on-demand" wymaga analizy nie tylko wolumenu, ale też stabilności i wzorca zapytań w ciągu doby. Szczerze mówiąc, sam popełniłem ten błąd raz i migrowałem klienta na sloty za wcześnie — więcej o tym w case studies poniżej.

• On-demand kosztuje 6,25 USD za każdy TiB przeskanowanych danych, sloty rezerwowane w Enterprise Edition 0,06 USD za slot-godzinę (pay-as-you-go) lub 0,048 USD z rocznym commitmentem.
• Próg opłacalności rezerwacji przy stałym obciążeniu 100 slotów (autoscaling, 1-year Enterprise) wypada w okolicach 350 GB skanowanych dziennie, niżej niż wielu FinOps-owców zakłada.
• Autoscaling reservations pozwalają zbić baseline do zera i płacić tylko za slot-sekundy, ale mają 60-sekundowe „lepkie" skalowanie w górę i minimalną granulację 100 slotów.
• Enterprise Plus jest wymagany do CMEK, Cross-region replication i BigQuery Omni; Enterprise wystarczy do 95% typowych analitycznych workloadów.
• Materialized views, partycjonowanie i klastrowanie potrafią obniżyć zużycie slotów o 40–70%, więc zoptymalizuj kwerendy PRZED zakupem commitmentów.
• Rozdziel obciążenia produkcyjne, dev i ad-hoc na osobne rezerwacje z priorytetami, bo inaczej jeden analityk potrafi wchłonąć całą pulę slotów.

Cennik BigQuery w 2026: co się zmieniło po wygaszeniu flat-rate

Do lipca 2023 roku BigQuery miał trzy modele rozliczeniowe: on-demand, flat-rate (miesięczne/roczne commitmenty w slotach) oraz Flex Slots. Google wprowadził wtedy BigQuery Editions i po ostatnich zmianach cennikowych z pierwszej połowy 2026, jest to praktycznie jedyny sposób kupowania mocy obliczeniowej poza on-demand. Stare kontrakty flat-rate wygasają i klienci są migrowani na Editions, zwykle Enterprise, chyba że wymagają CMEK, VPC-SC dla zapytań cross-region albo Assured Workloads (wtedy Enterprise Plus).

Editions to trzy warstwy funkcjonalne (Standard, Enterprise, Enterprise Plus) plus dwa modele commitmentu (pay-as-you-go za slot-sekundę i rezerwacje z autoscalingiem). Cena za slot-godzinę rośnie wraz z warstwą: Standard 0,04 USD, Enterprise 0,06 USD, Enterprise Plus 0,10 USD. Roczny commitment daje 20% zniżki, trzyletni 40%. Do tego dochodzi storage (od 2023 rozdzielony na aktywny i długoterminowy, opcjonalnie physical storage billing z kompresją). W praktyce w rachunku typowego zespołu analitycznego kompleks compute stanowi 70–85% wszystkich kosztów BigQuery.

Warto zaznaczyć: on-demand nie zniknął. W dokumentach Google Cloud BigQuery pricing jest wyraźnie utrzymany, wciąż kosztuje 6,25 USD za TiB przeskanowanych danych (pierwszy 1 TiB miesięcznie w free tier). Zmiana polega na tym, że dla dużych, przewidywalnych obciążeń Editions są prawie zawsze tańsze, a on-demand traktujemy jak „domyślne SLA na piku ruchu" oraz jako runtime dla ad-hoc queries analityków.

On-demand vs rezerwacje slotów: bezpośrednie porównanie

Poniżej zestawienie obu modeli w kluczowych wymiarach. To samo porównanie robię co kwartał przy przeglądzie kontraktów z Google, bo cennik i limity potrafią się zmienić między jednym audytem a drugim.

Wymiar	On-demand	Rezerwacje slotów (Enterprise, 1-year)
Jednostka rozliczania	TiB przeskanowanych danych	Slot-sekunda
Cena bazowa	6,25 USD / TiB	0,048 USD / slot-godz. (baseline)
Kontrola kosztów	Trudna, każdy analityk może wygenerować duży skan	Deterministyczna, nie zapłacisz więcej niż max slots × cena
SLA opóźnienia	Współdzielona pula GCP, brak gwarancji	Dedykowane sloty, przewidywalny czas
Autoskalowanie	Nie dotyczy (rozliczenie per zapytanie)	Tak, granulacja 100 slotów, „lepkość" 60 s
Idle koszt	0 USD	Baseline × cena (jeśli baseline > 0)
Idealny profil	Sporadyczne kwerendy, dev/test, POC	Powtarzalne pipeline'y, dashboardy, ELT o stałych porach

Krótko: on-demand kupujesz gotowość, sloty kupujesz przepustowość. W on-demand nie martwisz się o pojemność (Google to problem), ale za każde 40 GB skanowane po raz kolejny płacisz ok. 0,25 USD. W rezerwacjach masz sztywny sufit i wszystko poniżej niego jest „darmowe" ze skarbowego punktu widzenia zespołu.

Kiedy przełączyć się z on-demand na sloty rezerwowane?

To pytanie zadaje mi każdy zespół, z którym pracuję. Uczciwa odpowiedź to: „to zależy od dwóch liczb, miesięcznego skanu w TiB i współczynnika zmienności obciążenia". Mam prostą regułę kciuka, którą wypracowałem po tym, jak przemigrowałem cztery zespoły analityczne w Monzo:

• Poniżej 300 TiB/miesiąc skanu (~1 875 USD on-demand): zostań na on-demand. Overhead operacyjny rezerwacji nie zwróci się.
• 300–1 000 TiB/miesiąc: rozważ Enterprise pay-as-you-go z autoscalingiem. Nie musisz podpisywać commitmentu.
• Powyżej 1 000 TiB/miesiąc ze stabilnym profilem: 1-year commitment Enterprise, baseline pokrywający 40–60% średniego zużycia.
• Powyżej 5 000 TiB/miesiąc: 3-year commitment jest niemal zawsze zwycięski, 40% zniżki + negocjacyjny lewar EDP (Enterprise Discount Program).

Konkretny przykład kalkulacji progu opłacalności. Załóżmy, że zespół skanuje średnio 40 TiB dziennie i ma szczyty do 120 TiB w piątkowe zamknięcia miesiąca. On-demand kosztuje 40 × 30 × 6,25 USD ≈ 7 500 USD/mies. Rezerwacja 500 slotów autoscaling Enterprise (roczny commitment na 200 slots baseline, autoscale do 500), z mojego doświadczenia obsłuży ten profil w ok. 60% czasu na baseline, resztę w autoscale. Rachunek: 200 slotów × 730 h × 0,048 USD + ~300 slot × 200 h/mies × 0,06 USD ≈ 7 008 USD + 3 600 USD = 10 608 USD/mies. Wygląda drożej!

W czym haczyk? On-demand skan 40 TiB to po zoptymalizowaniu. Realnie zespoły on-demand skanują dwu- lub trzykrotnie więcej, bo nikt nie patrzy na koszty pojedynczego zapytania. Po tygodniu profilowania zwykle okazuje się, że rzeczywisty skan to 90–120 TiB dziennie, co daje 16 875–22 500 USD on-demand vs. 10 608 USD w slotach. To jest realna oszczędność 37–53%.

Czym różnią się BigQuery Editions Standard, Enterprise i Enterprise Plus?

Wybór Edition nie sprowadza się do „ile chcę wydać". Każda warstwa odblokowuje inne funkcje enterprise'owe, których zabraknie w niższej. Szczegółowa specyfikacja jest w oficjalnej dokumentacji Editions, ale poniżej moje praktyczne uwagi z terenu.

Standard (0,04 USD/slot-godz.)

Podstawowa edycja przewidziana dla zespołów, które nie potrzebują governance-owych bajerów. Brak dostępu do materialized views, brak BI Engine, brak column-level security. Nie polecam do środowisk produkcyjnych; oszczędność 0,02 USD za slot-godzinę zamienia się w miesiące pracy inżyniera, którego zatrudnisz, żeby ręcznie zarządzać cachem i uprawnieniami. Standard trzymam wyłącznie w projektach dev/sandbox, gdzie autoscaling 0→100 slotów obsługuje jednego, dwóch analityków testowych.

Enterprise (0,06 USD/slot-godz.), domyślny wybór

To edycja, którą stawiam każdemu klientowi jako punkt startowy. Zawiera materialized views z automatycznym refreshem, BI Engine (reserved memory dla Looker Studio i Data Studio), column i row-level security, Search Indexes i Vector Search (kluczowe dla RAG-owych obciążeń AI, patrz nasz przewodnik po FinOps dla AI/ML w 2026). Autoscaling działa w pełni, można kupować roczne i trzyletnie commitmenty. 95% moich klientów zostaje na Enterprise na stałe.

Enterprise Plus (0,10 USD/slot-godz.)

Warstwa dla regulowanych sektorów: banki, ubezpieczenia, farmacja, sektor publiczny. Dodaje CMEK (customer-managed encryption keys) na tabelach i zapytaniach, Cross-region replication zestawów danych, Assured Workloads zgodne z FedRAMP High, ITAR i wymaganiami suwerenności danych UE. Wspiera też BigQuery Omni, czyli zapytania federacyjne do S3 i Azure Blob Storage bez wymuszania kopii do GCS. W Monzo używałem tej edycji dla domeny płatności ze względu na compliance PCI DSS. Dla reszty analityki (produkt, marketing, oszustwa) wystarczał Enterprise.

Jak oszacować zużycie slotów przed zakupem rezerwacji

Nie kupuj slotów „na oko". BigQuery udostępnia widok INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT, który minutę po minucie pokazuje, ile slot-sekund pochłonęły twoje zapytania. Poniższa kwerenda to mój ulubiony punkt wyjścia i uruchamiam ją zaraz po pierwszym kontakcie z klientem, żeby zobaczyć realną charakterystykę obciążenia.

-- 14-dniowy profil zużycia slotów w oknach 1-minutowych
DECLARE start_ts TIMESTAMP DEFAULT TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY);

SELECT
  TIMESTAMP_TRUNC(period_start, MINUTE) AS ts,
  SUM(period_slot_ms) / 60000.0 AS slots_in_use, -- ms → sloty w minucie
  COUNT(DISTINCT job_id) AS concurrent_jobs
FROM `region-eu`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT
WHERE period_start >= start_ts
  AND statement_type != 'SCRIPT' -- ignoruj wrapper joby proceduralne
GROUP BY ts
ORDER BY ts;

Wynik importujesz do Looker Studio i rysujesz heatmapę „godzina × dzień tygodnia". Zwykle wyłania się bardzo wyraźny wzór: pipeline'y ELT odpalają się o 02:00–06:00 UTC (pik 800–1 500 slotów), dashboardy dla PM-ów około 09:00–17:00 (200–400 slotów baseline), weekend prawie zero. To jest gotowa mapa pod konfigurację autoscaling reservation: baseline 200, max slots 1 500.

Druga kluczowa kwerenda oblicza koszt każdego pojedynczego zapytania w slot-sekundach, bezpośrednio porównywalna z on-demand:

-- Top 50 najkosztowniejszych zapytań ostatnich 7 dni
SELECT
  job_id,
  user_email,
  ROUND(total_slot_ms / 1000 / 60, 2) AS slot_minutes,
  ROUND(total_bytes_processed / POW(1024, 4), 3) AS tib_scanned,
  ROUND(total_bytes_processed / POW(1024, 4) * 6.25, 2) AS on_demand_usd,
  ROUND(total_slot_ms / 1000 / 3600 * 0.06, 4) AS enterprise_usd,
  SUBSTR(query, 1, 120) AS query_preview
FROM `region-eu`.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_slot_ms DESC
LIMIT 50;

Kolumny on_demand_usd i enterprise_usd pokazują, dla których zapytań model rezerwacji już wygrywa. W moich audytach zawsze znajduję 5–10 „potworów", czyli kwerend, które w on-demand kosztują po 40–200 USD za odpalenie, a w Enterprise 3–15 USD. Tłumaczę wtedy zespołowi: „jeśli te 10 kwerend odpala się co godzinę, jesteście po stronie strat".

Autoscaling reservations: konfiguracja i pułapki, które kosztują

Autoscaling BigQuery jest genialny w koncepcji, ale ma trzy pułapki, o których dokumentacja mówi cicho. Trafiłem na wszystkie trzy przy pierwszej migracji i chcę oszczędzić Ci tego samego bólu.

Pułapka 1: 60-sekundowa „lepkość" skalowania

Kiedy autoscaler doskaluje sloty w górę, trzyma je przez co najmniej 60 sekund nawet jeśli zapytanie skończyło się w 5 sekund. Płacisz za pełną minutę. Jeśli masz 500 zapytań dziennie po 3–5 sekund każde, każde przez chwilę potrzebuje np. 300 dodatkowych slotów; w praktyce wszystkie te „szczyty" płacisz jak minutę na 300 slotach. Rozwiązanie: użyj reservations assignments z priorytetami i wrzuć małe zapytania interaktywne do rezerwacji z wyższym baseline, a nie do autoscaling.

Pułapka 2: Granulacja 100 slotów

Nie zaczniesz od 50 slotów. Nie zaczniesz od 150. Nowa rezerwacja w Editions ma minimum 100 slotów, autoscale schodzi w blokach po 100. Dla małych projektów oznacza to, że każde odpalenie zapytania musi się zmieścić w 100-slotowej alokacji, inaczej stoi w kolejce lub eskaluje do 200. Planuj to świadomie: małe projekty lepiej wsadzić do współdzielonej rezerwacji na poziomie folderu w Resource Manager.

Pułapka 3: Idle slots vs. multi-tenant reservations

Jeśli utworzysz kilka rezerwacji (np. prod, dev, ad-hoc) i jedna ma nieużywane sloty, domyślnie nie są one udostępniane innym. Musisz włączyć flagę ignoreIdleSlots = false przy assignment i skonfigurować kolejność żarłoczności przez concurrency. Bez tego zespoły płacą podwójnie, bo prod stoi na baseline, a dev wchodzi w autoscaling.

Optymalizacja kwerend przed zakupem commitmentów

Największym błędem, jaki widzę u nowych klientów, jest kupowanie slotów, żeby „naprawić" wolne zapytania. To odwrotny porządek. Najpierw zoptymalizuj SQL, bo często obniża to zużycie slotów o połowę, więc kupujesz połowę commitmentu. Kilka technik, które daję jako pierwsze do wdrożenia:

Partycjonowanie i klastrowanie

Każda tabela > 10 GB, do której odwołuje się więcej niż 5 zapytań dziennie, powinna być partycjonowana (najczęściej po DATE lub _PARTITIONTIME) i klastrowana po 2–4 kolumnach, po których najczęściej filtrujesz. To zwykle jednorazowa robota na 2–3 dni, a redukuje skan o 60–90%.

-- Migracja istniejącej tabeli na partycjonowaną + klastrowaną
CREATE OR REPLACE TABLE `analytics.events_partitioned`
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_name, country_code
AS SELECT * FROM `analytics.events_flat`;

-- Zmiana referencji w downstream views:
CREATE OR REPLACE VIEW `analytics.events` AS
SELECT * FROM `analytics.events_partitioned`;

Materialized views

Jeśli 20 dashboardów pobiera tę samą agregację z tej samej tabeli, przenieś ją do materialized view z automatycznym refreshem co 30 minut. Koszt refreshu < koszt 20 zapytań ad hoc. Refresh też idzie ze slotów rezerwacji, więc żadnego dodatkowego rachunku on-demand.

BI Engine dla dashboardów

Do dashbordów w Looker Studio i Looker (nie mylić z Studio) zawsze włączam BI Engine z rezerwacją 5–20 GB pamięci. To in-memory cache, który obsługuje 90% powtarzalnych zapytań poza slotami. Cache trafień = 0 slot-sekund. To osobna decyzja od głównej rezerwacji.

Wszystkie te techniki uzupełniają szerszą strategię optymalizacji zasobów w GCP. Jeśli robisz przy okazji porządek z Kubernetes i BigQuery jednocześnie, warto zajrzeć do naszego przewodnika po optymalizacji kosztów Kubernetes, bo autoskalowanie po obu stronach ma zaskakująco podobne pułapki.

Case study: jak obniżyliśmy rachunek BigQuery o 38%

Kiedy dołączyłem do zespołu platformowego w Monzo, roczny rachunek BigQuery zbliżał się do 2,4 mln USD i rósł ok. 4% miesiąc do miesiąca. Model: klasyczny on-demand, cztery domeny analityczne (produkt, oszustwa, marketing, finanse) współdzieliły jeden projekt i skanowały łącznie ok. 380 TiB dziennie. Bardzo pouczające były pierwsze audyty.

Krok 1, profil obciążenia. Uruchomiliśmy kwerendę na JOBS_TIMELINE_BY_PROJECT za dwa miesiące. Okazało się, że 22% dziennego skanu generowało pięć nieudokumentowanych pipeline'ów Dataflow, które co godzinę robiły SELECT * z tabeli 4 TB, żeby wyliczyć jedną kolumnę agregatu. To była pierwsza łatwa wygrana: przepisanie na materialized view + partycjonowanie, redukcja o 84 TiB/dzień w tydzień.

Krok 2, segmentacja rezerwacji. Rozdzieliliśmy obciążenie na trzy rezerwacje Enterprise: prod-elt (baseline 800 slotów, max 2 000, dedykowana dla nocnych pipeline'ów), analytics (baseline 400, max 1 500, dla analityków), ad-hoc (baseline 0, max 800, autoscaling dla eksperymentów). Assignmenty na poziomie folderu w Resource Manager, priorytety ustawione tak, że prod-elt nigdy nie stał na kolejce.

Krok 3, 3-year commitment. Po dwóch miesiącach stabilizacji podpisaliśmy 3-year commitment na 1 200 slotów baseline (40% zniżki), resztę zostawiliśmy w pay-as-you-go z autoscalingiem.

Wynik po 6 miesiącach: rachunek spadł z 2,4 mln USD/rok do 1,49 mln USD/rok. Trzeba było też odkryć osobny bug w jednym z workerów Dataflow, który generował 14 tys. USD miesięcznie idle, ale to inna historia. Kluczowa nauka: oszczędności BigQuery to 70% optymalizacji kwerend i 30% dobrego doboru commitmentu. Kolejność zawsze taka, najpierw SQL, potem rezerwacje.

Podobną dyscyplinę tagowania i chargebacku, o której napisałem w kontekście strategii alokacji kosztów AWS w multi-account, przeniosłem 1:1 do BigQuery, używając labels na poziomie datasetu i job labels na poziomie zapytania. Bez tego chargeback per zespół jest zgadywaniem.

Najczęściej zadawane pytania

Ile kosztują rezerwacje slotów BigQuery w 2026 roku?

W Enterprise Edition: 0,06 USD za slot-godzinę w modelu pay-as-you-go, 0,048 USD z rocznym commitmentem (20% zniżki) i 0,036 USD z trzyletnim (40% zniżki). Standard kosztuje 0,04 USD, Enterprise Plus 0,10 USD za slot-godzinę. Minimalna alokacja to 100 slotów.

Czy warto zostać na on-demand, jeśli mam zmienne obciążenie?

Tak, ale tylko jeśli miesięcznie skanujesz mniej niż 300 TiB. Powyżej tego progu autoscaling reservation w Enterprise pay-as-you-go zwykle wypada taniej, bo płacisz slot-sekundy zamiast bajtów. Zrób 2-tygodniowy profil na JOBS_TIMELINE_BY_PROJECT i porównaj koszty przed decyzją.

Jak działa autoscaling w BigQuery reservations?

Definiujesz baseline (minimalna liczba slotów, zawsze aktywna) i max slots (górny sufit). Autoscaler doskaluje w blokach po 100 slotów, gdy kolejka rośnie, i utrzymuje sloty przez co najmniej 60 sekund. Skalowanie w dół jest wolniejsze, żeby chronić przed migotaniem. Baseline można ustawić na 0, wtedy płacisz tylko za faktycznie zużyte slot-sekundy.

Czym Enterprise Edition różni się od Enterprise Plus?

Enterprise Plus dodaje CMEK (własne klucze szyfrowania), Cross-region replication zestawów danych, Assured Workloads (FedRAMP High, ITAR, sovereign cloud UE) oraz BigQuery Omni do zapytań federacyjnych na AWS S3 i Azure Blob. Kosztuje 0,10 USD za slot-godzinę vs. 0,06 USD w Enterprise. 95% typowych obciążeń analitycznych nie potrzebuje Plus.

Czy mogę anulować 1-year commitment BigQuery przed końcem okresu?

Nie. Roczne i trzyletnie commitmenty są nieodwoływalne i zapłacisz za pełny okres nawet jeśli przestaniesz używać BigQuery. Google pozwala tylko na dokupywanie slotów (upgrade). Dlatego zaczynaj od najmniejszego bezpiecznego baseline i dokupuj kwartalnie na podstawie realnej obserwacji obciążenia.

Jak zmniejszyć koszt BigQuery bez zmiany modelu rozliczania?

Trzy najskuteczniejsze techniki: partycjonuj tabele po dacie i klastruj po kolumnach filtrujących (redukcja skanu 60–90%), zastąp powtarzalne agregacje materialized views z auto-refreshem, i włącz BI Engine dla dashboardów. Ta trójka zwykle obniża zużycie slotów o 40–70% zanim w ogóle rozważysz zmianę na rezerwacje.