# Google BigQuery vs Amazon Redshift in 2026: Vergelijking en Sollicitatievragen voor Data Analysts

> Een uitgebreide vergelijking van BigQuery en Redshift in 2026. Architectuur, prijsmodellen, SQL-verschillen en veelgestelde sollicitatievragen voor 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 en Amazon Redshift domineren de cloud data warehouse markt in 2026, waarbij elk platform eigen voordelen biedt voor [data analytics](/technologies/data-analytics) workloads. Deze vergelijking behandelt architectuurverschillen, prijsmodellen, performance-eigenschappen en de sollicitatievragen die Data Analyst kandidaten regelmatig tegenkomen.

> **Snelle Beslissingshulp**
>
> Kies BigQuery voor serverless eenvoud, pay-per-query prijzen en sterke GCP-integratie. Kies Redshift voor voorspelbare kosten op schaal, complexe ETL-pipelines en diepe AWS-ecosysteem integratie.

## Architectuurverschillen tussen BigQuery en Redshift

BigQuery gebruikt een serverless, multi-tenant architectuur waarbij storage en compute volledig gescheiden zijn. Queries draaien op dynamisch toegewezen resources zonder enig clusterbeheer. Google handelt alle infrastructuurscaling, patches en optimalisaties automatisch af.

Redshift werkt met een provisioned cluster model met dedicated nodes. Storage en compute zijn nauw gekoppeld binnen nodes, hoewel [Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-whatis.html) nu een verbruiksgebaseerd alternatief biedt. Het RA3 node type introduceerde managed storage scheiding, waardoor onafhankelijke scaling van compute en storage mogelijk wordt.

| Aspect | BigQuery | Redshift |
|--------|----------|----------|
| Deployment | Volledig serverless | Provisioned clusters of Serverless |
| Storage-Compute | Volledig gescheiden | Gekoppeld (RA3 scheidt managed storage) |
| Scaling | Automatisch | Handmatige resize of Concurrency Scaling |
| Onderhoud | Geen | Onderhoudsvensters vereist |
| Cold Start | Geen | Cluster herstarttijd indien gepauzeerd |

Dit architectuurverschil heeft aanzienlijke impact op de operationele overhead. BigQuery vereist geen capaciteitsplanning, terwijl Redshift voortdurende beslissingen over cluster-sizing en onderhoudsplanning vereist.

## Prijsmodellen: Pay-per-Query vs Provisioned Capacity

BigQuery rekent 6,25 USD per TB gescand in on-demand modus (stand 2026). Reserved capacity (flat-rate) prijzen bieden voorspelbare maandelijkse kosten voor constante workloads. Opslagkosten bedragen 0,02 USD/GB/maand voor actieve data en 0,01 USD/GB/maand voor langetermijnopslag na 90 dagen.

```sql
-- BigQuery: Querykosten controleren voor uitvoering
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-prijzen hangen af van node type en aantal. DC2 nodes (dense compute) beginnen bij 0,25 USD/uur, terwijl RA3 nodes met managed storage beginnen bij 1,086 USD/uur. Redshift Serverless rekent op basis van verbruikte Redshift Processing Units (RPUs).

Kostenoptimalisatiestrategieën verschillen fundamenteel. BigQuery beloont query-optimalisatie door partitionering en clustering, aangezien minder data scannen de kosten direct verlaagt. Bij Redshift richt de optimalisatie zich op het correct dimensioneren van clusters en het benutten van reserved instances voor voorspelbare workloads.

## SQL-Syntax en Functieverschillen

Beide platformen ondersteunen ANSI SQL, maar er bestaan syntaxvariaties voor geavanceerde functies. Het begrijpen van deze verschillen is belangrijk voor [SQL sollicitatievragen](/technologies/data-analytics/interview-questions/sql-subqueries-ctes) en migratieprojecten.

```sql
-- BigQuery: Datumfuncties met EXTRACT en 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: Vergelijkbaar maar DATE_TRUNC met 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;
```

De verwerking van arrays en structs toont significante afwijkingen. BigQuery ondersteunt native geneste en herhaalde velden met UNNEST operaties. Redshift verwerkt semi-gestructureerde data via het SUPER type en PartiQL syntax die in recente versies is geintroduceerd.

```sql
-- BigQuery: Werken met geneste 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 type met 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-eigenschappen en Query-optimalisatie

BigQuery blinkt uit bij ad-hoc analytische queries op massale datasets zonder tuning. Het slot-gebaseerde uitvoeringsmodel verdeelt werk automatisch. De performance blijft consistent ongeacht gelijktijdige gebruikers aangezien elke query dedicated resources uit de slot pool ontvangt.

Redshift levert superieure performance voor voorspelbare, repetitieve queries wanneer het correct is geconfigureerd. Distribution keys, sort keys en materialized views beinvloeden de querysnelheid aanzienlijk. De query planner genereert geoptimaliseerde uitvoeringsplannen gebaseerd op tabelstatistieken.

```sql
-- Redshift: Definitie van distribution en 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 voor dashboard queries
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-optimalisatie is gebaseerd op partitionering en clustering. Partitionering vermindert gescande data op datum of integer range. Clustering sorteert data binnen partities voor snellere gefilterde queries.

```sql
-- BigQuery: Gepartitioneerde en geclusterde tabel
CREATE TABLE `project.dataset.sales_fact`
PARTITION BY DATE(sale_date)
CLUSTER BY customer_id, product_id
AS SELECT * FROM `project.dataset.raw_sales`;
```

Voor performance tuning strategieen over gerelateerde onderwerpen behandelt de [gids over Window Functions en CTEs](/blog/data-analytics/sql-window-functions-ctes-advanced-queries) geavanceerde query-optimalisatietechnieken.

## Data Laden en ETL-Integratie

BigQuery ondersteunt streaming inserts voor real-time data tegen 0,05 USD per GB, gratis batch laden vanuit Cloud Storage en native connectors voor Dataflow en Pub/Sub. De BigQuery Data Transfer Service automatiseert geplande imports vanuit SaaS-applicaties.

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

Redshift integreert nauw met S3 via het COPY commando, dat het laden van data over cluster nodes paralleliseert. AWS Glue biedt managed ETL, terwijl Redshift Spectrum S3 data direct bevraagt zonder te laden.

```sql
-- Redshift: COPY commando met optimale instellingen
COPY events
FROM 's3://bucket/events/'
IAM_ROLE 'arn:aws:iam::123456789:role/RedshiftS3Access'
FORMAT AS PARQUET
COMPUPDATE ON
STATUPDATE ON;
```

Beide platformen ondersteunen nu het [Apache Iceberg](https://iceberg.apache.org/) tabelformaat voor externe data lakes. BigQuery BigLake en Redshift Spectrum maken unified analytics mogelijk over data warehouse en data lake storage.

## Sollicitatievragen: BigQuery vs Redshift Vergelijking

Data Analyst sollicitaties testen regelmatig het begrip van cloud data warehouse afwegingen. Deze vragen verschijnen bij rollen die cloud platform expertise vereisen.

**Vraag 1: Wanneer zou je BigQuery aanbevelen boven Redshift?**

BigQuery wordt aanbevolen wanneer de organisatie serverless operatie zonder infrastructuurbeheer nodig heeft, pay-per-query prijzen passen bij onvoorspelbare of piekerige workloads, het dataplatform al op GCP draait, of teams onmiddellijke queryresultaten nodig hebben op petabyte-schaal data zonder cluster provisioning vertragingen.

**Vraag 2: Hoe werkt slot allocatie in BigQuery?**

BigQuery wijst slots (eenheden van rekencapaciteit) dynamisch toe aan queries. On-demand queries delen een pool van 2.000 slots per project. Elke slot vertegenwoordigt ongeveer een virtuele CPU met streaming toegang tot Colossus (gedistribueerde opslag). Complexe queries die meer parallellisme vereisen ontvangen proportioneel meer slots totdat de beschikbare capaciteit is uitgeput.

**Vraag 3: Leg Redshift distribution styles uit en wanneer elk te gebruiken.**

Redshift biedt vier distribution styles:
- **KEY**: Verdeelt rijen op hash van gespecificeerde kolom. Gebruik voor grote fact tabellen die frequent gejoined worden op die kolom.
- **EVEN**: Verdeelt rijen round-robin over nodes. Gebruik voor tabellen zonder duidelijke join patronen.
- **ALL**: Kopieert hele tabel naar elke node. Gebruik voor kleine dimensie tabellen die gejoined worden met grote facts.
- **AUTO**: Laat Redshift beslissen gebaseerd op tabelgrootte en query patronen.

**Vraag 4: Hoe optimaliseer je querykosten in BigQuery?**

BigQuery kosten worden geoptimaliseerd door tabellen te partitioneren op vaak gefilterde datumkolommen, te clusteren op hoge cardinaliteit kolommen, SELECT * queries te vermijden, approximate aggregatiefuncties te gebruiken (APPROX_COUNT_DISTINCT) voor verkennende analyses, tussenresultaten te materialiseren voor herhaalde berekeningen en kostencontroles in te stellen met aangepaste quota.

**Vraag 5: Welke monitoring tools bestaan er voor Redshift performance?**

Redshift biedt systeemtabellen en views voor performance monitoring: STL_QUERY logt query-uitvoeringsdetails, STL_WLM_QUERY toont workload management statistieken, SVL_QUERY_REPORT geeft metrieken op stapniveau weer, en CloudWatch metrieken volgen de clusterstatus. Query performance kan degraderen wanneer vacuum operaties achterstallig zijn of wanneer tabelstatistieken verouderd raken.

## Beveiligings- en Compliance Mogelijkheden

Beide platformen ondersteunen encryptie op kolomniveau, VPC isolatie en audit logging. BigQuery handhaaft fijnmazige toegang via [IAM en beveiligingsbeleid op kolomniveau](https://cloud.google.com/bigquery/docs/column-level-security). Data masking en row-level security maken multi-tenant architecturen mogelijk.

Redshift biedt vergelijkbare controles via IAM integratie, toegangsbeheer op kolomniveau en dynamische data masking. Cross-region snapshot replicatie ondersteunt disaster recovery vereisten.

Beide platformen handhaven SOC 1/2/3, ISO 27001, HIPAA en PCI DSS compliance certificeringen. Er bestaat feature pariteit voor de meeste enterprise beveiligingsvereisten, waardoor de keuze afhankelijk wordt van bestaande cloud provider relaties in plaats van beveiligingsmogelijkheden.

## Migratie-overwegingen en Hybride Benaderingen

Migratie tussen platformen vereist het aanpakken van SQL dialect verschillen, datatype mappings en ETL workflow herschrijvingen. BigQuery Migration Service evalueert Redshift workloads en automatiseert SQL vertaling. AWS Database Migration Service handelt de omgekeerde richting af.

Veel organisaties adopteren hybride strategieen en bevragen beide platformen via federated query mogelijkheden. BigQuery Omni draait op AWS infrastructuur, waardoor BigQuery SQL tegen S3 data mogelijk wordt. Redshift data sharing ondersteunt cross-account query federatie binnen AWS.

Data analytics teams kiezen steeds vaker gebaseerd op bestaande cloud investeringen in plaats van technische superioriteit. Beide platformen blijven functies toevoegen die historische beperkingen aanpakken, waardoor de functionele kloof verkleint.

## Conclusie

- BigQuery past bij teams die serverless eenvoud en variabele workloads met pay-per-query facturering prioriteren
- Redshift past bij organisaties met voorspelbare, hoog-volume queries waar provisioned capacity kostenvoordelen biedt
- SQL syntax verschillen vereisen aandacht bij migratieplanning en teamtraining
- Performance optimalisatie benaderingen verschillen fundamenteel: BigQuery benadrukt partitionering en clustering, Redshift vereist distribution keys en sort keys
- Sollicitatievragen focussen op architecturale afwegingen, kostenoptimalisatiestrategieen en platformspecifieke tuning technieken
- Beveiligings- en compliance mogelijkheden zijn vergelijkbaar; cloud ecosysteem integratie bepaalt vaak de platformkeuze

---

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