Inhaltsverzeichnis22 Abschnitte
- TL;DR
- Das Decision-Framework
- Kategorie 1: Relationale Datenbanken (OLTP)
- Managed Options im Vergleich
- Wann PostgreSQL
- Terraform: Aurora Serverless v2
- Kategorie 2: NoSQL Document / Key-Value
- DynamoDB vs. Firestore vs. MongoDB Atlas
- DynamoDB Single-Table-Design-Pattern
- Kategorie 3: Time-Series-Datenbanken
- Time-Series-Stores im Vergleich
- TimescaleDB Hypertable
- Kategorie 4: Analytische Datenbanken (OLAP)
- OLAP-Vergleich: BigQuery vs. Redshift vs. Snowflake vs. Databricks
- Cost-Optimierung
- Kategorie 5: Vector-Datenbanken
- Vector-Datenbanken im Vergleich
- pgvector für Intelligence-Plattformen
- Das Polyglot-Persistence-Pattern
- Decision-Checkliste
- FAQ
- Fazit
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
| Datenbank | Cloud | Max Storage | Connection-Limits | Managed |
|---|---|---|---|---|
| Amazon Aurora PostgreSQL | AWS | Unlimited (Serverless v2) | 5.000 | Voll |
| Cloud SQL PostgreSQL | GCP | 64 TB | 10.000 | Voll |
| Azure Database for PostgreSQL | Azure | 64 TB | ~1.000 | Voll |
| Neon | Multi-Cloud | Unlimited | Unlimited (serverless) | Voll |
| PlanetScale | Multi-Cloud | Unlimited | Unlimited | Voll |
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:
tsvectorfü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
| Feature | DynamoDB | Firestore | MongoDB Atlas |
|---|---|---|---|
| Cloud | Nur AWS | GCP / multi | Multi-Cloud |
| Pricing-Modell | On-Demand / Provisioned | Pro Operation | Instance-basiert |
| Query-Flexibilität | Single-Table-Design nötig | Rich Queries | Volle MongoDB-Query-API |
| Real-Time-Subscriptions | Via Streams + Lambda | Native | Change Streams |
| Globale Verteilung | Global Tables | Native Multi-Region | Atlas Global Clusters |
| Secondary Indexes | GSI/LSI | Composite Indexes | Beliebiges Feld |
| Max Item-Size | 400 KB | 1 MB | 16 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
| Store | Write-Throughput | Query-Language | Retention-Policies | Cloud-Native |
|---|---|---|---|---|
| Amazon Timestream | Millionen/s | SQL-like | Auto-Tiering | AWS |
| InfluxDB Cloud | High | Flux / InfluxQL | Configurable | Multi |
| TimescaleDB | High | Volles SQL | SQL-basiert | Multi |
| Prometheus | Moderate | PromQL | Configurable | Beliebiges K8s |
| OpenTSDB | Sehr hoch | HTTP-API | Configurable | Selbst-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
| Feature | BigQuery | Redshift | Snowflake | Databricks SQL |
|---|---|---|---|---|
| Pricing | Pro Query (TB gescannt) | Pro Cluster-Stunde | Pro Credit | Pro DBU |
| Serverless | Ja (voll) | Serverless-Option | Ja (Serverless) | Serverless-Option |
| Storage-Format | Capacitor (proprietär) | Parquet/ORC | FDN (proprietär) | Delta Lake |
| ML-Integration | BigQuery ML | Redshift ML | Snowpark ML | MLflow native |
| Streaming-Ingest | BigQuery Storage Write | Kinesis Firehose | Snowpipe | Autoloader |
| Git-Integration | Limitiert | Limitiert | Limitiert | Native (DBX) |
| Max Query-Ergebnis | 10 GB | Unlimited | Unlimited | Unlimited |
| Time-Travel | 7 Tage | 5 Tage | 90 Tage | 30 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
| Datenbank | Indexing | Max Vektoren | Filtering | Cloud-Managed |
|---|---|---|---|---|
| Pinecone | HNSW | Milliarden | Ja (Metadaten) | Ja |
| Weaviate | HNSW + BM25 | Milliarden | Ja | Ja (Cloud) |
| Qdrant | HNSW | Milliarden | Ja | Ja (Cloud) |
| pgvector | HNSW / IVFFlat | ~10M (praktisch) | Volles SQL | Via PostgreSQL |
| Chroma | HNSW | Millionen | Ja | Selbst-gehostet |
| Milvus | Mehrere | Milliarden | Ja | Zilliz 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.
Geschrieben von
Harbinger Team
Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastrukturkritische 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.