BigQuery: Co to jest? Kompletny poradnik dla analityków 2025

BigQuery to rozwiązanie, które zmienia sposób pracy analityka w momencie, gdy jego potrzeby przekraczają to, co potrafi zrobić UI Google Analytics 4 albo arkusz kalkulacyjny. Serwerless oznacza, że nie zarządzasz żadną infrastrukturą, uruchamiasz SQL, a Google skaluje obliczenia za Ciebie. Płacisz tylko za dane, które realnie zeskanuje zapytanie.

Ten poradnik wyjaśnia czym BigQuery jest technicznie (nie marketingowo), jak działa architektonicznie, ile naprawdę kosztuje, kiedy ma sens go używać, a kiedy jest złym wyborem. Na podstawie wdrożeń BigQuery, które robiłem dla europejskich zespołów e-commerce, SaaS i wydawców od 2022 roku, kiedy GA4 BigQuery Export stał się darmowy dla wszystkich.

Jeśli jesteś na etapie oceniania, czy BigQuery ma sens dla Twojego setupu, ten artykuł pokrywa podstawy. Jeśli już wiesz, że chcesz wejść i martwisz się kosztami, zobacz poradnik optymalizacji kosztów BigQuery (publikowany w następny piątek).

Kluczowe wnioski

BigQuery to hurtownia analityczna, nie transakcyjna baza danych. Używaj do raportowania, modelowania, data science; nie używaj do backendu aplikacji z milionami pojedynczych operacji.

Cennik (2025): 5 USD za TB zeskanowanych danych + 0,02 USD za GB/miesiąc magazynu. Pierwsze 1 TB query + 10 GB storage miesięcznie to free tier.

Killer use case dla analityków: darmowy eksport GA4 z pełnymi danymi hit-level (coś, czego UI GA4 nie daje, a Universal Analytics wymagał płatnej wersji 360).

Nie potrzebujesz ustawiać serwerów, partycji ani backupów. Google robi to za Ciebie. Ty piszesz SQL.

Największe ryzyko to koszt zapytania. Jedno nieprzemyślane SELECT * na dużym datasecie może kosztować 50 EUR. Partycjonowanie i klastrowanie to Twoi przyjaciele.

Czym naprawdę jest BigQuery

Najpierw wersja techniczna, nie marketingowa.

BigQuery to analytical database (OLAP) zbudowane na silniku kolumnowym. W przeciwieństwie do Postgresa albo MySQL, które optymalizują odczyt wierszy (OLTP, "pokaż mi zamówienie numer 12345"), BigQuery optymalizuje agregacje po kolumnach ("policz sumę przychodów z wszystkich zamówień per kanał marketingowy z ostatnich 90 dni"). Ta różnica decyduje o wszystkim innym.

Druga kluczowa cecha to separation of storage and compute. Dane leżą w Google Cloud Storage w formacie Capacitor (własny format kolumnowy Google). Compute, czyli silnik wykonujący zapytania, Dremel, uruchamia się on-demand. Nie płacisz za "włączony" klaster, płacisz za realne przetwarzanie.

Trzecia cecha: full SQL compliance (ANSI SQL 2011+) plus rozszerzenia Google (BigQuery ML do trenowania modeli z SQL-a, geospatial functions, arrays, structs, JSON). Jeśli umiesz SQL, umiesz BigQuery. Najpoważniejsza nauka to optymalizacja kosztów, nie składnia.

Jak BigQuery różni się od zwykłej bazy danych

Pięć kluczowych różnic, które decydują o tym, czy BigQuery pasuje do Twojego use case:

1. Skala vs latencja pojedynczego zapytania. BigQuery skaluje się do petabajtów, ale najszybsze zapytanie i tak potrwa 500 ms. Postgres odda odpowiedź na SELECT * FROM orders WHERE id = 12345 w 5 ms. Jeśli potrzebujesz sub-100ms reakcji per request, BigQuery nie jest właściwym narzędziem.

2. Brak indeksów (w tradycyjnym sensie). Zamiast indeksów masz partitioning (dzielisz tabelę po dacie, zwykle) i clustering (sortujesz fizycznie po 1-4 kolumnach). Zamiast "dodaj indeks po polu X", myślisz "jak fizycznie ułożyć dane, żeby zapytania skanowały mniej".

3. Brak UPDATE/DELETE w stylu OLTP. Możesz zaktualizować wiersze, ale drogo (skanuje i przepisuje całą partycję). Typowy pattern BigQuery to append-only plus materialized views albo scheduled queries, które przebudowują agregacje.

4. Cennik per-query, nie per-serwer. W Postgresie płacisz za maszynę 24/7. W BigQuery płacisz tylko kiedy ktoś uruchamia zapytanie. Jeśli Twój dashboard pobiera dane 5 razy dziennie, płacisz za 5 razy skanu. Reszta czasu: tylko storage (groszowe koszty).

5. Wymuszone dobre praktyki przez cennik. Każde SELECT * dosłownie kosztuje więcej. Każde niezostosowane filtrowanie po partycji skanuje cały dataset. W Postgresie zły SQL psuje performance; w BigQuery zły SQL psuje Twoje faktury.

Kiedy BigQuery ma sens

Cztery scenariusze, w których BigQuery to właściwy wybór.

1. Eksport danych GA4 (darmowy killer use case)

To główny powód, dla którego większość zespołów marketingowych nawet spotyka BigQuery. GA4 ma wbudowany darmowy eksport do BigQuery, dostępny w każdej property w Admin > BigQuery Links.

Dlaczego to duże:

• Dane hit-level, każde zdarzenie, każdy parametr, każdy user-scoped custom dimension, w pełnej rozdzielczości. UI GA4 zawsze agreguje, limituje do 10-16 wymiarów naraz i sampluje dla dużych datasetów.
• Brak limitów raportowania, żadnych kart w raportach, żadnego "cardinality explosion" błędu, żadnych cardinality limitów na custom dimensions.
• Full SQL access, dowolne join z danymi CRM, reklam, maili, wszystkiego co masz w BigQuery.
• Dane historyczne są Twoje, GA4 retencja default 2 miesiące (max 14). W BigQuery trzymasz dane tyle, ile chcesz, i robisz analizy year-over-year, których UI GA4 fizycznie nie pozwala.

Dla mid-market europejskiego e-commerce z 100 000 sesji dziennie, eksport GA4 do BigQuery to zwykle 5-15 EUR miesięcznie w kosztach storage plus koszty zapytań. Za porównywalną funkcjonalność w Universal Analytics 360 Google brał 150 000 EUR/rok.

2. Custom dashboardy ponad Workspace/Looker Studio native connectors

Jeśli robisz dashboardy w Looker Studio, Power BI albo własnym toolu, i native connector do GA4 Cię limituje (sampling, cardinality, brak konkretnych wymiarów), BigQuery jest warstwą pośrednią. Łączysz się z BigQuery, robisz custom widoki, łączysz z innymi źródłami, a dashboard serwuje gotowe dane.

3. Cross-platform attribution i customer analytics

Masz GA4, Google Ads, Meta Ads, dane CRM w HubSpot, zamówienia w Shopify. Każdy systemu ma swój UI i swoje dashboardy. BigQuery to miejsce, gdzie to wszystko łączysz po user_id lub email, i dopiero wtedy widzisz prawdziwy customer journey, od pierwszego dotknięcia do retencji.

4. Ad-hoc SQL dla analityków, którzy znają SQL

Jeśli Twój zespół analityki umie SQL i frustruje się limitami UI, BigQuery to ich przestrzeń. Zero czekania na data engineera, żeby zbudował pipeline. Zapytanie pisane w 30 sekund, odpowiedź w 2 sekundy, kolejna iteracja.

Zastanawiasz się, czy BigQuery pasuje do Twojego setupu GA4 albo potrzeb raportowych? Napisz do mnie po zescope'owaną ocenę, przegląd Twoich danych, pytań biznesowych, budżetu i realny estymat, czy BigQuery zwróci się w 6-12 miesiącach.

Kiedy BigQuery NIE jest właściwym narzędziem

Cztery scenariusze, w których BigQuery to zły wybór i powinieneś użyć czegoś innego.

1. Backend aplikacji transakcyjnej

Jeśli budujesz aplikację, która na każde kliknięcie użytkownika robi zapytanie w stylu SELECT * FROM users WHERE id = 42, BigQuery Cię zabije. Latencja pojedynczego zapytania startuje od 500 ms, a koszt rośnie proporcjonalnie do ruchu. Do tego potrzebujesz PostgresSQL, MySQL, Cloud Spannera, Firestore, czegokolwiek optymalizowanego do OLTP.

2. Bardzo małe datasety (pod 10 GB)

Jeśli mieścisz wszystko w jednym pliku Excela albo małej bazie Postgres, BigQuery to przerost. Koszty stałe nie istnieją (free tier pokryje wszystko), ale narzut operacyjny (konfiguracja, monitorowanie, uczenie zespołu) nie jest zerowy. Dla małych datasetów narzędzia jak Google Sheets, Metabase na Postgresie albo Retool są prostsze.

3. Wymóg real-time (pod 1 sekundę odpowiedzi)

BigQuery jest szybki dla swojej klasy (agregacje na petabajtach w kilka sekund), ale nie jest narzędziem real-time. Jeśli dashboard musi odświeżać co sekundę, potrzebujesz streaming analytics (Kafka + Flink, Apache Pinot, BigQuery BI Engine jako dodatek). Większość biznesowych dashboardów nie potrzebuje real-time, ale jeśli Twój tak, wiedz o tym wcześnie.

4. Budżet operacyjny pod 50 EUR/miesiąc bez GA4 Export

Bez przypadku GA4 Export BigQuery łatwo nie osiąga break-evenu dla bardzo małych biznesów. Jeśli masz 20 zapytań miesięcznie na małym datasecie, free tier pokryje wszystko, ale wtedy po co BigQuery. Matomo + własny Postgres kosztuje mniej administracyjnie.

Cennik BigQuery w praktyce

Dwa główne komponenty kosztowe (plus kilka pobocznych):

Koszty zapytań (query processing)

On-demand pricing: 5 USD za 1 TB zeskanowanych danych. To jest default. Każdy request skanuje konkretne kolumny konkretnych partycji i Google liczy bajty, które realnie przeczytał.

Praktyka: tabela GA4 Export z 3 miesięcy danych dla średniego e-commerce to około 5-15 GB. Skan całej tabeli w złym zapytaniu (SELECT *) kosztuje 5 × 15/1000 = 0,075 USD. Brzmi tanio, ale pomnóż przez 100 źle napisanych zapytań dziennie i masz 225 USD miesięcznie.

Alternatywa capacity-based: płacisz stały abonament za "sloty" (jednostki compute). Sensowne dopiero powyżej 2 000-3 000 USD/mc w on-demand.

Koszty storage

Active storage: 0,02 USD za GB/miesiąc (dane modyfikowane w ostatnich 90 dniach).

Long-term storage: 0,01 USD za GB/miesiąc (dane niezmieniane 90+ dni).

100 GB danych GA4 kosztuje 2 USD/miesiąc. Dane z 2022 roku, których nikt nie tyka, spadają do 1 USD/miesiąc.

Streaming inserts

0,01 USD za 200 MB dla wstawiania danych przez streaming API. Dla większości setupów to pomijalne, ale zespół z dużym real-time pipeline może to zauważyć.

Free tier (warto znać)

Każdego miesiąca:

• 1 TB zapytań za darmo
• 10 GB aktywnego storage za darmo
• Nieograniczone query cache hits (powtórzone zapytanie z cache nie liczy się do limitu)

Dla małej firmy testującej BigQuery to realnie oznacza 0 EUR miesięcznie przez pierwsze miesiące.

Mini-historia: od Workspace do BigQuery

Kiedy Paweł, analytics lead w polskim e-commerce, próbował odpowiedzieć na pytanie "jaki jest LTV klienta pozyskanego z Google Ads vs Meta Ads w perspektywie 12 miesięcy?" w marcu 2025, UI GA4 mu tego nie dał. Workspace limituje 90 dni dla explorations, limity kardynalności blokowały przekroje, a próby wydobycia danych przez API kończyły się sampling warningami.

Włączyliśmy BigQuery Export GA4 (5 minut pracy), podłączyliśmy historyczne 14 miesięcy danych, i napisaliśmy jedno zapytanie SQL, 40 linijek, łączące events_* tabele z tabelą klientów z jego Shopify (która już była w BQ przez Fivetran connector). Odpowiedź wypadła w 4 sekundy.

Koszt całego eksperymentu: 0,42 USD. Czas: popołudnie. Wniosek biznesowy: LTV klientów z Meta Ads był o 23% niższy niż z Google Ads, co kompletnie przewartościowało alokację budżetu na Q2.

To jest dokładnie ten use case, dla którego BigQuery istnieje.

GA4 BigQuery Export, killer use case krok po kroku

1. Włączenie eksportu

W GA4: Admin > BigQuery Links > Link. Musisz mieć projekt Google Cloud z włączoną BigQuery API. Wybierasz location (ważne, EU multi-region dla danych europejskich, spełnia wymagania RODO lepiej niż US region) i częstotliwość (streaming albo daily batch).

2. Struktura danych

Każdy dzień to osobna tabela: events_YYYYMMDD. Plus events_intraday_YYYYMMDD jeśli wybrałeś streaming. Każdy wiersz to jedno zdarzenie GA4, z pełnym kontekstem (user pseudo id, sesja, urządzenie, lokalizacja, wszystkie parametry custom).

Schema jest nested, zdarzenia mają tablice parametrów, a parametry mają struktury z różnymi typami value. Praktyka: używaj UNNEST liberalnie.

3. Pierwsze użyteczne zapytanie

"Top 10 stron z największą liczbą unikalnych userów w ostatnich 7 dniach":

SELECT
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page,
COUNT(DISTINCT user_pseudo_id) AS users
FROM my-project.analytics_123456789.events_*
WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY))
AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
AND event_name = 'page_view'
GROUP BY page
ORDER BY users DESC
LIMIT 10

Kluczowy element to _TABLE_SUFFIX filter, bez niego zapytanie skanuje wszystkie tabele events_* i koszty eksplodują.

4. Narzędzia, których warto używać

• BigQuery Studio (web UI bezpośrednio w Google Cloud Console), start domyślny, wbudowany query editor z autocomplete schemy
• BigQuery Console + dbt, dla zespołów, które już pracują w dbt
• Dataform (Google native), alternatywa dla dbt, wbudowana w GCP
• Looker Studio, darmowe dashboardy bezpośrednio z tabel BQ, zobacz poradnik Looker Studio
• Jupyter / Colab + biblioteka google-cloud-bigquery, data science workflows

Druga mini-historia: kiedy BigQuery był złym wyborem

Uczciwa przeciwwaga. Marek, CTO w polskim B2C startupie, wdrożył BigQuery jako główną bazę produktową w 2024 roku. Logika: "Google Cloud, skaluje się, nie trzeba zarządzać". Pół roku później biznes chodził, ale każda akcja user w aplikacji webowej generowała 2-3 zapytania BigQuery, a każde zapytanie ważyło 200-400 ms latencji plus opłaty.

Jego rachunek BigQuery w czerwcu 2024: 2 800 EUR. Rachunek Cloud SQL (Postgres) który mógłby obsłużyć tę samą aplikację: 120 EUR. Różnica 26× wynikała z tego, że BigQuery jest hurtownią analityczną, a on używał jej jak bazy operacyjnej.

Przeprowadziliśmy migrację krytycznych operacji na Cloud SQL w trzy tygodnie. BigQuery został tylko do analityki (GA4 Export + dashboardy managerskie). Rachunek spadł do 180 EUR miesięcznie łącznie.

Wniosek: BigQuery to hurtownia analityczna, nie baza transakcyjna. Używanie jej do czegokolwiek innego kończy się albo złą wydajnością, albo drogimi fakturami, albo jednym i drugim.

Planujesz wdrożenie BigQuery i nie jesteś pewien, czy robisz to dobrze? Zobacz moje usługi data engineering, audyt architektury, migracje GA4 → BigQuery, custom pipeline'y i optymalizacja kosztów.

Jak zacząć z BigQuery (w ciągu 30 minut)

Krok 1: Projekt Google Cloud

Wejdź na console.cloud.google.com, stwórz projekt (darmowy, potrzebuje tylko karty kredytowej dla free tier sign-up, ale pierwsze 300 USD przez 90 dni też jest darmowe dla nowych kont).

Krok 2: Włącz BigQuery API

W Google Cloud Console: APIs & Services > Library > BigQuery API > Enable. Zajmuje 30 sekund.

Krok 3: Pierwszy dataset

W BigQuery Studio: Explorer (po lewej) > Twój projekt > Create dataset. Nazwa, region (wybierz EU), done.

Krok 4: Załaduj pierwsze dane

Dwie opcje:

• Jeśli masz plik CSV, Create table > Upload > wskaż plik > BigQuery sam wykryje schemę
• Jeśli masz GA4, włącz Export (Admin > BigQuery Links)
• Dla testów, BigQuery ma publiczne datasety (bigquery-public-data) z przykładami: stack_overflow, london_bicycles, google_trends

Krok 5: Pierwsze zapytanie

W BigQuery Studio: Compose new query, wpisz SQL, Run. Wynik jest w tabeli. Zapytanie liczy bajty na pasku u góry, tam sprawdzasz koszt zanim klikniesz Run.

Krok 6: Połącz z Looker Studio albo Twoim BI

W Looker Studio: Add data > BigQuery > wybierz projekt > wybierz dataset > dashboard gotowy.

Najczęściej zadawane pytania

Ile kosztuje BigQuery?

Cennik ma dwa komponenty: query processing (5 USD za TB zeskanowanych danych) i storage (0,02 USD za GB aktywnego magazynu miesięcznie, 0,01 USD za long-term storage). Pierwsze 1 TB zapytań i 10 GB storage miesięcznie to free tier. Typowy setup GA4 Export dla mid-market e-commerce kosztuje 10-50 USD miesięcznie łącznie.

Czy BigQuery jest darmowy dla GA4?

Eksport danych GA4 do BigQuery jest darmowy dla wszystkich kont GA4 od 2022 roku. Płacisz za storage (0,02 USD/GB/miesiąc) i query processing, ale sam fakt eksportu nie kosztuje nic. W Universal Analytics eksport BigQuery wymagał płatnej wersji GA 360.

Czy BigQuery jest zgodny z RODO?

Tak, jeśli wybierzesz region EU (multi-region EU albo konkretny region jak europe-west1) i masz DPA z Google Cloud. Dane leżą w centrach danych UE. Dla pełnego kontekstu RODO i danych analitycznych zobacz poradnik GA4 i RODO.

Jaka jest różnica między BigQuery a Snowflake?

Obie to analityczne hurtownie danych z kolumnowym storage. Główne różnice: BigQuery jest natywny dla GCP (tight integration z GA4, Google Ads, Vertex AI), Snowflake działa na AWS/Azure/GCP (multi-cloud). BigQuery ma prostszy cennik (per query), Snowflake per-warehouse per-second. Dla analityki GA4 w Europie BigQuery wygrywa integracją. Dla multi-cloud enterprise Snowflake jest elastyczniejszy.

Czy potrzebuję znać SQL, żeby używać BigQuery?

Tak, do poważnej pracy tak. BigQuery to SQL-first narzędzie. Jeśli nie znasz SQL, możesz użyć Looker Studio podłączonego do BigQuery, żeby wygodnie przeglądać dane bez SQL, ale cała moc BigQuery (custom analityka, ad-hoc queries) wymaga SQL. Inwestycja w naukę ANSI SQL (1-2 tygodnie dla kogoś komfortowego z Excelem) zwraca się szybko.

Jak długo mogę trzymać dane w BigQuery?

Tak długo, jak chcesz. Nie ma limitów retencji (w przeciwieństwie do GA4, które max 14 miesięcy). Dane niezmieniane 90+ dni automatycznie wchodzą w long-term storage (50% taniej). Dla analityki historycznej year-over-year to znacząca przewaga nad native UI GA4.

Podsumowanie

BigQuery to bezserwerowa hurtownia analityczna Google. Używaj do raportowania, ad-hoc SQL, modelowania i przede wszystkim darmowego eksportu GA4. Nie używaj jako bazy aplikacji transakcyjnej, nie używaj dla sub-sekundowych requestów i nie używaj, jeśli masz 10 GB danych i żaden zespół SQL.

Dla większości mid-market europejskich biznesów z GA4 Eksport BigQuery to realna zmiana jakości analityki przy koszcie 10-50 EUR miesięcznie. Zacznij od free tier, włącz GA4 Export, napisz pierwsze zapytania, a po miesiącu zobaczysz, czy ma sens eskalować inwestycję.

Chcesz wdrożyć BigQuery dla swojego setupu GA4 albo martech stacku i nie jesteś pewien, od czego zacząć? Napisz do mnie po zescope'owaną ocenę, review Twoich danych, pytań biznesowych i budżetu plus konkretny plan wdrożenia. Bez ogólników, tylko realny scope i liczby.