Data Engineering

Cloud-Datenbank auswählen: Decision-Framework für Architekten (2026)

Strukturiertes Decision-Framework für die Wahl der richtigen Cloud-Datenbank: relationale, NoSQL-, Time-Series-, Graph-, Vector- und OLAP-Datenbanken im Vergleich mit konkretem Use-Case-Mapping.

Harbinger Team3. April 20269 Min. LesezeitAktualisiert 14.5.2026
  • datenbanken
  • cloud-architektur
  • postgresql
  • dynamodb
  • bigquery
  • vector-db
Inhaltsverzeichnis22 Abschnitte

Eine Cloud-Datenbank zu wählen ist eine der hebelstärksten Architektur-Entscheidungen, die ein Plattform-Team trifft. Triffst du sie richtig, hast du ein Fundament, das jahrelang skaliert, performt und wartbar bleibt. Triffst du sie falsch, steht eine schmerzhafte, teure Migration genau zum schlechtesten Zeitpunkt an — wenn deine User-Base gerade wächst.

Dieser Guide gibt dir ein strukturiertes Decision-Framework plus Deep-Dive-Vergleiche über alle wichtigen Datenbank-Kategorien.

TL;DR

  • Default für neue Apps: PostgreSQL mit Extensions (JSONB, pgvector, PostGIS) — verschiebt Spezialisierte-Stores oft um Jahre.
  • Hoher Throughput, einfache Access-Patterns: DynamoDB oder Firestore.
  • Time-Series: TimescaleDB (wenn du Postgres schon hast) oder InfluxDB.
  • Analytics: BigQuery für unvorhersehbare Last, Snowflake für vorhersehbare High-Concurrency.
  • Semantic Search: Pinecone für Scale, pgvector für < 10M Embeddings.
  • Polyglot ist Normalfall: 3–5 verschiedene Stores in Production sind Standard.

Das Decision-Framework

Bevor du konkrete Produkte vergleichst, beantworte diese fünf Fragen:

graph TD
    Q1{Was ist dein
primäres Access-Pattern?}
    Q1 --> Q1A[Key-Value / Document
Lookups]
    Q1 --> Q1B[Komplexe relationale
Queries / Joins]
    Q1 --> Q1C[Time-Series
Append-heavy]
    Q1 --> Q1D[Graph-Traversal]
    Q1 --> Q1E[Analytisch /
Aggregation]
    Q1 --> Q1F[Semantische Ähnlichkeit
Vector-Search]

    Q1A --> Q2A{Scale?}
    Q2A -->|< 100M Zeilen, kein Extrem-Scale| RDB[PostgreSQL / MySQL]
    Q2A -->|Massive Scale, variables Schema| NOSQL[DynamoDB / Firestore]

    Q1B --> RDB
    Q1C --> TSDB[TimescaleDB / InfluxDB /
Amazon Timestream]
    Q1D --> GDB[Neo4j / Amazon Neptune /
ArangoDB]
    Q1E --> OLAP[BigQuery / Redshift /
Snowflake / Databricks]
    Q1F --> VDB[Pinecone / Weaviate /
pgvector]

Kategorie 1: Relationale Datenbanken (OLTP)

Passt zu: Transaktionale Workloads, komplexe Queries, referentielle Integrität, Finanzdaten, User-Accounts.

Managed Options im Vergleich

DatenbankCloudMax StorageConnection-LimitsManaged
Amazon Aurora PostgreSQLAWSUnlimited (Serverless v2)5.000Voll
Cloud SQL PostgreSQLGCP64 TB10.000Voll
Azure Database for PostgreSQLAzure64 TB~1.000Voll
NeonMulti-CloudUnlimitedUnlimited (serverless)Voll
PlanetScaleMulti-CloudUnlimitedUnlimitedVoll

Wann PostgreSQL

PostgreSQL ist die Default-Wahl für die meisten neuen Anwendungen. Es kann:

  • JSONB: Semi-strukturierte Daten ohne Schema-Migration
  • Full-Text-Search: tsvector für leichtgewichtige Suche ohne Elasticsearch
  • Time-Series: mit TimescaleDB-Extension
  • Vector-Search: mit pgvector-Extension
  • Geospatial: mit PostGIS-Extension

Die Fähigkeit, PostgreSQL zu erweitern, verschiebt den Bedarf an Spezialstores oft um Jahre.

Terraform: Aurora Serverless v2

resource "aws_rds_cluster" "harbinger" {
  cluster_identifier     = "harbinger-prod"
  engine                 = "aurora-postgresql"
  engine_version         = "15.4"
  database_name          = "harbinger"
  master_username        = "admin"
  manage_master_user_password = true  # Secrets-Manager-Integration
  
  serverlessv2_scaling_configuration {
    min_capacity = 0.5
    max_capacity = 64
  }

  backup_retention_period = 14
  preferred_backup_window = "02:00-03:00"
  
  enabled_cloudwatch_logs_exports = ["postgresql"]
  
  deletion_protection = true
  skip_final_snapshot = false
  final_snapshot_identifier = "harbinger-prod-final"

  tags = {
    Environment = "production"
  }
}

Kategorie 2: NoSQL Document / Key-Value

Passt zu: High-Throughput-Key-Value-Access, flexible Schemata, globale Verteilung, Event-Sourcing.

DynamoDB vs. Firestore vs. MongoDB Atlas

FeatureDynamoDBFirestoreMongoDB Atlas
CloudNur AWSGCP / multiMulti-Cloud
Pricing-ModellOn-Demand / ProvisionedPro OperationInstance-basiert
Query-FlexibilitätSingle-Table-Design nötigRich QueriesVolle MongoDB-Query-API
Real-Time-SubscriptionsVia Streams + LambdaNativeChange Streams
Globale VerteilungGlobal TablesNative Multi-RegionAtlas Global Clusters
Secondary IndexesGSI/LSIComposite IndexesBeliebiges Feld
Max Item-Size400 KB1 MB16 MB

DynamoDB Single-Table-Design-Pattern

# Mehrere Entity-Typen in einer DynamoDB-Tabelle
# mit Composite-Keys und GSIs

table_schema = {
    "TableName": "harbinger-events",
    "KeySchema": [
        {"AttributeName": "PK", "KeyType": "HASH"},   # z.B. COUNTRY#US
        {"AttributeName": "SK", "KeyType": "RANGE"},  # z.B. EVENT#2024-01-15#uuid
    ],
    "GlobalSecondaryIndexes": [
        {
            "IndexName": "EventTypeIndex",
            "KeySchema": [
                {"AttributeName": "GSI1PK", "KeyType": "HASH"},  # EVENT_TYPE#CONFLICT
                {"AttributeName": "GSI1SK", "KeyType": "RANGE"}, # DATE#2024-01-15
            ],
            "Projection": {"ProjectionType": "ALL"},
        }
    ],
    "BillingMode": "PAY_PER_REQUEST",
}

# Access-Patterns, die das ermöglicht:
# 1. Alle Events für ein Land: PK=COUNTRY#US, SK begins_with EVENT#
# 2. Events nach Typ: GSI1PK=EVENT_TYPE#CONFLICT, GSI1SK between Dates
# 3. Einzelnes Event: PK=COUNTRY#US, SK=EVENT#2024-01-15#abc123

Kategorie 3: Time-Series-Datenbanken

Passt zu: Metrics, IoT-Sensordaten, Finanz-Tick-Daten, Monitoring-Telemetrie.

Time-Series-Stores im Vergleich

StoreWrite-ThroughputQuery-LanguageRetention-PoliciesCloud-Native
Amazon TimestreamMillionen/sSQL-likeAuto-TieringAWS
InfluxDB CloudHighFlux / InfluxQLConfigurableMulti
TimescaleDBHighVolles SQLSQL-basiertMulti
PrometheusModeratePromQLConfigurableBeliebiges K8s
OpenTSDBSehr hochHTTP-APIConfigurableSelbst-gehostet

TimescaleDB Hypertable

-- Hypertable für geopolitische Risk-Scores
CREATE TABLE risk_scores (
    time        TIMESTAMPTZ NOT NULL,
    country     TEXT NOT NULL,
    risk_score  FLOAT NOT NULL,
    event_count INTEGER,
    source      TEXT
);

-- In Hypertable umwandeln, partitioniert nach Zeit
SELECT create_hypertable('risk_scores', 'time', chunk_time_interval => INTERVAL '1 day');

-- Compression-Policy hinzufügen (Chunks älter als 7 Tage)
ALTER TABLE risk_scores SET (
    timescaledb.compress,
    timescaledb.compress_segmentby = 'country'
);
SELECT add_compression_policy('risk_scores', INTERVAL '7 days');

-- Retention-Policy (Daten älter als 2 Jahre droppen)
SELECT add_retention_policy('risk_scores', INTERVAL '2 years');

-- Query: Risk-Score-Trend mit Gap-Filling
SELECT
    time_bucket_gapfill('1 hour', time) AS bucket,
    country,
    AVG(risk_score) as avg_risk,
    locf(AVG(risk_score)) as filled_risk  -- last observation carried forward
FROM risk_scores
WHERE country = 'UA'
    AND time > NOW() - INTERVAL '30 days'
GROUP BY bucket, country
ORDER BY bucket;

Kategorie 4: Analytische Datenbanken (OLAP)

Passt zu: Business Intelligence, Ad-hoc-Analyse, Aggregationen über Milliarden Zeilen.

OLAP-Vergleich: BigQuery vs. Redshift vs. Snowflake vs. Databricks

FeatureBigQueryRedshiftSnowflakeDatabricks SQL
PricingPro Query (TB gescannt)Pro Cluster-StundePro CreditPro DBU
ServerlessJa (voll)Serverless-OptionJa (Serverless)Serverless-Option
Storage-FormatCapacitor (proprietär)Parquet/ORCFDN (proprietär)Delta Lake
ML-IntegrationBigQuery MLRedshift MLSnowpark MLMLflow native
Streaming-IngestBigQuery Storage WriteKinesis FirehoseSnowpipeAutoloader
Git-IntegrationLimitiertLimitiertLimitiertNative (DBX)
Max Query-Ergebnis10 GBUnlimitedUnlimitedUnlimited
Time-Travel7 Tage5 Tage90 Tage30 Tage (Delta)

Cost-Optimierung

BigQuery:

-- Tabellen partitionieren, um gescannte Bytes zu reduzieren
CREATE TABLE harbinger_prod.events.geopolitical
PARTITION BY DATE(event_date)
CLUSTER BY country_code, event_type
AS SELECT * FROM staging.raw_events;

-- Partition-Filter in Queries verwenden (Full-Table-Scans vermeiden)
SELECT country_code, COUNT(*) as event_count
FROM harbinger_prod.events.geopolitical
WHERE DATE(event_date) BETWEEN '2024-01-01' AND '2024-03-31'  -- Partition-Pruning
GROUP BY country_code;

Kategorie 5: Vector-Datenbanken

Passt zu: Semantische Suche, RAG (Retrieval-Augmented Generation), Recommendation-Systeme, Similarity-Matching.

Vector-Datenbanken im Vergleich

DatenbankIndexingMax VektorenFilteringCloud-Managed
PineconeHNSWMilliardenJa (Metadaten)Ja
WeaviateHNSW + BM25MilliardenJaJa (Cloud)
QdrantHNSWMilliardenJaJa (Cloud)
pgvectorHNSW / IVFFlat~10M (praktisch)Volles SQLVia PostgreSQL
ChromaHNSWMillionenJaSelbst-gehostet
MilvusMehrereMilliardenJaZilliz Cloud

pgvector für Intelligence-Plattformen

-- pgvector aktivieren
CREATE EXTENSION IF NOT EXISTS vector;

-- Artikel-Embeddings neben Metadaten speichern
CREATE TABLE article_embeddings (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    article_id  TEXT NOT NULL,
    title       TEXT NOT NULL,
    country     TEXT,
    event_date  DATE,
    embedding   vector(1536),  -- Dimensionen OpenAI text-embedding-3-small
    created_at  TIMESTAMPTZ DEFAULT NOW()
);

-- HNSW-Index für schnelle Approximate-Nearest-Neighbour-Search
CREATE INDEX ON article_embeddings USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Semantic Search: ähnliche geopolitische Events finden
SELECT
    article_id,
    title,
    country,
    event_date,
    1 - (embedding <=> $1::vector) AS similarity
FROM article_embeddings
WHERE country = 'UA'  -- pre-filter by country
    AND event_date > '2024-01-01'
ORDER BY embedding <=> $1::vector
LIMIT 20;

Das Polyglot-Persistence-Pattern

Die meisten produktiven Plattformen nutzen mehrere Datenbank-Typen — der Schlüssel ist, jeden Store auf seine Stärken zu mappen:

graph LR
    APP[Application-Layer]
    
    APP --> PG[(PostgreSQL
User-Daten, Config,
transaktional)]
    APP --> DDB[(DynamoDB
High-Throughput
API-Responses)]
    APP --> REDIS[(Redis
Cache, Sessions,
Rate-Limiting)]
    APP --> PGV[(pgvector
Semantische Suche
RAG)]
    APP --> BQ[(BigQuery
Analytics,
BI-Queries)]
    APP --> TS[(TimescaleDB
Metrics,
Risk-Scores)]

Decision-Checkliste

Nutz diese Checkliste, bevor du dich auf eine Datenbank festlegst:

Workload-Charakteristik

  • Primary Access-Pattern dokumentiert (Point-Lookup / Range-Scan / Aggregation)
  • Erwartetes Read/Write-Ratio
  • Peak-QPS-Schätzungen (p50, p99)
  • Datenvolumen bei Launch und 2-Jahres-Projektion

Consistency-Anforderungen

  • Brauchst du ACID-Transaktionen? (→ RDBMS)
  • Tolerierst du Eventual Consistency? (→ NoSQL/distributed)
  • Brauchst du Multi-Region-Writes? (CockroachDB, DynamoDB Global Tables)

Operational

  • Managed Service vs. selbst gehostet?
  • Team-Vertrautheit mit der Query-Sprache?
  • Migrations-Pfad, falls sich Anforderungen ändern?
  • Cost-Modell verstanden (pro Query vs. pro Stunde vs. pro Zeile)?

FAQ

Welche Datenbank für ein neues SaaS-MVP? PostgreSQL — Punkt. Du bekommst JSONB für Flexibilität, Full-Text-Search, und mit Extensions kannst du später Vector-Search oder Time-Series draufpacken, ohne Migration.

Wann lohnt sich DynamoDB statt Postgres? Ab konstant > 10.000 Reads/s mit einfachen Lookups oder wenn du globale Multi-Region-Writes brauchst. Drunter ist Postgres + Read- Replicas billiger und flexibler.

Welche DACH-spezifischen Considerations? DSGVO erfordert nachvollziehbare Daten-Lokation. Cloud SQL und Aurora in eu-central-1 (Frankfurt) sind safe. Snowflake EU-Central erfordert Enterprise-Tier. Hetzner + Managed-Postgres ist eine günstige Alternative.

Was kostet ein Wechsel zwischen Datenbanken realistisch? Bei 100k Zeilen mit klarem Schema: 1–2 Wochen. Bei 100M Zeilen mit Custom-Indexes und gewachsenen Queries: 3–6 Monate, inklusive Re-Tooling aller BI-Reports und ETL-Pipelines.

Fazit

Die richtige Cloud-Datenbank-Entscheidung ist immer kontextabhängig. Widersteh der Versuchung, alles auf eine Datenbank zu standardisieren — der Performance-Gap zwischen einem passend gewählten Store und einem General-Purpose-Store kann 10–100x betragen.

Plattformen, die diverse Datentypen verarbeiten — wie Harbinger Explorer, das News-Events, Risk-Scores, Time-Series-Indikatoren und semantische Signale korreliert — laufen oft mit 3–5 verschiedenen Datenbank-Typen in Production, jede optimiert für ihr spezifisches Access-Pattern.

Preis- und Feature-Stand: April 2026. Cloud-Provider iterieren schnell — verifiziere kritische Annahmen direkt bei AWS, GCP und Azure.

H

Geschrieben von

Harbinger Team

Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastruktur­kritische Tech-Entscheidungen — keine Marketing- Folien, sondern echte Trade-offs aus Production-Workloads.

Hat dir das geholfen?

Jede Woche ein neuer Artikel über DACH-Cloud, Data und AI — direkt in dein Postfach. Kein Spam, kein Marketing-Sprech.

Kein Spam. 1-Klick-Abmeldung. Datenschutz bei Loops.so.