# Google BigQuery vs Amazon Redshift 2026: Vergleich und Interviewfragen für Data Analysts

> Ein umfassender Vergleich von BigQuery und Redshift in 2026. Architektur, Preismodelle, SQL-Unterschiede und häufige Interviewfragen für Data Analysts.

- Published: 2026-07-31
- Updated: 2026-07-31
- Author: Anthony Fillion-Maillet
- Tags: bigquery, redshift, data-warehouse, interview
- Reading time: 12 min

---

Google BigQuery und Amazon Redshift dominieren den Cloud-Data-Warehouse-Markt im Jahr 2026, wobei jede Plattform eigene Vorteile für [Data-Analytics](/technologies/data-analytics)-Workloads bietet. Dieser Vergleich behandelt Architekturunterschiede, Preismodelle, Performance-Eigenschaften und die Interviewfragen, die Data-Analyst-Kandidaten häufig begegnen.

> **Schnelle Entscheidungshilfe**
>
> BigQuery eignet sich für serverlose Einfachheit, Pay-per-Query-Preise und enge GCP-Integration. Redshift empfiehlt sich für planbare Kosten bei großem Datenvolumen, komplexe ETL-Pipelines und tiefe AWS-Ökosystem-Integration.

## Architekturunterschiede zwischen BigQuery und Redshift

BigQuery verwendet eine serverlose, mehrmandantenfähige Architektur, bei der Speicher und Compute vollständig getrennt sind. Abfragen laufen auf dynamisch zugewiesenen Ressourcen ohne jegliches Cluster-Management. Google übernimmt sämtliche Infrastrukturskalierung, Patches und Optimierungen automatisch.

Redshift arbeitet mit einem Provisioned-Cluster-Modell mit dedizierten Nodes. Speicher und Compute sind innerhalb der Nodes eng gekoppelt, obwohl [Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-whatis.html) mittlerweile eine verbrauchsbasierte Alternative bietet. Der RA3-Node-Typ führte eine Managed-Storage-Trennung ein, die unabhängige Skalierung von Compute und Speicher ermöglicht.

| Aspekt | BigQuery | Redshift |
|--------|----------|----------|
| Bereitstellung | Vollständig serverlos | Provisionierte Cluster oder Serverless |
| Speicher-Compute | Vollständig getrennt | Gekoppelt (RA3 trennt Managed Storage) |
| Skalierung | Automatisch | Manuelle Größenanpassung oder Concurrency Scaling |
| Wartung | Keine | Wartungsfenster erforderlich |
| Kaltstart | Keiner | Cluster-Aufwachzeit bei Pausierung |

Dieser Architekturunterschied beeinflusst den operativen Aufwand erheblich. BigQuery erfordert keine Kapazitätsplanung, während Redshift kontinuierliche Cluster-Sizing-Entscheidungen und Wartungsplanung verlangt.

## Preismodelle: Pay-per-Query vs Provisionierte Kapazität

BigQuery berechnet 6,25 USD pro gescanntem TB im On-Demand-Modus (Stand 2026). Reserved-Capacity-Preise (Flat-Rate) bieten planbare monatliche Kosten für konstante Workloads. Speicherkosten betragen 0,02 USD/GB/Monat für aktive Daten und 0,01 USD/GB/Monat für Langzeitspeicher nach 90 Tagen.

```sql
-- BigQuery: Abfragekosten vor Ausführung prüfen
SELECT
  total_bytes_billed / POW(10, 12) AS tb_billed,
  (total_bytes_billed / POW(10, 12)) * 6.25 AS estimated_cost_usd
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE job_id = 'your-job-id';
```

Redshift-Preise hängen von Node-Typ und -Anzahl ab. DC2-Nodes (Dense Compute) beginnen bei 0,25 USD/Stunde, während RA3-Nodes mit Managed Storage bei 1,086 USD/Stunde starten. Redshift Serverless berechnet basierend auf verbrauchten Redshift Processing Units (RPUs).

Kostenoptimierungsstrategien unterscheiden sich grundlegend. BigQuery belohnt Abfrageoptimierung durch Partitionierung und Clustering, da das Scannen weniger Daten die Kosten direkt reduziert. Bei Redshift konzentriert sich die Optimierung auf die richtige Cluster-Dimensionierung und die Nutzung von Reserved Instances für planbare Workloads.

## SQL-Syntax und Funktionsunterschiede

Beide Plattformen unterstützen ANSI-SQL, aber Syntaxvariationen existieren bei erweiterten Funktionen. Das Verständnis dieser Unterschiede ist wichtig für [SQL-Interviewfragen](/technologies/data-analytics/interview-questions/sql-subqueries-ctes) und Migrationsprojekte.

```sql
-- BigQuery: Datumsfunktionen mit EXTRACT und DATE_TRUNC
SELECT
  DATE_TRUNC(order_date, MONTH) AS order_month,
  EXTRACT(DAYOFWEEK FROM order_date) AS day_of_week,
  COUNT(*) AS order_count
FROM `project.dataset.orders`
WHERE order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 1 YEAR)
GROUP BY 1, 2;

-- Redshift: Ähnlich, aber DATE_TRUNC mit String-Argument
SELECT
  DATE_TRUNC('month', order_date) AS order_month,
  EXTRACT(DOW FROM order_date) AS day_of_week,
  COUNT(*) AS order_count
FROM orders
WHERE order_date >= DATEADD(year, -1, CURRENT_DATE)
GROUP BY 1, 2;
```

Die Handhabung von Arrays und Structs zeigt deutliche Abweichungen. BigQuery unterstützt nativ verschachtelte und wiederholte Felder mit UNNEST-Operationen. Redshift verarbeitet semi-strukturierte Daten über den SUPER-Typ und PartiQL-Syntax, die in neueren Versionen eingeführt wurden.

```sql
-- BigQuery: Arbeiten mit verschachtelten Arrays
SELECT
  user_id,
  event.name AS event_name,
  event.timestamp AS event_time
FROM `analytics.events`,
UNNEST(events) AS event
WHERE DATE(event.timestamp) = CURRENT_DATE();

-- Redshift: SUPER-Typ mit PartiQL
SELECT
  user_id,
  e.name AS event_name,
  e.timestamp AS event_time
FROM events_table AS t, t.events AS e
WHERE DATE(e.timestamp) = CURRENT_DATE;
```

## Performance-Eigenschaften und Abfrageoptimierung

BigQuery glänzt bei Ad-hoc-Analyseabfragen auf massiven Datensätzen ohne Tuning. Das Slot-basierte Ausführungsmodell verteilt die Arbeit automatisch. Die Performance bleibt unabhängig von gleichzeitigen Benutzern konsistent, da jede Abfrage dedizierte Ressourcen aus dem Slot-Pool erhält.

Redshift liefert überlegene Performance für planbare, repetitive Abfragen, wenn es richtig konfiguriert ist. Distribution Keys, Sort Keys und Materialized Views beeinflussen die Abfragegeschwindigkeit erheblich. Der Query Planner generiert optimierte Ausführungspläne basierend auf Tabellenstatistiken.

```sql
-- Redshift: Definition von Distribution- und Sort-Keys
CREATE TABLE sales_fact (
  sale_id BIGINT,
  customer_id BIGINT,
  product_id BIGINT,
  sale_date DATE,
  amount DECIMAL(10, 2)
)
DISTKEY(customer_id)
SORTKEY(sale_date);

-- Redshift: Materialized View für Dashboard-Abfragen
CREATE MATERIALIZED VIEW daily_sales_summary AS
SELECT
  sale_date,
  COUNT(*) AS transaction_count,
  SUM(amount) AS total_revenue
FROM sales_fact
GROUP BY sale_date;
```

BigQuery-Optimierung basiert auf Partitionierung und Clustering. Partitionierung reduziert gescannte Daten nach Datum oder Integer-Bereich. Clustering sortiert Daten innerhalb von Partitionen für schnellere gefilterte Abfragen.

```sql
-- BigQuery: Partitionierte und geclusterte Tabelle
CREATE TABLE `project.dataset.sales_fact`
PARTITION BY DATE(sale_date)
CLUSTER BY customer_id, product_id
AS SELECT * FROM `project.dataset.raw_sales`;
```

Für Performance-Tuning-Strategien zu verwandten Themen behandelt der [Leitfaden zu Window Functions und CTEs](/blog/data-analytics/sql-window-functions-ctes-advanced-queries) fortgeschrittene Abfrageoptimierungstechniken.

## Datenladen und ETL-Integration

BigQuery unterstützt Streaming-Inserts für Echtzeitdaten zu 0,05 USD pro GB, kostenloses Batch-Laden aus Cloud Storage und native Konnektoren für Dataflow und Pub/Sub. Der BigQuery Data Transfer Service automatisiert geplante Importe aus SaaS-Anwendungen.

```sql
-- BigQuery: Daten aus Cloud Storage laden
LOAD DATA INTO `project.dataset.events`
FROM FILES (
  format = 'PARQUET',
  uris = ['gs://bucket/events/*.parquet']
);
```

Redshift integriert sich eng mit S3 über den COPY-Befehl, der das Laden von Daten über Cluster-Nodes parallelisiert. AWS Glue bietet verwaltete ETL, während Redshift Spectrum S3-Daten direkt ohne Laden abfragt.

```sql
-- Redshift: COPY-Befehl mit optimalen Einstellungen
COPY events
FROM 's3://bucket/events/'
IAM_ROLE 'arn:aws:iam::123456789:role/RedshiftS3Access'
FORMAT AS PARQUET
COMPUPDATE ON
STATUPDATE ON;
```

Beide Plattformen unterstützen mittlerweile das [Apache Iceberg](https://iceberg.apache.org/)-Tabellenformat für externe Data Lakes. BigQuery BigLake und Redshift Spectrum ermöglichen einheitliche Analysen über Data-Warehouse- und Data-Lake-Speicher hinweg.

## Interviewfragen: BigQuery vs Redshift Vergleich

Data-Analyst-Interviews testen häufig das Verständnis von Cloud-Data-Warehouse-Kompromissen. Diese Fragen erscheinen bei Positionen, die Cloud-Plattform-Expertise erfordern.

**Frage 1: Wann würden Sie BigQuery gegenüber Redshift empfehlen?**

BigQuery empfiehlt sich, wenn die Organisation serverlosen Betrieb ohne Infrastrukturmanagement benötigt, Pay-per-Query-Preise zu unvorhersehbaren oder sprunghaften Workloads passen, die Datenplattform bereits auf GCP läuft oder Teams sofortige Abfrageergebnisse auf Petabyte-Daten ohne Cluster-Provisioning-Verzögerungen benötigen.

**Frage 2: Wie funktioniert die Slot-Zuweisung in BigQuery?**

BigQuery weist Slots (Einheiten der Rechenkapazität) dynamisch Abfragen zu. On-Demand-Abfragen teilen sich einen Pool von 2.000 Slots pro Projekt. Jeder Slot repräsentiert ungefähr eine virtuelle CPU mit Streaming-Zugriff auf Colossus (verteilter Speicher). Komplexe Abfragen, die mehr Parallelität erfordern, erhalten proportional mehr Slots, bis die verfügbare Kapazität erschöpft ist.

**Frage 3: Erklären Sie Redshift-Distribution-Styles und wann welcher zu verwenden ist.**

Redshift bietet vier Distribution-Styles:
- **KEY**: Verteilt Zeilen nach Hash der angegebenen Spalte. Verwenden für große Faktentabellen, die häufig über diese Spalte gejoined werden.
- **EVEN**: Verteilt Zeilen Round-Robin über Nodes. Verwenden für Tabellen ohne klare Join-Muster.
- **ALL**: Kopiert die gesamte Tabelle auf jeden Node. Verwenden für kleine Dimensionstabellen, die mit großen Fakten gejoined werden.
- **AUTO**: Lässt Redshift basierend auf Tabellengröße und Abfragemustern entscheiden.

**Frage 4: Wie optimiert man Abfragekosten in BigQuery?**

BigQuery-Kosten lassen sich optimieren durch Partitionierung von Tabellen nach häufig gefilterten Datumsspalten, Clustering nach Spalten mit hoher Kardinalität, Vermeidung von SELECT *-Abfragen, Verwendung approximativer Aggregationsfunktionen (APPROX_COUNT_DISTINCT) für explorative Analysen, Materialisierung von Zwischenergebnissen für wiederholte Berechnungen und Einrichtung von Kostenkontrollen mit benutzerdefinierten Kontingenten.

**Frage 5: Welche Monitoring-Tools existieren für Redshift-Performance?**

Redshift bietet Systemtabellen und Views für Performance-Monitoring: STL_QUERY protokolliert Abfrageausführungsdetails, STL_WLM_QUERY zeigt Workload-Management-Statistiken, SVL_QUERY_REPORT zeigt Metriken auf Schrittebene, und CloudWatch-Metriken verfolgen den Cluster-Zustand. Die Abfrageperformance kann sich verschlechtern, wenn Vacuum-Operationen überfällig sind oder Tabellenstatistiken veraltet werden.

## Sicherheit und Compliance-Fähigkeiten

Beide Plattformen unterstützen Verschlüsselung auf Spaltenebene, VPC-Isolation und Audit-Logging. BigQuery erzwingt feinkörnigen Zugriff durch [IAM und Sicherheitsrichtlinien auf Spaltenebene](https://cloud.google.com/bigquery/docs/column-level-security). Datenmaskierung und Row-Level-Security ermöglichen mandantenfähige Architekturen.

Redshift bietet ähnliche Kontrollen durch IAM-Integration, Zugriffssteuerung auf Spaltenebene und dynamische Datenmaskierung. Regions-übergreifende Snapshot-Replikation unterstützt Disaster-Recovery-Anforderungen.

Beide Plattformen unterhalten SOC 1/2/3, ISO 27001, HIPAA und PCI-DSS-Compliance-Zertifizierungen. Feature-Parität besteht für die meisten Enterprise-Sicherheitsanforderungen, wodurch die Wahl eher von bestehenden Cloud-Anbieter-Beziehungen als von Sicherheitsfähigkeiten abhängt.

## Migrationsüberlegungen und Hybrid-Ansätze

Die Migration zwischen Plattformen erfordert die Behandlung von SQL-Dialekt-Unterschieden, Datentyp-Mappings und ETL-Workflow-Umschreibungen. BigQuery Migration Service bewertet Redshift-Workloads und automatisiert SQL-Übersetzung. AWS Database Migration Service übernimmt die umgekehrte Richtung.

Viele Organisationen adoptieren Hybrid-Strategien und fragen über beide Plattformen hinweg durch Federated-Query-Funktionen ab. BigQuery Omni läuft auf AWS-Infrastruktur und ermöglicht BigQuery-SQL gegen S3-Daten. Redshift Data Sharing unterstützt kontoübergreifende Query-Federation innerhalb von AWS.

Data-Analytics-Teams wählen zunehmend basierend auf bestehenden Cloud-Investitionen statt technischer Überlegenheit. Beide Plattformen fügen kontinuierlich Features hinzu, die historische Einschränkungen adressieren und die funktionale Lücke verkleinern.

## Fazit

- BigQuery eignet sich für Teams, die serverlose Einfachheit und variable Workloads mit Pay-per-Query-Abrechnung priorisieren
- Redshift passt zu Organisationen mit planbaren, hochvolumigen Abfragen, wo provisionierte Kapazität Kostenvorteile bietet
- SQL-Syntaxunterschiede erfordern Aufmerksamkeit bei Migrationsplanung und Team-Training
- Performance-Optimierungsansätze unterscheiden sich grundlegend: BigQuery betont Partitionierung und Clustering, Redshift erfordert Distribution Keys und Sort Keys
- Interviewfragen konzentrieren sich auf architektonische Kompromisse, Kostenoptimierungsstrategien und plattformspezifische Tuning-Techniken
- Sicherheits- und Compliance-Fähigkeiten sind vergleichbar; Cloud-Ökosystem-Integration bestimmt oft die Plattformwahl

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/de/blog/data-analytics/bigquery-vs-redshift-comparison-interview-2026