BigQuery ML

Kurzfazit

BigQuery ML ist die pragmatischste Art, Machine Learning in einem bereits etablierten Data Warehouse zu betreiben. Statt Daten in separate ML-Umgebungen zu kopieren, trainierst du Modelle direkt per CREATE MODEL-SQL-Statement, inklusive Forecasting mit TimesFM und Remote-Calls zu Gemini oder Anthropic-Modellen. Der Preis dafür: Du bist an Google Cloud gebunden, und für individuelle Deep-Learning-Architekturen brauchst du weiterhin Vertex AI oder SageMaker. Für Analysten-Teams mit SQL-Skills und BigQuery als zentralem Warehouse ist es die beste Wahl, für Python-ML-Teams nicht.

Für wen ist BigQuery ML?

Data Analysts ohne Python-Erfahrung: Wer SQL beherrscht, aber kein TensorFlow oder scikit-learn anfassen will, baut hier in Stunden Modelle, die sonst wochenlanges Onboarding in Python-ML-Stacks erfordern. CREATE MODEL, ML.PREDICT, fertig.

Unternehmen mit BigQuery als zentralem Warehouse: Wenn eure Daten ohnehin in BigQuery liegen, Events, Transaktionen, Logs, ist BQML die natürliche Erweiterung. Keine Datenexporte, keine Parallel-Infrastruktur, keine zusätzlichen Pipeline-Jobs.

Marketing- und Revenue-Teams: Churn-Prediction, Lead-Scoring, Lifetime-Value-Forecasting direkt auf den CRM- und Event-Daten im Warehouse, Ergebnisse landen als Tabelle, die direkt in Looker, Tableau oder Data Studio sichtbar wird.

Operations und Supply Chain: Demand Forecasting mit ARIMA_PLUS oder TimesFM auf historischen Verkaufsdaten. Die vortrainierten Modelle liefern in wenigen Minuten Zeitreihen-Prognosen, ohne dass ein Data Scientist eigene Modelle bauen muss.

Weniger geeignet für: Deep-Learning-Spezialisten (Vertex AI oder SageMaker bieten mehr Flexibilität), AWS-zentrische Stacks, Startups ohne BigQuery-Einsatz sowie alle, die individuelle Modellarchitekturen oder Fine-Tuning eigener Transformer brauchen.

Preise im Detail

Modell	Preis (europe-west3 / Frankfurt)	Was du bekommst
Free Tier	0 €	10 GiB Storage + 1 TiB Query-Volumen pro Monat gratis
On-Demand (Analyse)	ca. 6,25 USD / TiB gescannt	Pay-per-Query, bis zu 2.000 Slots pro Projekt geteilt
BQML Built-in Training	ca. 6,25 USD / TiB (wie Analyse)	Linear/Logistic Regression, K-Means, ARIMA_PLUS, TimesFM, PCA, Matrix Factorization
BQML External Training	Separater Vertex-AI-Preis, umgerechnet in Slots	AutoML Tables, Boosted Trees, DNN, Random Forest (läuft auf Vertex AI)
Standard Edition	ca. 0,04 USD / Slot-Stunde	Pay-as-you-go Kapazität, autoscaling, für kleinere Workloads
Enterprise Edition	ca. 0,06 USD / Slot-Stunde	Voller BQML-Funktionsumfang, inkl. externe Modelle und Remote-Modelle
Enterprise Plus Edition	ca. 0,10 USD / Slot-Stunde	Zusätzliche Security-, Governance- und Advanced-Features
Remote-Modelle (Gemini, Anthropic)	BigQuery-Kosten + API-Kosten separat	ML.GENERATE_TEXT, ML.GENERATE_EMBEDDING, pro Token beim Modellanbieter

Einordnung: Die Preismodelle sind auf dem Papier einfach, in der Praxis aber tückisch. Bei On-Demand zahlst du für jedes Byte, das die Query scannt, auch beim Modell-Training. Ein CREATE MODEL auf einer 2-TiB-Tabelle kostet schon im Training rund 12,50 USD, und wer Hyperparameter-Tuning oder ARIMA mit Auto-Tuning aktiviert, multipliziert das schnell um den Faktor 10. Für produktive Workloads lohnt sich fast immer das Editions-Modell mit reservierten Slots, weil die Kosten planbarer werden. Remote-Modelle wie Gemini-Calls fallen doppelt ins Gewicht: BigQuery-Kosten für den SQL-Job plus Token-Kosten beim jeweiligen Modellanbieter. Die 1 TiB Free Tier pro Monat reicht für Prototyping, aber nicht für produktives Training.

Stärken im Detail

SQL schlägt Python für 80 % der Use-Cases. Der echte Gamechanger ist nicht die Modellqualität, sondern der Zugang: Ein CREATE MODEL ... OPTIONS(model_type='linear_reg') AS SELECT ... ist in fünf Minuten geschrieben und nutzt die gleichen Tabellen, die der Analyst ohnehin kennt. Kein Jupyter-Setup, keine Python-Versionen, keine virtuellen Environments, das senkt die Einstiegshürde für ML in Analysten-Teams radikal.

Keine Datenbewegung ist ein echter Kostenvorteil. Klassische ML-Pipelines exportieren Daten aus dem Warehouse in ein Feature Store, trainieren dort Modelle, und laden die Predictions wieder zurück. BQML macht das in einem einzigen SQL-Statement. Gerade bei Terabyte-großen Faktentabellen spart das Stunden pro Pipeline-Lauf und eliminiert eine ganze Fehlerklasse (Schema-Drift, Export-Timeouts, inkonsistente Daten zwischen Training und Inference).

Forecasting mit TimesFM ist eine kleine Sensation. Googles vortrainiertes Zeitreihen-Foundation-Modell ist seit 2024 in BQML verfügbar und liefert für viele Business-Zeitreihen (Umsatz, Traffic, Lagerbestand) erstaunlich gute Prognosen ohne eigenes Training. AI.FORECAST auf einer Verkaufshistorie gibt dir in Sekunden eine 30-Tage-Prognose, ein Use-Case, der früher einen Data Scientist mit Prophet oder statsmodels beschäftigt hätte.

Remote-Modelle bringen LLMs ins Warehouse. Über CREATE MODEL ... REMOTE WITH CONNECTION kannst du Gemini, Vertex-AI-Endpoints oder Anthropic-Modelle direkt aus SQL heraus aufrufen. ML.GENERATE_TEXT klassifiziert Kundensupport-Tickets, extrahiert Entitäten aus Freitext oder fasst Reviews zusammen, alles im gleichen SQL-Kontext, in dem auch das Dashboard gebaut wird. Das ist qualitativ eine andere Liga als Function-UDFs, die man manuell mit Python bauen müsste.

Schwächen ehrlich betrachtet

Die Kostenkontrolle ist ein Dauerthema. BigQuery ML hat keine Budget-Warnung pro Modell, du merkst einen teuren Trainingslauf erst auf der nächsten Rechnung. Ein CREATE MODEL auf einer 10-TiB-Tabelle ohne WHERE-Filter produziert schnell dreistellige Kosten, Auto-ARIMA mit Hyperparameter-Search vervielfacht das. Pflicht ist die Vorab-Prüfung per Dry-Run (bq query --dry_run) und Budget-Alerts auf Projekt-Ebene, sonst zahlst du Lehrgeld.

Für individuelle ML-Architekturen bist du hier falsch. Wer eigene Transformer fine-tunen, Computer-Vision-Netze bauen oder Reinforcement-Learning machen will, findet in BQML keine Werkzeuge. Die externen Modelle (DNN, Boosted Trees) laufen im Hintergrund auf Vertex AI, aber mit deutlich weniger Kontrolle als direkt in Vertex AI oder SageMaker. BQML ist explizit für tabulare Daten und klassische ML-Aufgaben gebaut, alles andere ist Zweitoption.

Vendor-Lock-in bei Google Cloud ist real. Ein BQML-Modell lässt sich als ONNX oder TensorFlow SavedModel exportieren, aber die Trainingspipeline ist eng an BigQuery gekoppelt. Wer ernsthaft überlegt, zu Snowflake Cortex, Databricks oder AWS zu migrieren, baut diese Pipelines komplett neu. Remote-Modelle verschärfen das: ML.GENERATE_TEXT mit Gemini ist kein Standard-Feature, das du auf einer anderen Plattform nachbaust.

Deutscher Support existiert faktisch nicht. Google Cloud hat deutschsprachige Sales- und Support-Ansprechpartner, aber Dokumentation, Error-Messages und Community-Ressourcen sind durchgehend englisch. Für Enterprise-Kunden mit Premium Support Paketen ist das handhabbar, für Mittelstand-Teams ohne Cloud-Muttersprache ein echter Reibungspunkt.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Eine vollwertige ML-Entwicklungsumgebung mit Python, Notebooks und MLOps brauchst	Databricks
Bereits in AWS arbeitest und ML direkt auf S3/Redshift betreiben willst	Amazon SageMaker
In Microsoft-Azure-Umgebungen ML betreiben willst	Azure Machine Learning
Primär Dashboards und Visualisierungen auf BigQuery-Daten brauchst (kein ML)	Looker Studio
Individuelle Deep-Learning-Modelle mit voller Kontrolle willst	Vertex AI (Google Cloud, eigene Plattform)
Snowflake als Warehouse nutzt und ML im Warehouse willst	Snowflake Cortex (vergleichbares Konzept, eigene Stärken)

BigQuery ML ist das Tool, wenn BigQuery bereits dein Warehouse ist. Für alle anderen Szenarien gibt es spezialisiertere Alternativen. Der größte Konkurrent ist Snowflake Cortex mit einem sehr ähnlichen Ansatz, die Entscheidung fällt meist auf der Ebene “welches Warehouse habt ihr schon”, nicht auf ML-Feature-Ebene.

So steigst du ein

Schritt 1: Aktiviere BigQuery in deinem Google-Cloud-Projekt und wähle bewusst eine EU-Region (empfohlen: europe-west3 Frankfurt oder europe-west4 Niederlande). Lade einen Test-Datensatz hoch, z. B. deine letzten 12 Monate Verkaufsdaten als CSV. Richte vorher ein Budget-Alert auf Projekt-Ebene ein (Cloud Billing → Budgets & Alerts), sonst fährst du mit offenen Augen ins Kostenrisiko.

Schritt 2: Baue dein erstes Modell mit einem einfachen CREATE MODEL-Statement, z. B. eine lineare Regression auf einem Teildatensatz mit LIMIT oder WHERE, um Kosten klein zu halten. Beispiel: CREATE MODEL sales.churn_predictor OPTIONS(model_type='logistic_reg', input_label_cols=['churned']) AS SELECT * FROM sales.customers WHERE signup_date < '2025-01-01'. Prüfe jeden Query vorher mit Dry-Run, um das Scan-Volumen zu sehen.

Schritt 3: Für Forecasting nutze AI.FORECAST mit TimesFM auf einer Zeitreihe, das erfordert kein eigenes Training und ist oft gut genug. Für Klassifikation prüfe die Modellgüte mit ML.EVALUATE und produktive Vorhersagen mit ML.PREDICT. Wenn die ersten Ergebnisse überzeugen, überlege den Wechsel vom On-Demand- zum Editions-Modell, ab ca. 500 GiB Training pro Monat rechnet sich Enterprise Edition meist.

Ein konkretes Beispiel

Ein mittelständischer E-Commerce-Händler aus Hamburg mit rund 200.000 aktiven Kunden führt alle Bestell-, Klick- und Newsletter-Daten bereits in BigQuery zusammen. Die Marketingabteilung will vor jedem Versand-Event wissen, welche Kunden kurz vor dem Abspringen stehen. Bisher lief das manuell: Export nach CSV, Analyse in Excel, subjektive Bauchregeln.

Mit BQML baut eine Analystin in zwei Nachmittagen ein Churn-Modell: CREATE MODEL marketing.churn OPTIONS(model_type='boosted_tree_classifier', input_label_cols=['churned_90d']) AS SELECT ... FROM events.customer_features. Das Training auf 450 GiB Feature-Daten kostet einmalig rund 3 USD (Built-in-Modell-Rate). Die täglichen Prediction-Jobs via ML.PREDICT laufen in der 1-TiB-Free-Tier und liefern jeden Morgen eine Tabelle “gefährdete Kunden” mit Risiko-Score direkt in Looker Studio. Was früher ein externes Data-Science-Projekt für 20.000 € gewesen wäre, ist jetzt ein interner SQL-View mit monatlichen Kosten im zweistelligen USD-Bereich.

DSGVO & Datenschutz

• Datenhosting: EU-Regionen verfügbar, insbesondere europe-west3 (Frankfurt), europe-west1 (Belgien), europe-west4 (Niederlande), europe-west10 (Berlin). Bei korrekter Region-Wahl verlassen die Daten den europäischen Wirtschaftsraum nicht.
• Datennutzung: Google nutzt Kundendaten in BigQuery nach eigener Aussage nicht für Modell-Training. Bei Remote-Modellen (Gemini etc.) gelten die jeweiligen Modell-Datenschutzbedingungen, hier ist eine separate Prüfung nötig.
• Auftragsverarbeitung: Google Cloud bietet einen standardisierten AVV (Data Processing Addendum) an, der DSGVO-konform ist und automatisch Teil der Google-Cloud-Vertragsbedingungen wird.
• Data Residency: Über “Organization Policies” lässt sich erzwingen, dass neue BigQuery-Datasets nur in EU-Regionen angelegt werden können. Für Compliance-Pflichtiges (Gesundheit, Finanzen) empfehlenswert.
• Schrems II / Drittland-Transfer: Google Cloud hat Standardvertragsklauseln (SCC) implementiert, aber der US-Cloud-Act bleibt ein Restrisiko. Für besonders sensible Daten empfiehlt sich zusätzlich Customer-Managed Encryption Keys (CMEK) oder External Key Manager.
• Remote-Modelle beachten: ML.GENERATE_TEXT mit US-gehosteten Gemini-Modellen verschiebt die Inferenz potenziell in die USA, auch wenn die Quelldaten in Frankfurt liegen. Hier muss das Setup der Connection und Modell-Region explizit geprüft werden.
• Account-Löschung: Datasets und Modelle lassen sich sofort löschen, Audit-Logs bleiben nach Standard-Policy 400 Tage erhalten.

Gut kombiniert mit

• Looker Studio, BQML-Predictions werden als Tabelle ausgegeben; Looker Studio visualisiert sie direkt im gleichen BigQuery-Dataset ohne zusätzliche Pipeline. Ideal für Management-Dashboards mit Churn-, Demand- oder Conversion-Prognosen.
• Databricks, wenn für einzelne Use-Cases komplexere Modelle nötig werden, kann Databricks Daten via BigQuery-Connector lesen und die Ergebnisse zurückschreiben. BQML deckt 80 % ab, Databricks die Spezialfälle.
• DeepL, in Kombination mit ML.GENERATE_TEXT-Klassifikationen lassen sich mehrsprachige Kundensupport-Tickets erst übersetzen und dann im SQL-Workflow weiterverarbeiten.

Unser Testurteil

BigQuery ML verdient 4 von 5 Sternen. Für Teams mit BigQuery-basiertem Warehouse ist es die direkteste Brücke von SQL zu Machine Learning, und mit TimesFM und Remote-Modellen ist das Feature-Set seit 2024 ernsthaft konkurrenzfähig geworden. Den fünften Stern verhindern drei Dinge: die schwer vorhersehbare Kostenstruktur (besonders bei On-Demand), der Vendor-Lock-in in Google Cloud und die fehlende Tiefe für individuelle Deep-Learning-Architekturen. Wer nicht bereits BigQuery nutzt, hat keinen Grund, den Umzug nur wegen BQML zu machen, wer BigQuery ohnehin einsetzt, lässt hier einen massiven Produktivitätshebel liegen, wenn er es nicht nutzt.

Was wir bemerkt haben

• 2024, Google integrierte sein vortrainiertes Zeitreihen-Foundation-Modell TimesFM direkt in BQML. Seitdem liefert AI.FORECAST ohne eigenes Training brauchbare Prognosen für Business-Zeitreihen, ein Quantensprung gegenüber ARIMA_PLUS und ein Feature, das Snowflake und Databricks erst nachziehen mussten.
• 2024, Die Abrechnungseinheit wurde offiziell von TB (Terabyte, 10¹²) auf TiB (Tebibyte, 2⁴⁰) umgestellt. Der Unterschied klingt klein (~10 %), ist in Rechnungen aber sichtbar und sorgte bei Kunden für Verwirrung. Heute ist der offizielle Preis 6,25 USD/TiB.
• 2024–2025, Remote-Modelle wurden deutlich ausgebaut: Neben Gemini und Vertex-AI-Endpoints sind jetzt auch Anthropic-Modelle über Vertex AI Model Garden aus BQML heraus per SQL erreichbar. Das verschiebt BQML vom reinen Tabellen-ML zu einem echten Integrationspunkt für LLM-Workflows.
• 2023, Google führte die BigQuery Editions (Standard, Enterprise, Enterprise Plus) ein und ersetzte damit das alte Flat-Rate-Modell. Für bestehende Kunden war das eine Umstellungsphase, seitdem ist die Wahl zwischen On-Demand und Editions die wichtigste Kostenentscheidung für jeden BigQuery-Workload.