DEV Community: Aleksei Aleinikov

GKE Autopilot vs Standard 2026: Die echten Trade-offs

Aleksei Aleinikov — Wed, 15 Jul 2026 12:00:00 +0000

Die Wahl zwischen GKE Autopilot und Standard sieht wie eine Checkbox bei der Cluster-Erstellung aus. Es ist tatsächlich eine Entscheidung, die dein Abrechnungsmodell, deine Betriebsgrenzen und die ausführbaren Workloads für die gesamte Lebensdauer des Clusters festlegt. Der Modus lässt sich danach nicht mehr wechseln.

Die meisten Vergleiche listen Features auf. Dieser beginnt dort, wo die Feature-Liste die eigentliche Antwort verbirgt: wer die Worker-Node-Schicht besitzt.

Das Eine, was beide Modi gemeinsam haben

Beide Modi betreiben dieselbe von Google verwaltete Control Plane. etcd, API-Server, Scheduler, Controller Manager — Google verwaltet, aktualisiert und betreibt alles davon hochverfügbar. Du provisionierst keinen Control-Plane-Node, weil es keinen zu provisionieren gibt. Es ist ein vollständig verwalteter Dienst hinter dem container.googleapis.com-Endpunkt.

Das ist kein Differenzierungsmerkmal. Der eigentliche Unterschied liegt vollständig unterhalb der Control Plane.

Autopilot: Die Node-Schicht verschwindet

Im Autopilot-Modus abstrahiert Google alles unterhalb der Pod-Ebene.

Node-Provisioning ist automatisch. Du erstellst oder löschst keine Node Pools. Wenn du einen Pod mit einem gültigen Resource-Request deployest, provisioniert Google automatisch einen passenden Node. Wenn der Pod endet, skaliert der Node herunter. Der Node ist ein Implementierungsdetail, das du nicht verwaltest.

Du forderst Kapazität an, keine Maschinen. Standardmäßig (GKE 1.32.3-gke.1927002 und später) laufen Pods auf der Container-optimierten Compute-Plattform — Nodes, die zur Laufzeit dynamisch skalieren und ab Bruchteilen einer vCPU wachsen, sodass neue Pods selten auf das Booten eines Nodes warten. Braucht ein Workload spezifische Hardware, forderst du eine ComputeClass an, statt einen Node Pool zu verwalten:

Balanced / Scale-Out — General-Purpose; Scale-Out wählt Arm (T2A) für zustandslose Dichte
Performance — Compute-optimierte Machine-Serie
Accelerator — GPUs und TPUs, angefordert in der ComputeClass oder im Pod-Spec
autopilot-spot — unterbrechungstolerante Spot-Pods

GKE provisioniert und dimensioniert die passenden Nodes automatisch.

Security-Posture wird erzwungen. Pods laufen standardmäßig als Nicht-Root, hostPath-Volumes und Host-Networking sind gesperrt, und Google pflegt das Node-OS. Diese Einschränkungen sind keine Konfigurationsoptionen — sie machen das verwaltete Modell möglich.

Resource-Requests sind Pflicht. Autopilot lehnt Pods ohne resources.requests ab. Das bricht Workloads, die sie wegzulassen, aber es ist ohnehin die richtige Einschränkung.

Standard: Du besitzt die Node-Schicht

Im Standard-Modus bist du der Node-Betreiber.

Node Pools gehören dir. Du erstellst sie, wählst Machine-Familien (n2, n2d, c3, t2d, m3, a2/a3 GPU und mehr), konfigurierst Boot-Disk-Größe, setzt Node-Taints und -Labels und entscheidest über die Upgrade-Strategie.

Vollständige Workload-Freiheit. Privilegierte Container, eigene DaemonSets für deine Agents, hostPath-Volumes, Host-Networking, Windows-Workloads — alles unterstützt. Das ist der Modus, wenn dein Security-Tooling, dein Netzwerk-Plugin oder dein Compliance-Agent Low-Level-Node-Zugriff benötigt.

Dein Upgrade-Takt. Du konfigurierst die Node-Pool-Upgrade-Strategie (Surge- oder Blue-Green-Upgrades), Wartungsfenster und Patch-Ausschlüsse.

Abrechnung ist vorhersehbar, aber unerbittlich. Du zahlst für die GCE-VMs in deinen Node Pools, unabhängig davon, ob Pods darauf laufen oder nicht. Drei n2-standard-8-Nodes in europe-west3 für 24 Stunden → du zahlst für 72 vCPU-Stunden und 288 GB-Stunden RAM, unabhängig von der tatsächlichen Pod-Last.

Das Abrechnungsmodell ist die eigentliche Entscheidung

Hier machen Teams teure Fehler.

Autopilot-Kosten = Summe der Pod-resources.requests × Einheitstarife (vCPU-Stunde + GB-Stunde + Ephemeral-Storage-GB-Stunde). Die Tarife enthalten einen Managed-Cluster-Aufschlag gegenüber reinen VM-Äquivalenten — etwa 10–20 % pro Einheit. Keine Pods → keine Compute-Kosten.

Ein Detail, das viele überrascht: Die Pod-Abrechnung gilt nur für General-Purpose-Pods. Sobald ein Pod spezifische Hardware wählt — eine GPU, eine TPU oder eine benannte Compute-Engine-Machine-Serie — wechselt Autopilot diesen Workload auf Node-basierte Abrechnung (ganzer Node plus Management-Aufschlag), genau wie Standard. Autopilots „zahle nur, was Pods anfordern“ gilt für General-Purpose-Compute, nicht für Accelerator-Nodes.

Standard-Kosten = Summe der Node-VM-Preise × Laufstunden. Ein Node bei 20 % Auslastung kostet dasselbe wie ein Node bei 95 %.

Der Kipppunkt: Bei etwa 70–80 % konstanter Node-Auslastung unterschreiten die Standard-Gesamtkosten in der Regel die von Autopilot. Unterhalb dieser Schwelle ist Autopilot meistens günstiger.

In der Praxis:

Dev- und Test-Cluster : Autopilot gewinnt fast immer. Variable Last, Pods idle über Nacht, niemand skaliert manuell herunter.
Batch-Workloads mit Spitzen : Autopilot gewinnt — du zahlst für die Spitze, nicht für die Wartezeit.
Produktions-Cluster mit stabiler, hoher Last : Kalkuliere es durch. Wenn deine p50-Node-Auslastung zuverlässig über 75 % liegt, ist Standard wahrscheinlich günstiger.
Keine überspezifizierten Resource-Requests in Autopilot — überhöhte Requests erhöhen direkt die Rechnung.

Was sich geändert hat — und was Autopilot 2026 noch nicht kann

Die Lücke zwischen den Modi ist seit dem Autopilot-Launch 2021 deutlich geschrumpft. Was inzwischen auf Autopilot funktioniert:

GPUs und TPUs — über eine ComputeClass oder das Pod-Spec angefordert; keine Accelerator-Node-Pools zu verwalten
Spot-Pods — unterbrechungstolerante Kapazität pro Pod, kein Spot-Node-Pool
Arm (T2A) — über die Scale-Out-Klasse oder eine Arm-ComputeClass
DaemonSets — unterstützt, solange sie keinen erhöhten Zugriff auf den Node benötigen (die meisten Monitoring- und Logging-Agents erfüllen das)
Confidential GKE Nodes — AMD-SEV-Speicherverschlüsselung ist jetzt eine Autopilot-Option, kein Standard-Alleinstellungsmerkmal mehr
GKE Sandbox (gVisor) — auf Autopilot standardmäßig aktiv, für eine zusätzliche Syscall-Isolationsschicht
GKE Dataplane V2, CMEK, Binary Authorization, Workload Identity Federation — alle verfügbar, mehrere standardmäßig aktiv

Die harten Grenzen, die bleiben — die echten Gründe für Standard:

Kein erhöhter Node-Zugriff — privilegierte Container und alles, was Root auf dem Host braucht, wird abgelehnt; ein Agent, der den Node direkt anfassen muss, läuft nicht
Kein Node-SSH — kein SSH oder Exec in Worker-Nodes; Debug auf Pod-Ebene
Kein eigenes Node-OS — Autopilot nutzt ausschließlich Container-Optimized OS, kein Ubuntu-Image, keine eigenen Startup-Skripte
Keine Windows-Nodes — nur Linux-Workloads
Kein Host-Networking, keine beliebigen hostPath-Volumes — Node-erzwungene Security-Einschränkungen
Keine Cloud-Marketplace-Apps und kein externalIPs-Service-Feld

Zwei Korrekturen, die erwähnenswert sind, weil ältere Vergleiche sie falsch darstellen: DaemonSets und Confidential GKE Nodes funktionieren 2026 beide auf Autopilot. Der Blocker war nie „DaemonSet“ — es ist erhöhter Node-Zugriff.

Gegenüberstellung: Das vollständige Bild

	GKE Autopilot	GKE Standard
Node-Verwaltung	Google	Du
Cluster-Standort	Nur regional	Regional oder zonal
Abrechnung General-Purpose	Pro Pod-Request	Pro Node-VM
Abrechnung spezifische Hardware	Pro Node (+ Aufschlag)	Pro Node-VM
Idle-Node-Kosten	Keine	Voller Node-Preis
Compute-Auswahl	ComputeClasses	Jede GCE-Machine-Serie
Node-OS	Container-Optimized OS	COS / Ubuntu / Windows
Node-SSH	Nein	Ja
Privilegierter / erhöhter Node-Zugriff	Nein	Ja
DaemonSets	Ja (kein erhöhter Zugriff)	Ja (uneingeschränkt)
Windows-Nodes	Nein	Ja
Confidential GKE Nodes	Ja	Ja
GKE Sandbox (gVisor)	Standardmäßig aktiv	Optional
GPU / TPU	Ja (ComputeClass)	Ja (Node Pools)
Spot	Pro Pod	Node Pool
Arm (T2A)	Ja	Ja
Dataplane V2	Standard	Optional
Workload Identity Federation	Vorkonfiguriert	Optional
Node-Auto-Upgrade	Pflicht	Konfigurierbar
Autopilot-Modus-Workloads	Ganzer Cluster	Pro Workload via ComputeClass

Die Grenze verwischt 2026

Zwei Änderungen machen die Wahl weniger binär als früher.

Autopilot-Workloads innerhalb von Standard-Clustern. Du musst nicht mehr einen Modus für den ganzen Cluster wählen. In einem Standard-Cluster kannst du einzelne Workloads im Autopilot-Modus laufen lassen, indem du eine Autopilot-ComputeClass anforderst — GKE provisioniert und verwaltet diese Nodes für dich, während der Rest des Clusters mit deinen eigenen Node Pools unter deiner Kontrolle bleibt. Händefreie Nodes für die Workloads, die sie wollen, volle Kontrolle für die, die sie brauchen.

Die Container-optimierte Compute-Plattform. Auf aktuellen Versionen (GKE 1.32.3-gke.1927002+) laufen General-Purpose-Autopilot-Pods auf Nodes, die zur Laufzeit dynamisch skalieren und aus einem Pool vorbereitgestellter Kapazität schöpfen. Das beseitigt den größten Teil der Cold-Start-Verzögerung, die früher Autopilots Schwachstelle war — neue Pods werden meist eingeplant, ohne auf einen frischen Node zu warten.

Fazit: „Autopilot vs Standard“ wird zunehmend zu „wie viel von diesem Cluster soll verwaltet sein“ — statt zwei getrennten Welten.

Wie man wählt: Drei Fragen

75% Node-Auslastung? → Standard. Sonst → Autopilot." width="799" height="433">

1. Benötigt ein Workload erhöhten Node-Zugriff — privilegierte Container, ein DaemonSet, das den Node anfasst, Node-SSH, ein eigenes oder Ubuntu-Node-OS oder Windows-Nodes?

Wenn ja → Standard , ohne Diskussion. Das sind harte Einschränkungen in Autopilot, keine Einstellungen. (Was nicht mehr auf dieser Liste steht: GPUs, TPUs, Spot, Arm und Confidential GKE Nodes laufen alle auf Autopilot.)

2. Läuft dein Cluster bei konstant hoher Node-Auslastung (über ~75%)?

Wenn ja → Standard durchrechnen. Bei konstant hoher Auslastung nutzt du die VMs, für die du zahlst, vollständig — und der Standard-VM-Preis unterbietet Autopilots Pod-Request-Preis. Nutze den GCP Pricing Calculator mit deinen tatsächlichen Resource-Requests.

3. Soll das Team, das diesen Cluster betreibt, Infrastruktur verwalten?

Wenn nein → Autopilot. Dev-Umgebungen, interne Developer-Plattformen, SaaS-Produktcluster, Batch-Verarbeitung — Autopilot beseitigt den Node-Pool-Verwaltungsaufwand, damit das Team sich auf die Applikationsschicht konzentriert.

Im Zweifel: Autopilot als Standard für neue Cluster , es sei denn, eine der harten Grenzen greift. Für die Workloads, die es benötigen, kann immer ein paralleler Standard-Cluster betrieben werden.

Ein Muster, das in großem Maßstab funktioniert

Beim Aufbau der ersten Produktions-GCP-Plattform bei der Deutschen Telekom hat sich mit der Zeit diese Aufteilung ergeben:

Standard für die Produktions-Datenebene : konstant hohe Auslastung, Security-DaemonSets für Compliance-Agents, vollständige Dataplane-V2-Konfiguration, Spot-Node-Pools für Batch-Verarbeitung.
Autopilot für Dev- und Pre-Prod-Umgebungen : automatisches Scale-to-Zero an Wochenenden und nachts, keine Idle-Node-Kosten, Entwickler erhalten einen Cluster, ohne ihn besitzen zu müssen.

Beide Cluster-Typen treten demselben GKE Enterprise Fleet bei, teilen Policy-Controller-Regeln und werden aus demselben Cloud-Monitoring-Workspace überwacht. Der Modus ist ein Implementierungsdetail; die Governance-Schicht liegt über beiden.

Die Security-Grundlage ändert sich nicht

Unabhängig vom gewählten Modus sind diese Maßnahmen identisch und nicht verhandelbar:

Workload Identity Federation — keine Service-Account-Schlüsseldateien auf Nodes oder in Pods. WIF stellt kurzlebige OIDC-Token aus. Den vollständigen Ansatz zur Eliminierung von SA-Schlüsseln findest du in Service-Account-Schlüssel abschaffen: Workload Identity Federation auf GKE.

Binary Authorization — erzwinge, dass nur signierte, geprüfte Images in deinem Cluster laufen.

GKE Dataplane V2 — eBPF-basierte Network-Policy-Durchsetzung (Cilium). Standard bei Autopilot; opt-in bei Standard.

Least-Privilege RBAC — ClusterAdmin für Menschen ist fast nie korrekt. Binde Rollen an Service Accounts, nicht direkt an Google-Identitäten.

Node-Auto-Upgrade — konfiguriere bei Standard einen Release-Channel (Regular oder Stable) und aktiviere Auto-Upgrade. Rückstand bei Node-Versionen ist die häufigste Ursache vermeidbarer Security-Exposition in produktiven GKE-Clustern. Bei Autopilot übernimmt Google das.

Mehr zu Isolations-Trade-offs beim Betrieb nicht vertrauenswürdiger Workloads innerhalb von GKE findest du in MicroVMs 2026: Firecracker vs gVisor für sichere Workloads.

Ursprünglich veröffentlicht auf alekseialeinikov.com

GKE Autopilot vs Standard in 2026: The Real Trade-offs

Aleksei Aleinikov — Wed, 15 Jul 2026 12:00:00 +0000

Choosing between GKE Autopilot and Standard looks like a checkbox decision at cluster creation time. It is actually a commitment that determines your billing model, your operational ceiling, and what workloads you can run — for the lifetime of the cluster. You cannot switch modes after creation.

Most comparisons list features. This one starts where the feature list hides the real answer: who owns the worker node layer.

The One Thing Both Modes Have in Common

Both modes run the exact same Google-managed control plane. etcd, the API server, the scheduler, the controller manager — Google manages, upgrades, and HA-replicates all of it. You never provision a control plane node, because there are none to provision. It is a fully managed service behind the container.googleapis.com endpoint.

This is not a differentiator. Stop treating it as one. The actual split is entirely below the control plane.

Autopilot: The Node Layer Disappears

In Autopilot mode, Google abstracts away everything below the pod level.

Node provisioning is automatic. You never create or delete a node pool. When you deploy a pod with a valid resource request, Google provisions a node that fits it. When the pod leaves, the node scales down. The node is an implementation detail you do not manage.

You request capacity, not machines. By default (GKE 1.32.3-gke.1927002 and later) pods run on the container-optimized compute platform — nodes that dynamically resize while running and scale from a fraction of a vCPU, so new pods rarely wait for a node to boot. When a workload needs specific hardware, you request a ComputeClass instead of managing a node pool:

Balanced / Scale-Out — general-purpose; Scale-Out selects Arm (T2A) for stateless density
Performance — compute-optimised machine series
Accelerator — GPUs and TPUs, requested in the ComputeClass or the pod spec
autopilot-spot — interruption-tolerant Spot pods

GKE provisions and sizes the matching nodes automatically.

Security posture is enforced. Pods run as non-root by default, hostPath volumes and host networking are blocked, and Google maintains the node OS. These constraints are not configuration options — they are what makes the managed model work.

Resource requests are mandatory. Autopilot rejects pods without resources.requests. This will break workloads that lazily omit them, but it is the right constraint to enforce anyway.

Standard: You Own the Node Layer

In Standard mode, you are the node operator.

Node pools are yours. You create them, choose machine families (n2, n2d, c3, t2d, m3, a2/a3 GPU, and more), configure boot disk size, set node taints and labels, and decide upgrade strategy.

Full workload freedom. Privileged containers, custom DaemonSets for your own agents, hostPath volumes, host networking, Windows workloads — all supported. This is the mode when your security tooling, network plugin, or compliance agent needs low-level node access.

Your upgrade cadence. You configure node pool upgrade strategy (surge or blue-green), maintenance windows, and patch exclusions. You choose the release channel.

Billing is predictable but blunt. You pay for the GCE VMs in your node pools whether pods are running on them or not. Three n2-standard-8 nodes in europe-west3 running 24 h → you pay for 72 vCPU-hours and 288 GB-hours of RAM, regardless of actual pod load.

The Billing Model Is the Real Decision

This is where teams make expensive mistakes.

Autopilot cost = sum of pod resources.requests × per-unit rates (vCPU-hour + GB-hour + ephemeral storage GB-hour). The rates include a managed-cluster premium over raw VM equivalent — roughly 10–20% per unit. No pods → no compute cost.

One caveat that surprises people: per-pod billing only applies to general-purpose pods. The moment a pod selects specific hardware — a GPU, a TPU, or a named Compute Engine machine series — Autopilot switches that workload to per-node billing (the whole node plus a management premium), exactly like Standard. Autopilot’s “pay only for what pods request” advantage is about general-purpose compute, not accelerator nodes.

Standard cost = sum of node VM prices × hours running. A node at 20% utilisation costs the same as a node at 95%.

The crossover: at roughly 70–80% consistent node utilisation , Standard’s total cost typically drops below Autopilot’s. Below that threshold, Autopilot is usually cheaper because you are not paying for idle capacity.

In practice:

Dev and test clusters : Autopilot almost always wins. Variable load, pods idle overnight, no one scales down properly.
Batch workloads with spikes : Autopilot wins — you pay for the spike, not for waiting.
Production clusters with steady, high load : model it. If your p50 node utilisation is reliably above 75%, Standard is likely cheaper.
Avoid over-specifying resource requests in Autopilot — over-requested pods inflate your bill directly. Get sizing right before migrating.

What Changed — and What Autopilot Still Cannot Do in 2026

The gap between the modes has narrowed sharply since Autopilot launched in 2021. What now works on Autopilot:

GPUs and TPUs — requested through a ComputeClass or the pod spec; no accelerator node pools to manage
Spot pods — per-pod interruption-tolerant capacity, no Spot node pool
Arm (T2A) — via the Scale-Out class or an Arm ComputeClass
DaemonSets — supported, as long as they do not need elevated access on the node (most monitoring and logging agents qualify)
Confidential GKE Nodes — AMD SEV memory encryption is now an Autopilot option, not a Standard-only feature
GKE Sandbox (gVisor) — enabled by default on Autopilot for an extra syscall-isolation layer
GKE Dataplane V2, CMEK, Binary Authorization, Workload Identity Federation — all available, several on by default

The hard limits that remain — the real reasons to reach for Standard:

No elevated node access — privileged containers and anything that needs root on the host are rejected; an agent that must touch the node directly will not run
No node SSH — you cannot SSH or exec into worker nodes; you debug at the pod level
No custom node OS — Autopilot is Container-Optimized OS only, with no Ubuntu image and no custom startup scripts
No Windows nodes — Linux workloads only
No host networking or arbitrary hostPath volumes — node-enforced security restrictions
No Cloud Marketplace apps and no externalIPs Service field

Two corrections worth flagging, because older comparisons still get them wrong: DaemonSets and Confidential GKE Nodes both work on Autopilot in 2026. The blocker was never “DaemonSets” — it is elevated node access.

Side-by-Side: The Full Picture

	GKE Autopilot	GKE Standard
Node management	Google	You
Cluster location	Regional only	Regional or zonal
General-purpose billing	Per pod request	Per node VM
Specific-hardware billing	Per node (+ premium)	Per node VM
Idle node cost	None	Full node price
Compute selection	ComputeClasses	Any GCE machine series
Node OS	Container-Optimized OS	COS / Ubuntu / Windows
Node SSH	No	Yes
Privileged / elevated node access	No	Yes
DaemonSets	Yes (no elevated access)	Yes (unrestricted)
Windows nodes	No	Yes
Confidential GKE Nodes	Yes	Yes
GKE Sandbox (gVisor)	On by default	Optional
GPU / TPU	Yes (ComputeClass)	Yes (node pools)
Spot	Per pod	Node pool
Arm (T2A)	Yes	Yes
Dataplane V2	Default	Optional
Workload Identity Federation	Pre-configured	Optional
Node auto-upgrade	Mandatory	Configurable
Autopilot-mode workloads	Whole cluster	Per-workload via ComputeClass

The Line Is Blurring in 2026

Two changes make this less of a binary choice than it used to be.

Autopilot workloads inside Standard clusters. You no longer have to pick one mode for the whole cluster. In a Standard cluster you can mark specific workloads to run in Autopilot mode by requesting an Autopilot ComputeClass — GKE provisions and manages those nodes for you, while the rest of the cluster stays under your control with your own node pools. Hands-off nodes for the workloads that want them, full control for the ones that need it.

The container-optimized compute platform. On recent versions (GKE 1.32.3-gke.1927002+), general-purpose Autopilot pods run on nodes that resize dynamically while running and draw from a pool of pre-provisioned capacity. This removes most of the cold-start delay that used to be Autopilot’s weak point — new pods usually schedule without waiting for a fresh node to boot.

The takeaway: “Autopilot vs Standard” is increasingly “how much of this cluster do I want managed”, not two separate worlds.

How to Choose: Three Questions

75% node utilisation? → Standard. Otherwise → Autopilot." width="799" height="433">

1. Does any workload need elevated node access — privileged containers, a custom DaemonSet that touches the node, node SSH, a custom or Ubuntu node OS, or Windows nodes?

If yes → Standard , full stop. These are hard constraints in Autopilot, not settings you can unlock. (Note what is not on this list anymore: GPUs, TPUs, Spot, Arm, and Confidential GKE Nodes all work on Autopilot.)

2. Is your cluster running at consistently high node utilisation (above ~75%)?

If yes → run the numbers for Standard. At high, consistent utilisation you are paying for capacity you are actually using, and Standard’s per-VM price undercuts Autopilot’s per-pod-request price. Use the GCP Pricing Calculator with your actual resource requests.

3. Should the team running this cluster manage infrastructure?

If no → Autopilot. Dev environments, internal developer platforms, SaaS product clusters, batch processing — Autopilot removes node-pool-management toil so the team focuses on the application layer.

When still unsure: default to Autopilot for new clusters unless you hit one of the hard limits above. You can always run a parallel Standard cluster for workloads that need it.

A Pattern That Works at Scale

Building the first production GCP platform at Deutsche Telekom, the split that emerged over time was:

Standard for the production data plane : consistent high utilisation, security DaemonSets for compliance agents, full Dataplane V2 configuration, spot-node pools for batch processing.
Autopilot for dev and pre-prod environments : automatic scale-to-zero on weekends and overnight, no idle node cost, developers get a cluster without owning it.

Both clusters join the same GKE Enterprise fleet, share Policy Controller rules, and report to the same Cloud Monitoring workspace. The mode is an implementation detail; the governance layer sits above both.

The Security Baseline Does Not Change

Regardless of mode, these practices are identical and non-negotiable:

Workload Identity Federation — no service account key files on nodes or in pods. WIF issues short-lived OIDC tokens. Dropping SA keys entirely removes one of the most common GCP credential-exfiltration vectors — see the full walkthrough in Kill Service Account Keys: Workload Identity Federation on GKE.

Binary Authorization — enforce that only signed, approved images run in your cluster.

GKE Dataplane V2 — eBPF-based network policy enforcement (Cilium). Default on Autopilot; opt-in on Standard.

Least-privilege RBAC — ClusterAdmin for humans is almost never correct. Bind roles to service accounts, not to Google identities directly.

Node auto-upgrade — on Standard, configure a release channel (Regular or Stable) and enable auto-upgrade. Falling behind on node versions is the single most common cause of preventable security exposure in production GKE clusters. On Autopilot, Google handles this for you.

The mode you pick does not change the security work. Do it regardless.

For more on isolation trade-offs when running untrusted workloads inside GKE, see MicroVMs in 2026: Firecracker vs gVisor for Secure Workloads.

Originally published at alekseialeinikov.com

AI Coding Agents in 2026: Claude Code vs Codex vs opencode

Aleksei Aleinikov — Tue, 14 Jul 2026 12:00:00 +0000

Two years ago, AI in the editor meant autocomplete: it guessed the next line and you pressed Tab. In 2026 it means something categorically different — an agent that reads your repo, edits files across it, runs your tests, reads the errors, and tries again, all from a single instruction. The tool stopped suggesting and started doing.

Three names dominate that shift: Claude Code , Codex , and opencode. They look similar in a demo and are marketed as rivals, but they make genuinely different bets on lock-in, control, and openness. This is a vendor-neutral guide to what they actually are, how the thing under all of them works, and how to choose — and run — one without handing over the keys to your codebase.

First, What a Coding Agent Actually Is

The word “agent” gets thrown around loosely, so pin it down. A coding agent is not one clever prompt — it’s a loop.

You give a goal — “add JWT auth to the API.” Then:

The model plans the next concrete step.
It acts — calls tools to read files, edit code, run a command, grep the repo.
It observes the result — test output, a stack trace, the new file contents.
It loops — feeds that back in and plans again, until the task is actually done.
It stops and shows you a diff to review and approve.

That loop is the whole idea, and it’s why an agent is powerful and risky at the same time: between your prompt and the result, it takes actions on its own. Autocomplete could only ever suggest; an agent edits your files and runs your shell. Every tool below is a different wrapper around this same loop.

The Three That Matter

Claude Code — Anthropic’s agent. It began as a terminal tool and now runs across the terminal, IDE, desktop app, and the browser — including managed cloud sessions that chew through long tasks in parallel while your machine is off. It’s tied to Claude models, closed-source, MCP-native, and asks permission before edits and commands. If you already trust Claude for code, it’s the most polished way to let it act.

Codex — OpenAI’s coding agent, and the one that pushes the loop the furthest. It runs in two modes: a cloud agent that grinds through long tasks in an isolated, managed sandbox — so you can fire off several jobs at once and walk away — and a local CLI for hands-on work at the keyboard. It’s tied to OpenAI’s frontier models, which are still some of the strongest at real code, and its cloud agent is a mature, isolated place to hand off long work. The CLI is open; the models and the managed service are proprietary. The trade is clear: you accept the OpenAI ecosystem, and in return you get one of the strongest model-plus-cloud combinations on the market.

opencode — the open-source outlier. A terminal agent that is model-agnostic : you point it at whichever provider you want — Anthropic, OpenAI, Google, or a local model — and the agent itself is open-source, so you can read it, extend it, and self-host it. Its bet is no lock-in and full auditability.

Where Each One Sits

Strip away the branding and the three separate on two axes: how open they are (closed vs open-source) and how locked to one model vendor they are. Notice what is not an axis anymore: where it runs. Both Claude Code and Codex now run locally and offer a managed cloud, so that stopped being the dividing line.

Here is the same decision as a table:

	Claude Code	Codex	opencode
Vendor	Anthropic	OpenAI	Open-source (community)
Models	Claude only	OpenAI only	Any — bring your own
Where it runs	Local + managed cloud	Local CLI + managed cloud	Local / self-hosted
Openness	Closed	CLI open, service/model closed	Fully open-source
MCP support	Native	Yes	Yes
Auditability	Trust the vendor	Trust the vendor	Read the source
Best for	Deep Claude users, polished all-surface	Delegating & parallelizing long tasks, hands-off cloud runs	Avoiding lock-in, local-only, self-hosting

The pattern is clear: the two proprietary agents cluster together — polished, model-locked, vendor-trusted — and opencode is the deliberate counterweight for teams that refuse model lock-in or need to audit what the agent does.

How to Actually Choose

Ignore the demos; they all look magical for ten minutes. Choose on three real constraints:

Model lock-in. Do you want to be tied to one model family? Claude Code binds you to Claude, Codex to OpenAI. opencode lets you swap models — including running a local one for sensitive code — without changing your workflow.
Where it runs. This used to split them, but no longer: both Claude Code and Codex run locally and offer a managed cloud that chews through long, parallel tasks while you do something else. opencode is the local / self-hosted one — no vendor cloud at all, which is the whole point if you need everything on your own infrastructure. So don’t choose on “local vs cloud”; choose on whose cloud you’re willing to send code to, if any.
Openness and auditability. In a regulated or security-sensitive shop, “we can read exactly what the agent does” is not a nice-to-have. That’s opencode’s home turf; the proprietary tools ask you to trust the vendor instead.

In practice the switching cost is low — the loop is the same everywhere — so trying two is cheap and often clarifying. Pick the default that matches your constraints, not the one with the best launch video.

Letting It Act Without Letting It Loose

Here’s the part the demos skip. A coding agent is, mechanically, a program that edits your source and runs shell commands on your behalf. That is enormous leverage and a genuine attack surface. The failure mode isn’t the model being dumb — it’s the model being capable and unsupervised.

Treat every agent like a new junior developer who somehow has root. Four guardrails make that safe:

Permission prompts. Approve edits and shell commands before they run, not after. All three support this — leave it on, especially for anything that touches the network or the filesystem outside the repo.
Sandboxed execution. Run the agent in a container or a microVM, never directly on your host or anything near production. If it runs rm -rf or a poisoned dependency’s postinstall, the blast radius should be a throwaway sandbox. For the isolation trade-offs, see MicroVMs in 2026: Firecracker vs gVisor for Secure Workloads.
Scoped tool access. An agent’s power comes from the tools it can call. Allow-list them — and if it reaches external tools over MCP, control which servers and which tools it can touch, deny-by-default. This is exactly the per-tool permission problem covered in User-Level Permission Controls for MCP Tool Access.
Human reviews the diff. The agent proposes; you decide. Read the change before it commits. The moment you let an agent merge unattended, you’ve replaced code review with faith.

None of this is exotic — it’s least-privilege, applied to a very capable new kind of process. The agent that can rewrite your codebase in a minute can also break it in a minute; the guardrails are what turn that speed into leverage instead of a liability.

The Field Rule

The three agents are more alike than their marketing suggests: the same plan-act-observe loop, wrapped differently — and the two proprietary ones, Claude Code and Codex, are near-twins that both now run locally and in a managed cloud. So choose on what actually differs — openness and model lock-in — and run whichever you pick like a powerful junior: sandboxed, permission-gated, tool-scoped, and never merging without a human on the button. Claude Code if you live in Claude and want the most polished experience; Codex if you want OpenAI’s frontier models with a mature cloud agent to hand long, parallel work to ; opencode if you refuse lock-in and want open source you control. If you just want a strong set-and-forget default and don’t mind the OpenAI ecosystem, Codex is the easiest one to bet on. Get the guardrails right first, and any of the three becomes leverage instead of a gamble.

Originally published at alekseialeinikov.com

KI-Coding-Agents 2026: Claude Code vs Codex vs opencode

Aleksei Aleinikov — Tue, 14 Jul 2026 12:00:00 +0000

Vor zwei Jahren bedeutete KI im Editor Autocomplete: Sie erriet die nächste Zeile, und du drücktest Tab. 2026 bedeutet sie etwas kategorisch anderes — einen Agent , der dein Repo liest, Dateien darüber hinweg ändert, deine Tests ausführt, die Fehler liest und es erneut versucht, alles aus einer einzigen Anweisung. Das Werkzeug hörte auf vorzuschlagen und fing an zu handeln.

Drei Namen dominieren diesen Wandel: Claude Code , Codex und opencode. In einer Demo sehen sie ähnlich aus und werden als Rivalen vermarktet, aber sie setzen auf wirklich unterschiedliche Wetten bei Lock-in, Kontrolle und Offenheit. Das hier ist ein anbieterneutraler Leitfaden dazu, was sie wirklich sind, wie das Ding unter allen funktioniert, und wie man eines wählt — und betreibt — ohne die Schlüssel zu deinem Codebestand abzugeben.

Zuerst: Was ein Coding-Agent wirklich ist

Das Wort „Agent“ wird locker verwendet, also fixieren wir es. Ein Coding-Agent ist nicht ein cleverer Prompt — er ist eine Schleife.

Du gibst ein Ziel vor — „füge JWT-Auth zur API hinzu.“ Dann:

Das Modell plant den nächsten konkreten Schritt.
Es handelt — ruft Tools auf, um Dateien zu lesen, Code zu ändern, einen Befehl auszuführen, das Repo zu durchsuchen.
Es beobachtet das Ergebnis — Testausgabe, einen Stacktrace, den neuen Dateiinhalt.
Es wiederholt — führt das zurück und plant erneut, bis die Aufgabe wirklich erledigt ist.
Es stoppt und zeigt dir einen Diff zum Prüfen und Freigeben.

Diese Schleife ist die ganze Idee, und deshalb ist ein Agent zugleich mächtig und riskant: zwischen deinem Prompt und dem Ergebnis handelt er eigenständig. Autocomplete konnte nur vorschlagen; ein Agent ändert deine Dateien und führt deine Shell aus. Jedes Werkzeug unten ist eine andere Hülle um genau diese Schleife.

Die drei, die zählen

Claude Code — Anthropics Agent. Er begann als Terminal-Tool und läuft heute über Terminal, IDE, Desktop-App und den Browser — inklusive verwalteter Cloud-Sitzungen, die lange Aufgaben parallel abarbeiten, auch wenn deine Maschine aus ist. Er ist an Claude-Modelle gebunden, Closed Source, MCP-nativ und fragt vor Änderungen und Befehlen um Erlaubnis. Wenn du Claude für Code bereits vertraust, ist er der ausgereifteste Weg, es handeln zu lassen.

Codex — OpenAIs Coding-Agent, und der, der die Schleife am weitesten treibt. Er läuft in zwei Modi: einem Cloud-Agent , der lange Aufgaben in einer isolierten, verwalteten Sandbox durcharbeitet — du kannst also mehrere Jobs auf einmal anstößen und weggehen — und einer lokalen CLI fürs Arbeiten direkt an der Tastatur. Er ist an OpenAIs Frontier-Modelle gebunden, die noch immer zu den stärksten bei echtem Code zählen, und sein Cloud-Agent ist ein ausgereifter, isolierter Ort, um lange Arbeit abzugeben. Die CLI ist offen; die Modelle und der verwaltete Dienst sind proprietär. Der Handel ist klar: du akzeptierst das OpenAI-Ökosystem und bekommst dafür eine der stärksten Modell-plus-Cloud-Kombinationen am Markt.

opencode — der Open-Source-Ausreißer. Ein Terminal-Agent, der modellagnostisch ist: Du richtest ihn auf den Anbieter, den du willst — Anthropic, OpenAI, Google oder ein lokales Modell — und der Agent selbst ist Open Source, sodass du ihn lesen, erweitern und selbst hosten kannst. Seine Wette lautet: kein Lock-in und volle Auditierbarkeit.

Wo jeder sitzt

Streift man Branding ab, trennen sich die drei auf zwei Achsen: wie offen sie sind (closed vs Open Source) und wie stark an einen Modell-Anbieter gebunden. Beachte, was keine Achse mehr ist: wo es läuft. Sowohl Claude Code als auch Codex laufen inzwischen lokal und bieten eine verwaltete Cloud — das hörte auf, die Trennlinie zu sein.

Dieselbe Entscheidung als Tabelle:

	Claude Code	Codex	opencode
Anbieter	Anthropic	OpenAI	Open Source (Community)
Modelle	Nur Claude	Nur OpenAI	Beliebig — bring dein eigenes
Wo es läuft	Lokal + verwaltete Cloud	Lokale CLI + verwaltete Cloud	Lokal / selbst gehostet
Offenheit	Closed	CLI offen, Dienst/Modell closed	Vollständig Open Source
MCP-Support	Nativ	Ja	Ja
Auditierbarkeit	Anbieter vertrauen	Anbieter vertrauen	Quellcode lesen
Am besten für	Tiefe Claude-Nutzer, ausgereift auf allen Oberflächen	Lange Aufgaben delegieren & parallelisieren, händefreie Cloud-Läufe	Lock-in vermeiden, lokal, selbst hosten

Das Muster ist klar: Die beiden proprietären Agents clustern zusammen — ausgereift, modellgebunden, anbietervertrauensbasiert — und opencode ist das bewusste Gegengewicht für Teams, die Modell-Lock-in ablehnen oder auditieren müssen, was der Agent tut.

Wie man wirklich wählt

Ignoriere die Demos; alle sehen zehn Minuten lang magisch aus. Wähle nach drei echten Einschränkungen:

Modell-Lock-in. Willst du an eine Modellfamilie gebunden sein? Claude Code bindet dich an Claude, Codex an OpenAI. opencode lässt dich Modelle tauschen — inklusive eines lokalen Modells für sensiblen Code — ohne deinen Workflow zu ändern.
Wo es läuft. Das trennte sie früher, aber nicht mehr: Sowohl Claude Code als auch Codex laufen lokal und bieten eine verwaltete Cloud, die lange, parallele Aufgaben abarbeitet, während du etwas anderes tust. opencode ist das lokale / selbst gehostete — gar keine Anbieter-Cloud, was genau der Punkt ist, wenn du alles auf deiner eigenen Infrastruktur brauchst. Wähle also nicht nach „lokal vs Cloud“, sondern danach, wessen Cloud du überhaupt Code anvertrauen willst.
Offenheit und Auditierbarkeit. In einem regulierten oder sicherheitskritischen Umfeld ist „wir können genau lesen, was der Agent tut“ kein Nice-to-have. Das ist opencodes Heimspiel; die proprietären Tools verlangen stattdessen Vertrauen in den Anbieter.

In der Praxis sind die Wechselkosten niedrig — die Schleife ist überall dieselbe — also ist es günstig und oft erhellend, zwei auszuprobieren. Wähle die Voreinstellung, die zu deinen Einschränkungen passt, nicht die mit dem besten Launch-Video.

Handeln lassen, ohne von der Leine zu lassen

Hier der Teil, den die Demos überspringen. Ein Coding-Agent ist mechanisch ein Programm, das deinen Quellcode ändert und Shell-Befehle in deinem Namen ausführt. Das ist enorme Hebelwirkung und eine echte Angriffsfläche. Der Fehlerfall ist nicht ein dummes Modell — es ist ein fähiges und unbeaufsichtigtes.

Behandle jeden Agent wie einen neuen Junior-Entwickler, der irgendwie Root hat. Vier Leitplanken machen das sicher:

Berechtigungsabfragen. Genehmige Änderungen und Shell-Befehle bevor sie laufen, nicht danach. Alle drei unterstützen das — lass es an, besonders für alles, was das Netzwerk oder das Dateisystem außerhalb des Repos berührt.
Sandbox-Ausführung. Betreibe den Agent in einem Container oder einer microVM, nie direkt auf deinem Host oder nahe der Produktion. Führt er rm -rf oder das Postinstall einer vergifteten Abhängigkeit aus, sollte der Schadensradius eine Wegwerf-Sandbox sein. Zu den Isolations-Trade-offs siehe MicroVMs 2026: Firecracker vs gVisor für sichere Workloads.
Eingegrenzter Tool-Zugriff. Die Macht eines Agents kommt aus den Tools, die er aufrufen kann. Erlaube sie per Allow-List — und erreicht er externe Tools über MCP, kontrolliere welche Server und welche Tools er berühren darf, deny-by-default. Genau dieses Pro-Tool-Berechtigungsproblem behandelt Benutzerbezogene Zugriffskontrolle für MCP-Tools.
Ein Mensch prüft den Diff. Der Agent schlägt vor; du entscheidest. Lies die Änderung, bevor sie committet. In dem Moment, in dem du einen Agent unbeaufsichtigt mergen lässt, hast du Code-Review durch Glauben ersetzt.

Nichts davon ist exotisch — es ist Least-Privilege, angewandt auf eine sehr fähige neue Art von Prozess. Der Agent, der deinen Codebestand in einer Minute umschreiben kann, kann ihn auch in einer Minute kaputt machen; die Leitplanken verwandeln dieses Tempo in Hebelwirkung statt in ein Risiko.

Die Feldregel

Die drei Agents sind sich ähnlicher, als ihr Marketing suggeriert: dieselbe Plan-Handeln-Beobachten-Schleife, anders verpackt — und die beiden proprietären, Claude Code und Codex, sind Beinahe-Zwillinge, die beide inzwischen lokal und in einer verwalteten Cloud laufen. Wähle also nach dem, was wirklich unterschiedlich ist — Offenheit und Modell-Lock-in — und betreibe das Gewählte wie einen mächtigen Junior: sandboxed, berechtigungsgesteuert, tool-eingegrenzt, und niemals mergend ohne einen Menschen am Knopf. Claude Code, wenn du in Claude lebst und das ausgereifteste Erlebnis willst; Codex, wenn du OpenAIs Frontier-Modelle mit einem ausgereiften Cloud-Agent willst, an den du lange, parallele Arbeit übergibst ; opencode, wenn du Lock-in ablehnst und Open Source willst, den du kontrollierst. Willst du einfach einen starken Set-and-forget-Standard und störst dich nicht am OpenAI-Ökosystem, ist Codex die einfachste Wette. Bring zuerst die Leitplanken in Ordnung, und jeder der drei wird zur Hebelwirkung statt zum Glücksspiel.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Cloud Bigtable 2026: Wann Wide-Column BigQuery, Spanner und Cassandra schlägt

Aleksei Aleinikov — Mon, 13 Jul 2026 15:00:00 +0000

Bigtable ist die am meisten missverstandene Datenbank in Google Cloud. Teams greifen zu BigQuery, wenn sie Bigtable brauchen, schrauben ein Analytics-Warehouse an einen Workload, der nur schnelle Key-Lookups will, und wundern sich dann, warum Rechnung und Latenz beide in die falsche Richtung liefen. Andere hören „NoSQL in Google-Größe“ und werfen Bigtable auf ein Problem, das eigentlich relationale Transaktionen brauchte.

Die Verwirrung ist verständlich — die Namen verschwimmen, und auf jedem steht „Petabytes“. Aber diese Engines lösen wirklich unterschiedliche Probleme, und die falsche zu wählen ist auf eine Weise teuer, die man jahrelang spürt. Das hier ist ein praktischer Leitfaden dazu, was Cloud Bigtable wirklich ist, wann es BigQuery, Spanner, Cassandra und DynamoDB schlägt, und die eine Design-Entscheidung, die bestimmt, ob es fliegt oder abstürzt.

Was Bigtable wirklich ist

Bigtable ist ein Wide-Column-NoSQL-Store : eine einzige, riesige Tabelle, in der jede Zeile über einen Row Key adressiert wird und Spalten spärlich sind und in Column Families gruppiert werden. Es stammt direkt vom Bigtable-Paper von 2006 ab, das HBase, Cassandra und einen Großteil der NoSQL-Ära inspirierte — und dieselben Kernideen erklären sein Verhalten bis heute.

Unter der Haube zählen drei Dinge:

Zeilen werden nach Row Key sortiert gespeichert. Die Tabelle ist ein langer, lexikografisch geordneter Keyspace — deshalb sind Range-Scans günstig und deshalb zählt das Key-Design so sehr (dazu unten mehr).
Die Tabelle wird in Tablets aufgeteilt. Zusammenhängende Zeilenbereiche bilden Tablets, und jedes Tablet wird von genau einem Node bedient. Füge Nodes hinzu, und Bigtable verteilt Tablets automatisch neu.
Speicher ist von Compute getrennt. Daten liegen als immutable SSTables auf Colossus, Googles verteiltem Dateisystem. Nodes bedienen Requests; sie besitzen die Daten nicht. Diese Trennung ist der Grund, warum du Durchsatz durch Hinzufügen von Nodes skalierst, ohne je ein Byte zu verschieben — und warum Bigtable von Gigabytes bis Petabytes einstellige Millisekunden-Latenz hält.

Das ist das ganze mentale Modell: eine sortierte Wide-Column-Tabelle, in Tablets zerlegt, bedient von einer dünnen Compute-Schicht über dauerhaftem Speicher. Alles, worin Bigtable gut und schlecht ist, folgt daraus.

Wo es passt: Bigtable vs BigQuery vs Spanner vs Cassandra

Am schnellsten wählst du richtig, indem du jede Engine danach einordnest, wie du auf die Daten zugreifst, nicht nach dem Marketing.

Cloud Bigtable — Punkt-/Key-Zugriff, Wide-Column-NoSQL. Durchsatzstarke Reads und Writes per Row Key, einstellige ms-Latenz, Single-Row-Atomarität.
Cloud Spanner — Punkt-/Key-Zugriff, aber relational mit SQL und starken Multi-Row-Transaktionen. Diese Korrektheit kostet pro Operation mehr.
BigQuery — die entgegengesetzte Ecke: analytische Full-Table-Scans mit SQL. Hervorragend für Aggregationen über Milliarden Zeilen, falsch fürs schnelle Holen einer einzelnen Zeile.
Cassandra / DynamoDB — dieselbe Wide-Column-Familie wie Bigtable, die man auf AWS/Azure oder in einem bestimmten Hybrid-Setup wählt.

Dieselbe Entscheidung als Tabelle:

	Cloud Bigtable	BigQuery	Cloud Spanner	Cassandra / DynamoDB
Datenmodell	Wide-Column-NoSQL (spärlich)	Spaltenbasiertes Warehouse	Relational (SQL)	Wide-Column-NoSQL
Am besten für	Durchsatzstarke Key-Reads/Writes	Ad-hoc-Analytics über riesige Scans	Globale, stark-konsistente Transaktionen	Key-Reads/Writes außerhalb GCP
Query	Key- + Range-Scans, keine Joins	Volles SQL, Joins, Aggregate	Volles SQL + Transaktionen	Key/CQL-API, keine Joins
Transaktionen	Nur Single-Row-atomar	Keine (Analytics)	Multi-Row, externe Konsistenz	Single-Row / leichtgewichtig
Latenz	Einstellige ms in jedem Maßstab	Sekunden (Scan-basiert)	Niedrige ms (höher als Bigtable)	Einstellige ms
Skalierung	Petabytes, linear mit Nodes	Petabytes, serverless	Petabytes, global	Petabytes
Wählen bei	Zeitreihen, IoT, Adtech, ML-Features	Du brauchst SQL-Analytics, keine Punkt-Reads	Du brauchst relational + starke Txn	Du bist auf AWS/Azure oder hybrid

Das Muster ist klar: Bigtable gehört der Punktzugriff im großen Maßstab. Sobald du SQL-Analytics brauchst, ist das BigQuery; sobald du relationale Transaktionen brauchst, ist das Spanner. Wenn du für die Analytics-Seite noch zwischen den beiden Warehouses wählst, sind die Trade-offs hier aufgeschlüsselt: BigQuery vs Snowflake 2026: Ein ehrlicher Vergleich.

Wann Bigtable die richtige Wahl ist

Bigtable glänzt, wenn ein Workload ein bekanntes Key-Zugriffsmuster und eine sehr hohe Lese-/Schreibrate hat. Die klassischen Fälle:

Zeitreihen und Monitoring — Metriken, Events und Sensordaten, kontinuierlich geschrieben und nach Entität + Zeitbereich zurückgelesen.
IoT — Millionen Geräte, die je Daten anhängen; Bigtable schluckt die Schreib-Feuerwehr ohne Latenzeinbruch.
Adtech und Personalisierung — Nutzerprofile und Echtzeit-Bidding-State, in Millisekunden abgerufen, milliardenfach am Tag.
Finanz-/Betriebsdaten — hochvolumige transaktionale Datensätze (keine Multi-Row-Transaktionen) wie Tick-Daten oder Ledger.
ML-Feature-Stores — Feature-Lookups mit niedriger Latenz zur Serving-Zeit, in einem Maßstab, der eine relationale Datenbank ins Schwitzen brächte.

Der rote Faden: Du kennst den Key, brauchst die Antwort schnell, und es gibt viel Traffic. Ist das dein Workload und brauchst du keine Joins oder Multi-Row-Transaktionen, ist Bigtable schwer zu schlagen.

Der Row Key ist das ganze Spiel

Alles Gute an Bigtable hängt an einer Entscheidung: dem Row Key. Weil Zeilen sortiert gespeichert und nach zusammenhängenden Bereichen in Tablets aufgeteilt werden, bestimmt der Key, welcher Node jeden Write bearbeitet. Machst du ihn falsch, hebelst du die gesamte Architektur aus.

Die Falle sind sequenzielle Keys — ein roher Zeitstempel, ein hochzählender Counter, alles Monotone. Jeder neue Write sortiert sich ans Ende des Keyspace, also landet jeder Write im selben Tablet, also nimmt ein Node 100 % der Schreiblast, während der Rest untätig bleibt. Du hast ein Hundert-Node-Cluster gekauft und nutzt eines. Das ist der Bigtable-Performance-Bug Nummer eins — und komplett selbstverschuldet.

Die Lösung ist ein hochkardinales Präfix , das Writes über den Keyspace verteilt:

Field Promotion — setze ein hochkardinales Attribut (wie device_id oder user_id) vor den Zeitstempel: device123#2026-07-13T10:00. Writes streuen jetzt über Geräte statt sich auf „jetzt“ zu türmen.
Salting — stell einen Hash-Bucket voran (03#…), sodass Writes rundlaufend über N Tablets verteilt werden.
Hashing / Umkehren — kehre eine sequenzielle ID um oder hashe sie, sodass benachbarte Werte weit auseinanderliegen.

In der Praxis ist der Key ein zusammengesetzter String, und die Reihenfolge seiner Teile ist die ganze Entscheidung:

Terminal window

# Gut: hochkardinales Präfix zuerst, dann umgekehrter Zeitstempel
# device123#20260713T0959 → Writes streuen über Geräte
# Schlecht: der Zeitstempel führt
# 20260713T1000#device123 → jeder Write türmt sich auf "jetzt"

cbt createtable metrics families=m

cbt set metrics "device123#20260713T0959" m:temp=21.4

cbt read metrics prefix="device123#" # schneller Range-Scan, ein Gerät

Das Ziel ist immer dasselbe: Writes verteilen, nicht nach Zeit sortieren. Halte zusammengehörige Daten nah genug, damit deine üblichen Range-Scans effizient bleiben, aber lass nie die „neuesten“ Zeilen alle auf ein Tablet fallen. In Bigtable ist der Row Key kein bloßer Bezeichner — er ist das Performance-Modell.

Drei weitere Dinge, die in der Produktion beißen

Das Row-Key-Design ist das große Thema, aber drei Einschränkungen erwischen Teams beim ersten Mal:

Es gibt keine Sekundärindizes. Du kannst nur per Row Key nachschlagen, also entwirfst du den Key für deinen primären Read — und für ein zweites Zugriffsmuster speicherst du dieselben Daten oft erneut unter einem anderen Key oder in einer zweiten Tabelle. Plane bewusste Denormalisierung ein; ein ad-hoc WHERE auf einer Nicht-Key-Spalte gibt es nicht.
Konsistenz hängt vom Cluster-Setup ab. Eine Single-Cluster-Instanz ist stark konsistent. Multi-Cluster-Replikation ist eventuell konsistent, und du steuerst den Traffic mit App-Profiles. Brauchst du starke Konsistenz über Regionen, ist das Spanner, nicht Bigtable.
Du zahlst für Nodes × Zeit, plus Speicher. Durchsatz wird bereitgestellt: untätige Nodes kosten trotzdem, also dimensioniere auf die Dauerlast und nutze Autoscaling für Spitzen. Und halte Zeilen hoch, nicht breit — modelliere Events als viele Zeilen und halte jede einzelne Zeile deutlich unter dem ~256-MB-Limit, statt eine riesige Zeile wachsen zu lassen.

Wann man Bigtable NICHT nutzen sollte

Bigtable ist ein Spezialist, und der falsche Workload macht es schmerzhaft:

Du brauchst SQL-Analytics, Joins oder Ad-hoc-Aggregation → das ist BigQuery. Bigtable scannt und gruppiert dir keine Milliarden Zeilen.
Du brauchst Multi-Row-Transaktionen oder ein relationales Schema → das ist Spanner. Bigtable garantiert Atomarität nur pro Zeile.
Du hast kleine Daten oder moderaten Traffic → das Mindest-Cluster und das Betriebsmodell sind Overkill. Ein verwaltetes Postgres (Cloud SQL / AlloyDB) ist einfacher und günstiger.
Dein Zugriffsmuster ist unvorhersehbar und query-getrieben → ohne klares Key-Zugriffsmuster kämpfst du gegen das Row-Key-Modell, statt es zu reiten.

Bigtable verdient sein Geld im großen Maßstab, auf einem bekannten Key. Darunter gewinnen einfachere Werkzeuge.

Die Feldregel

Passe die Engine an das Zugriffsmuster an, nicht an das „Petabytes“-Etikett. Bigtable für durchsatzstarken Punktzugriff auf einem bekannten Key; BigQuery für SQL-Analytics über riesige Scans; Spanner für relationale Transaktionen; Cassandra oder DynamoDB, wenn du außerhalb von Google Cloud bist. Und wenn du Bigtable wählst, verbring deine Design-Zeit mit dem Row Key — verteile Writes, halte Scans knapp und sortiere deinen Keyspace nie nach Zeit. Alles andere am Skalieren von Bigtable erledigt sich von selbst; der Row Key ist der Teil, den nur du richtig hinbekommen kannst.

Bigtable steht selten allein — meist sitzt es hinter einem Strom von Events, der es mit Writes füttert. Um diesen Ingestion-Pfad sauber zu halten, siehe Pub/Sub oder Eventarc? Event-getriebenes GCP ohne Spaghetti.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Cloud Bigtable in 2026: When Wide-Column Beats BigQuery, Spanner, and Cassandra

Aleksei Aleinikov — Mon, 13 Jul 2026 15:00:00 +0000

Bigtable is the most misunderstood database on Google Cloud. Teams reach for BigQuery when they need Bigtable, bolt an analytics warehouse onto a workload that just wants fast key lookups, and then wonder why the bill and the latency both went the wrong way. Others hear “NoSQL at Google scale” and throw Bigtable at a problem that actually needed relational transactions.

The confusion is understandable — the names all blur together, and every one of them says “petabytes” on the tin. But these engines solve genuinely different problems, and picking the wrong one is expensive in a way you feel for years. This is a practical guide to what Cloud Bigtable actually is, when it beats BigQuery, Spanner, Cassandra and DynamoDB, and the single design decision that determines whether it flies or falls over.

What Bigtable Actually Is

Bigtable is a wide-column NoSQL store : a single, enormous table where each row is addressed by one row key , and columns are sparse and grouped into column families. It descends directly from the 2006 Bigtable paper that inspired HBase, Cassandra, and much of the NoSQL era — and the same core ideas still explain how it behaves today.

Under the hood, three things matter:

Rows are stored sorted by row key. The table is one long, lexicographically ordered keyspace — this is why range scans are cheap and why key design matters so much (more on that below).
The table is split into tablets. Contiguous ranges of rows form tablets, and each tablet is served by exactly one node. Add nodes and Bigtable rebalances tablets across them automatically.
Storage is separated from compute. Data lives as immutable SSTables on Colossus, Google’s distributed file system. Nodes serve requests; they don’t own the data. That separation is why you scale throughput by adding nodes without ever moving a byte of data — and why Bigtable holds single-digit-millisecond latency from gigabytes to petabytes.

That is the whole mental model: a sorted wide-column table, sharded into tablets, served by a thin compute layer over durable storage. Everything Bigtable is good and bad at follows from it.

Where It Fits: Bigtable vs BigQuery vs Spanner vs Cassandra

The fastest way to pick right is to place each engine by how you access the data, not by the marketing.

Cloud Bigtable — point/key access, wide-column NoSQL. High-throughput reads and writes by row key, single-digit-ms latency, single-row atomicity.
Cloud Spanner — point/key access, but relational with SQL and strong multi-row transactions. You pay more per operation for that correctness.
BigQuery — the opposite corner: full-table analytical scans with SQL. Superb for aggregations over billions of rows, wrong for fetching one row fast.
Cassandra / DynamoDB — the same wide-column family as Bigtable, the ones you reach for on AWS/Azure or in a specific hybrid setup.

Here is the same decision as a table:

	Cloud Bigtable	BigQuery	Cloud Spanner	Cassandra / DynamoDB
Data model	Wide-column NoSQL (sparse)	Columnar warehouse	Relational (SQL)	Wide-column NoSQL
Best at	High-throughput key reads/writes	Ad-hoc analytics over huge scans	Global, strongly-consistent transactions	Key reads/writes off-GCP
Query	Key + range scans, no joins	Full SQL, joins, aggregates	Full SQL + transactions	Key/CQL API, no joins
Transactions	Single-row atomic only	None (analytics)	Multi-row, external consistency	Single-row / lightweight
Latency	Single-digit ms at any scale	Seconds (scan-based)	Low ms (higher than Bigtable)	Single-digit ms
Scale	Petabytes, linear with nodes	Petabytes, serverless	Petabytes, global	Petabytes
Pick when	Time-series, IoT, adtech, ML features	You need SQL analytics, not point reads	You need relational + strong txn	You are on AWS/Azure or hybrid

The pattern is clear: Bigtable owns point access at massive scale. The moment you need SQL analytics, that is BigQuery; the moment you need relational transactions, that is Spanner. If you are still choosing between the two warehouses for the analytics side, the trade-offs are laid out in BigQuery vs Snowflake in 2026: An Honest Comparison.

When Bigtable Is the Right Call

Bigtable shines when a workload has a known key access pattern and a very high read/write rate. The classic fits:

Time-series and monitoring — metrics, events, and sensor readings written continuously and read back by entity + time range.
IoT — millions of devices each appending data; Bigtable absorbs the write firehose without breaking latency.
Adtech and personalization — user profiles and real-time bidding state fetched in milliseconds, billions of times a day.
Financial / operational data — high-volume transactional records (not multi-row transactions) like tick data or ledgers.
ML feature stores — low-latency feature lookups at serving time, at a scale that would make a relational database sweat.

The common thread: you know the key, you need the answer fast, and there is a lot of traffic. If that is your workload and you do not need joins or multi-row transactions, Bigtable is hard to beat.

The Row Key Is the Whole Game

Everything good about Bigtable depends on one decision: the row key. Because rows are stored sorted and split into tablets by contiguous range, the key determines which node handles each write. Get it wrong and you defeat the entire architecture.

The trap is sequential keys — a raw timestamp, an auto-incrementing counter, anything monotonic. Every new write sorts to the end of the keyspace, which means every write lands in the same tablet, which means one node takes 100% of the write load while the rest sit idle. You bought a hundred-node cluster and you are using one. This is the number-one Bigtable performance bug, and it is entirely self-inflicted.

The fix is a high-cardinality prefix that spreads writes across the keyspace:

Field promotion — put a high-cardinality attribute (like device_id or user_id) before the timestamp: device123#2026-07-13T10:00. Writes now scatter across devices instead of piling onto “now.”
Salting — prepend a hash bucket (03#…) so writes distribute round-robin across N tablets.
Hashing / reversing — reverse a sequential ID or hash it so adjacent values land far apart.

In practice the key is a compound string, and the order of its parts is the whole decision:

Terminal window

# Good: high-cardinality prefix first, then a reversed timestamp
# device123#20260713T0959 → writes scatter across devices
# Bad: the timestamp leads
# 20260713T1000#device123 → every write piles onto "now"

cbt createtable metrics families=m

cbt set metrics "device123#20260713T0959" m:temp=21.4

cbt read metrics prefix="device123#" # fast range scan for one device

The goal is always the same: distribute writes, don’t sort them by time. Keep related data close enough that your common range scans stay efficient, but never let the “newest” rows all collapse onto one tablet. In Bigtable, the row key is not just an identifier — it is the performance model.

Three More Things That Bite in Production

Row-key design is the big one, but three constraints catch teams the first time:

There are no secondary indexes. You can only look up by row key, so you design the key for your primary read — and for a second access pattern you often store the same data again under a different key or in a second table. Plan for deliberate denormalization; there is no ad-hoc WHERE on a non-key column.
Consistency depends on your cluster setup. A single-cluster instance is strongly consistent. Multi-cluster replication is eventually consistent, and you steer traffic with app profiles. If you need strong consistency across regions, that is Spanner, not Bigtable.
You pay for nodes × time, plus storage. Throughput is provisioned: idle nodes still cost money, so size to sustained load and lean on autoscaling for spikes. And keep rows tall, not wide — model events as many rows and keep any single row well under the ~256 MB limit, instead of growing one giant row.

When NOT to Use Bigtable

Bigtable is a specialist, and the wrong workload makes it painful:

You need SQL analytics, joins, or ad-hoc aggregation → that is BigQuery. Bigtable will not scan-and-group billions of rows for you.
You need multi-row transactions or a relational schema → that is Spanner. Bigtable guarantees atomicity only per row.
You have small data or modest traffic → the minimum cluster and operational model are overkill. A managed Postgres (Cloud SQL / AlloyDB) is simpler and cheaper.
Your access pattern is unpredictable and query-driven → without a clear key access pattern, you will fight the row-key model instead of riding it.

Bigtable earns its keep at scale, on a known key. Below that bar, simpler tools win.

The Field Rule

Match the engine to the access pattern, not to the “petabytes” label. Bigtable for high-throughput point access on a known key; BigQuery for SQL analytics over huge scans; Spanner for relational transactions; Cassandra or DynamoDB when you are off Google Cloud. And if you do pick Bigtable, spend your design time on the row key — distribute writes, keep scans tight, and never sort your keyspace by time. Everything else about scaling Bigtable takes care of itself; the row key is the part only you can get right.

Bigtable rarely lives alone — it usually sits behind a stream of events feeding it writes. For keeping that ingestion path clean, see Pub/Sub or Eventarc? Event-Driven GCP Without the Spaghetti.

Originally published at alekseialeinikov.com

Wie man 1.000.000 Benachrichtigungen versendet, ohne abzustürzen

Aleksei Aleinikov — Mon, 13 Jul 2026 12:00:00 +0000

Eine Benachrichtigung zu senden ist ein Funktionsaufruf. Eine Million zu senden ist ein Problem verteilter Systeme im Gewand eines Funktionsaufrufs.

Die naive Variante wirkt harmlos: Ein Nutzer löst ein Event aus, du iterierst über eine Million Empfänger und rufst für jeden den Push-, E-Mail- oder SMS-Provider auf. Im Demo funktioniert es. Bei tausend Nutzern funktioniert es. Dann fächert ein Produkt-Launch ein einziges Event über die gesamte Nutzerbasis auf, jeder Send wartet auf eine langsame Drittanbieter-API, und der Request-Thread, der in 50 ms hätte antworten sollen, hält jetzt eine Million offene Aufrufe. Die API stürzt ab — nicht weil der Code falsch ist, sondern weil die Form falsch ist.

Das hier ist ein anbieterneutraler Durchgang durch die Form, die hält: eine Message-Queue-Architektur mit Fan-out-Workern, Back-Pressure und den langweiligen Zuverlässigkeitsteilen, die verhindern, dass ein „Send“ zum Ausfall wird. Die Beispiele sind cloud-agnostisch — dasselbe Muster läuft auf RabbitMQ, Kafka, SQS oder Pub/Sub.

Der Fehler: Die Arbeit im Request erledigen

Als Erstes muss man reparieren, wo die Arbeit passiert. Wenn du im Request-Handler sendest, ist der Thread, der den HTTP-Aufruf angenommen hat, derselbe Thread, der auf einen langsamen externen Provider wartet — millionenfach.

Zwei Dinge gehen gleichzeitig schief. Erstens stapelt sich die Latenz : Die Antwortzeit deiner API ist jetzt die Summe aller Provider-Aufrufe, also zieht ein langsamer Anbieter den ganzen Request nach unten. Zweitens explodiert die Nebenläufigkeit : Eine Spitze reiht sich nirgends ein, sie öffnet eine Million gleichzeitige Sends gegen Provider, die dich bereitwillig rate-limiten oder abweisen, während dein eigener Connection-Pool und Speicher austrocknen.

Die Faustregel ist einfach:

Der Request soll den Auftrag annehmen, nicht ausführen.

Nimm das Event an, schreib es in eine dauerhafte Queue und antworte in Millisekunden mit 202 Accepted. Die schwere Arbeit wandert zu Hintergrund-Workern, die du unabhängig vom Request-Pfad skalieren, drosseln und wiederholen kannst. Die Spitze ist immer noch da — aber jetzt landet sie in einer Queue, wo ein Rückstau eine Unannehmlichkeit ist, kein Ausfall.

In „schreib es in eine dauerhafte Queue“ versteckt sich eine Feinheit. Schreibst du in deine Datenbank und publizierst in die Queue als zwei getrennte Schritte, verliert ein Absturz dazwischen das Event oder sendet ein Phantom. Die Lösung ist das transaktionale Outbox-Pattern : Schreib das Event in derselben Datenbank-Transaktion wie deinen fachlichen Write in eine outbox-Tabelle, und ein separater Relay befördert diese Zeilen in die Queue. Ein atomarer Write, keine verlorenen Events, keine doppelten Sends.

Der Kern: Eine Fan-out-Pipeline

Sobald die Arbeit vom Request-Pfad weg ist, wird die Architektur zur Pipeline. Ein Event kommt herein; kanalspezifische Benachrichtigungen gehen hinaus. Der Baustein, der sie skalieren lässt, ist Fan-out : eine einzige Ingress-Queue, aufgeteilt in je eine isolierte Spur pro Kanal.

Geh den Pfad durch:

Producer → Ingress-Queue. Die API (oder ein vorgelagertes Event) publiziert pro logischem Event eine Nachricht in ein einziges dauerhaftes Topic. Das ist das Einzige, was der Request-Pfad berührt, und es ist schnell und append-only.
Fan-out. Ein leichtgewichtiger Schritt liest das Ingress-Event, entscheidet welche Kanäle gelten (dieser Nutzer will Push + E-Mail, keine SMS) und publiziert eine Nachricht in die Queue jedes Kanals. Fan-out ist, wo aus „einem Event“ „drei Sends“ werden.
Kanalspezifische Queues + Worker. Jeder Kanal — Push, E-Mail, SMS — hat seine eigene Queue und seinen eigenen Worker-Pool. Diese Isolation ist der ganze Punkt: Ein langsames SMS-Gateway staut nur die SMS-Queue. Push und E-Mail fließen weiter.
Provider. Jeder Worker-Pool spricht mit seinem Provider (APNs/FCM, SMTP/SES, ein SMS-Gateway) in einem Tempo, das dieser Provider verkraften kann.

Die Isolation bringt drei Dinge, die ein einzelner geteilter Worker-Pool nicht kann: unabhängiges Skalieren (mehr E-Mail-Worker hochfahren, ohne SMS anzufassen), unabhängiges Scheitern (ein toter Provider staut die anderen nicht) und unabhängiges Tuning (E-Mail verträgt Minuten Verzögerung; Push oft nicht).

Zwei Hebel machen aus dem Diagramm ein Produktionssystem. Batche zum Provider : Die meisten Push-, E-Mail- und SMS-APIs akzeptieren Hunderte Empfänger pro Aufruf, also sendet ein Worker, der seine Queue zu Batches bündelt, weit mehr pro Sekunde als einer, der einzeln sendet. Und trenne nach Priorität, nicht nur nach Kanal : Ein transaktionaler OTP und eine Marketing-Blast dürfen sich nie eine Queue teilen — gib latenzkritischem Verkehr seine eigene Spur, damit eine Kampagne über eine Million Nachrichten keinen Login-Code verzögert. Wo die Reihenfolge pro Nutzer zählt, schlüssle diese Nachrichten auf dieselbe Partition, damit ein einzelner Worker sie der Reihe nach abarbeitet.

Anhand der Queue-Tiefe skalieren, nicht der Request-Rate

Die Worker sind der Ort, an dem eine Million Events tatsächlich versendet werden, und der Trick ist, worauf man skaliert. Skaliere nicht auf CPU oder Request-Rate — skaliere auf Queue-Tiefe und Nachrichtenalter. Wächst der Rückstau über einen Schwellenwert, füge Worker-Replicas hinzu; leert er sich, skaliere zurück.

Genau das entkoppelt Ankunftstempo von Sendetempo. Eine Million Events können in einer Minute eintreffen; deine Worker brauchen vielleicht eine Stunde zum Senden, gedrosselt auf das, was die Provider erlauben. Das ist in Ordnung — die Queue federt die Differenz ab. Die Aufgabe des Systems ist nicht, alles sofort zu senden. Sie ist, nie ein Event zu verlieren und nie abzustürzen , während so schnell abgebaut wird, wie die nachgelagerten Provider es zulassen.

Diese Worker-Pools laufen meist auf einer autoskalierenden Container-Plattform, und ist diese Plattform Kubernetes, zählt die Basis, auf der sie läuft, ebenso viel wie die Pipeline selbst — siehe Secure-by-Default GKE: Eine Referenzarchitektur für 2026.

Das ist dasselbe event-getriebene Rückgrat hinter jedem entkoppelten System. Baust du es speziell auf GCP, lohnt sich als Nächstes der Abgleich der Trade-offs zwischen Transport und Router: Pub/Sub oder Eventarc? Event-getriebenes GCP ohne Spaghetti.

Unter Last oben bleiben: Die langweiligen Teile, die zählen

Eine Queue und ein paar Worker bringen dich durchs Demo. Was einen Lauf über eine Million Nachrichten um 3 Uhr morgens am Leben hält, ist die Zuverlässigkeitsschicht — die Teile, die alle überspringen, bis die Produktion sie lehrt. Es sind vier, und sie funktionieren nur, weil du eine Queue hast.

Retry mit Backoff. Provider scheitern vorübergehend — ein Timeout, ein 503, ein kurzes Rate-Limit. Wiederhole, aber mit exponentiellem Backoff und Jitter , nie in einer engen Schleife. Eine enge Retry-Schleife über Tausende Worker ist von einem Denial-of-Service-Angriff nicht zu unterscheiden — und das Ziel ist dein eigener Provider. Backoff verteilt die Retries, sodass ein Aussetzer sich erholt, statt sich zu verstärken.

Dead-Letter-Queue (DLQ). Manche Nachrichten gelingen nie: ein fehlerhaftes Payload, eine dauerhaft ungültige Adresse, ein Bug. Verschiebe die Nachricht nach N Versuchen in eine Dead-Letter-Queue , statt sie endlos zu wiederholen. Die schlechte Nachricht wird zur Prüfung geparkt — nie verloren, nie die Linie blockierend — und der gesunde Verkehr dahinter läuft weiter. Ohne DLQ wiederholt sich eine Giftnachricht, bis sie die Queue aushungert.

Idempotenz. Jede dauerhafte Queue stellt mindestens einmal zu. Eine erneute Zustellung, ein langsames Ack, ein Worker, der nach dem Senden aber vor dem Ack abstürzt — jedes davon bedeutet, dass dieselbe Nachricht zweimal verarbeitet wird. Bedeutet „zweimal“ eine zweite E-Mail oder eine Doppelbelastung, ist das ein Bug, den du geschrieben hast. Dedupliziere auf einer stabilen Message-ID : notiere „Nachricht abc123 bereits gesendet“ und behandle einen erneuten Lauf als No-op. Halte diesen Eintrag in einem schnellen Store mit einer TTL, die dein Retry-Fenster abdeckt — du musst nur jüngste IDs merken, nicht die ganze Historie. Die erneute Zustellung wird harmlos.

Back-Pressure. Das ist der Schutz, der das gesamte System vom Kippen abhält. Jeder Worker respektiert ein Concurrency- und Rate-Limit pro Provider. Wird ein Provider langsamer, werden die Worker mit ihm langsamer — die Queue wächst, aber nichts stürzt ab. Back-Pressure verwandelt „der Provider hat Mühe“ in „der Rückstau ist heute tiefer“, statt „wir haben ihn gehämmert, bis er uns blockiert hat“.

Zusammengenommen sind diese vier der Grund, warum das Design seinen eigenen Erfolg überlebt. Die Queue macht sie möglich; überspringst du sie, wird deine Retry-Logik zu einem selbstverschuldeten DDoS gegen genau die Provider, von denen du abhängst.

Alles zusammengesetzt

Verfolge einen Launch durch die fertige Form. Eine Kampagne feuert ein Event. Die API schreibt es in die Ingress-Queue und antwortet in Millisekunden — der nutzerseitige Pfad weiß nicht einmal, dass eine Million Sends kommen. Fan-out teilt das Event in Push-, E-Mail- und SMS-Arbeit auf drei isolierten Queues. Jeder Worker-Pool skaliert auf seinem eigenen Rückstau, sendet im Tempo seines Providers, wiederholt vorübergehende Fehler mit Backoff, verschiebt die hoffnungslosen in die DLQ und dedupliziert erneute Zustellungen auf einer Message-ID. Die Spitze wird zu drei abbauenden Queues. Nichts stürzt ab.

Nichts davon ist exotisch. Es ist eine Queue, ein Fan-out-Schritt, Worker-Pools, die auf Tiefe skalieren, und vier Zuverlässigkeits-Schutzmechanismen. Der Fehler waren nie die Tools — es war, eine Aufgabe verteilter Systeme in einem einzigen Request-Thread zu erledigen. Nimm die Arbeit von diesem Thread, isoliere die Kanäle und lass Back-Pressure die Spitze abfedern — und „eine Million Benachrichtigungen senden“ hört auf, eine beängstigende Zahl zu sein, und wird zu einem Dienstag.

Die Feldregel

Nimm den Auftrag an, führ ihn nicht aus. Fan-out auf je eine Queue pro Kanal, damit Fehler lokal bleiben. Skaliere Worker auf Queue-Tiefe, nicht auf Request-Rate. Und behandle Retries, Dead-Letter-Queues, Idempotenz und Back-Pressure als tragend, nicht optional — sie sind der Unterschied zwischen einem Rückstau und einem Ausfall.

Ursprünglich veröffentlicht auf alekseialeinikov.com

How to Send 1,000,000 Notifications Without Falling Over

Aleksei Aleinikov — Mon, 13 Jul 2026 12:00:00 +0000

Sending one notification is a function call. Sending a million is a distributed-systems problem wearing a function call’s clothes.

The naive version looks innocent: a user triggers an event, you loop over a million recipients, and for each one you call the push, email, or SMS provider. It works in the demo. It works for a thousand users. Then a product launch fans a single event out to your whole user base, every send waits on a slow third-party API, and the request thread that was supposed to return in 50 ms is now holding a million open calls. The API falls over — not because the code is wrong, but because the shape is wrong.

This is a vendor-neutral walkthrough of the shape that holds: a message-queue architecture with fan-out workers, back-pressure, and the boring reliability parts that keep a “send” from turning into an outage. The examples are cloud-agnostic — the same pattern runs on RabbitMQ, Kafka, SQS, or Pub/Sub.

The Mistake: Doing the Work Inside the Request

The first thing to fix is where the work happens. When you send inside the request handler, the thread that accepted the HTTP call is the same thread waiting on a slow external provider — a million times over.

Two things go wrong at once. First, latency stacks : your API’s response time is now the sum of every provider call, so one slow vendor drags the whole request down. Second, concurrency explodes : a spike doesn’t queue anywhere, it opens a million concurrent sends against providers that will happily rate-limit or drop you, while your own connection pools and memory run dry.

The rule of thumb is simple:

The request should accept the job, not do the job.

Accept the event, write it to a durable queue, and return 202 Accepted in milliseconds. The heavy lifting moves to background workers that you can scale, throttle, and retry independently of the request path. The spike is still there — but now it lands in a queue, where a backlog is an inconvenience, not an outage.

One subtlety hides in “write it to a durable queue.” If you write to your database and publish to the queue as two separate steps, a crash between them loses the event or sends a phantom one. The fix is the transactional outbox : commit the event to an outbox table in the same database transaction as your business write, then a separate relay ships those rows to the queue. One atomic write, no lost events, no double sends.

The Core: A Fan-Out Pipeline

Once the work is off the request path, the architecture becomes a pipeline. One event enters; per-channel notifications leave. The piece that makes it scale is fan-out : a single ingress queue, split into one isolated lane per channel.

Walk the path:

Producer → ingress queue. The API (or an upstream event) publishes one message per logical event to a single durable topic. This is the only thing the request path touches, and it’s fast and append-only.
Fan-out. A lightweight step reads the ingress event, decides which channels apply (this user wants push + email, not SMS), and publishes a message to each channel’s queue. Fan-out is where “one event” becomes “three sends.”
Per-channel queues + workers. Each channel — push, email, SMS — has its own queue and its own worker pool. This isolation is the whole point: a slow SMS gateway backs up the SMS queue only. Push and email keep flowing.
Providers. Each worker pool talks to its provider (APNs/FCM, SMTP/SES, an SMS gateway) at a rate that provider can absorb.

The isolation buys you three things you can’t get from a single shared worker pool: independent scaling (spin up more email workers without touching SMS), independent failure (one dead provider doesn’t stall the others), and independent tuning (email tolerates minutes of delay; push often can’t).

Two levers turn this from a diagram into a production system. Batch to the provider : most push, email, and SMS APIs accept hundreds of recipients per call, so a worker that groups its queue into batches sends far more per second than one that goes one-at-a-time. And split by priority, not just by channel : a transactional OTP and a marketing blast should never share a queue — give latency-critical traffic its own lane so a million-message campaign can’t delay a login code. Where per-user ordering matters, key those messages to the same partition so a single worker handles them in sequence.

Scale on Queue Depth, Not Request Rate

The workers are where a million events actually get sent, and the trick is what you scale on. Don’t autoscale on CPU or request rate — scale on queue depth and message age. When the backlog grows past a threshold, add worker replicas; when it drains, scale back down.

This is what decouples arrival speed from send speed. A million events can arrive in a minute; your workers might take an hour to send them, throttled to what the providers allow. That’s fine — the queue absorbs the difference. The system’s job is not to send everything instantly. It’s to never lose an event and never fall over , while draining as fast as the downstream providers permit.

Those worker pools usually run on an autoscaling container platform, and if that platform is Kubernetes, the base it runs on matters as much as the pipeline itself — see Secure-by-Default GKE: A Reference Architecture for 2026.

This is the same event-driven backbone behind any decoupled system. If you’re building it on GCP specifically, the trade-offs between the transport and the router are worth reading next: Pub/Sub or Eventarc? Event-Driven GCP Without the Spaghetti.

Staying Up Under Load: The Boring Parts That Matter

A queue and some workers will get you through a demo. What keeps a million-message run alive at 3 a.m. is the reliability layer — the parts everyone skips until production teaches them. There are four, and they only work because you have a queue.

Retry with backoff. Providers fail transiently — a timeout, a 503, a brief rate-limit. Retry, but with exponential backoff and jitter , never a tight loop. A tight retry loop across thousands of workers is indistinguishable from a denial-of-service attack, and the target is your own provider. Backoff spreads the retries out so a blip recovers instead of amplifying.

Dead-letter queue (DLQ). Some messages never succeed: a malformed payload, a permanently-invalid address, a bug. After N attempts, move the message to a dead-letter queue instead of retrying forever. The bad message is parked for inspection — never lost, never blocking the line — and the healthy traffic behind it keeps moving. Without a DLQ, one poison message retries until it starves the queue.

Idempotency. Every durable queue delivers at-least-once. A redelivery, a slow ack, a worker that crashes after sending but before acking — any of these means the same message gets processed twice. If “twice” means a second email or a double charge, that’s a bug you wrote. Dedupe on a stable message ID : record “message abc123 already sent” and treat a re-run as a no-op. Keep that record in a fast store with a TTL that covers your retry window — you only need to remember recent IDs, not all of history. Redelivery becomes harmless.

Back-pressure. This is the guard that keeps the whole system from tipping over. Each worker respects a per-provider concurrency limit and rate limit. When a provider slows down, workers slow with it — the queue grows, but nothing crashes. Back-pressure turns “the provider is struggling” into “the backlog is deeper today” instead of “we hammered them until they blocked us.”

Put together, these four are why the design survives its own success. The queue makes them possible; skip them and your retry logic becomes a self-inflicted DDoS on the exact providers you depend on.

Putting It Together

Trace one launch through the finished shape. A campaign fires one event. The API writes it to the ingress queue and returns in milliseconds — the user-facing path never even knows a million sends are coming. Fan-out splits the event into push, email, and SMS work on three isolated queues. Each worker pool scales on its own backlog, sends at its provider’s pace, retries transient failures with backoff, dead-letters the hopeless ones, and dedupes redeliveries on a message ID. The spike becomes three draining queues. Nothing falls over.

None of this is exotic. It’s a queue, a fan-out step, worker pools that scale on depth, and four reliability guards. The mistake was never the tools — it was doing a distributed-systems job inside a single request thread. Move the work off that thread, isolate the channels, and let back-pressure absorb the spike, and “send a million notifications” stops being a scary number and becomes a Tuesday.

The Field Rule

Accept the job, don’t do it. Fan out to one queue per channel so failures stay local. Scale workers on queue depth, not request rate. And treat retries, dead-letter queues, idempotency, and back-pressure as load-bearing, not optional — they’re the difference between a backlog and an outage.

Originally published at alekseialeinikov.com

Sovereign by Design: Building a Sovereign Platform on Kubernetes

Aleksei Aleinikov — Sun, 12 Jul 2026 12:00:00 +0000

“Sovereign cloud” is the loudest phrase in European IT right now, and most of it is a sticker. Vendors slap it on a region, a contract clause, or a compliance certificate and call the platform sovereign. But sovereignty is not something you buy at the checkout — it is a property of how you architect. If it is not designed in, no label puts it there.

This is a practical, vendor-neutral architecture for building a genuinely sovereign platform. The core idea: stop treating sovereignty as one thing to procure, and start treating it as three independent layers you design for — with Kubernetes as the portability spine that ties them together.

This builds on a security foundation rather than replacing it. If your platform is not hardened first, sovereignty is moot — start from the secure-by-default GKE reference architecture and layer sovereignty on top.

Sovereignty Is Three Layers, Not One

The single biggest mistake is treating “sovereign” as a binary you either have or lack. It is really three separate questions, and a platform can score high on one while failing another.

Data sovereignty — Where does the data physically live, and who can legally compel access to it? Residency is only half; the legal reach over the operator is the other half.
Operational sovereignty — Who runs the control plane? Who can read, administer, or be compelled to expose the running system?
Technical sovereignty — Can you leave? Are your workloads portable, or welded to one provider’s proprietary APIs?

A typical “sovereign cloud” offering covers one of these convincingly and waves at the rest. Real sovereignty means designing for all three — so let’s take them in the order that gives you the most leverage.

The Freedom to Leave: Portability as the Real Test

Technical sovereignty has a brutally simple test: what does it cost you to leave?

If leaving a provider means rewriting your applications and re-architecting around a different set of proprietary services, you are locked in — and lock-in is the exact opposite of sovereignty. If leaving means redeploying the same manifests onto a different conformant cluster, you are sovereign at the technical layer.

This is where Kubernetes earns its place — not as a container scheduler, but as the portability layer. Standard Kubernetes manifests, OCI images, Helm charts and infrastructure-as-code are conformant across every major platform and on-premises. The workload does not change when the ground underneath it does.

Portability is not free, though. The workload core travels; the edges do not — storage classes, ingress controllers, load-balancer annotations, and cloud identity integration are provider-specific and have to be abstracted or swapped deliberately. Real portability means keeping that core clean and the provider-specific edges thin and replaceable, not pretending nothing changes when you move.

The discipline is to keep your critical path on portable, standards-based components and to treat every proprietary managed service as a deliberate trade. A queue expressed as a Kubernetes workload moves anywhere; a queue that is a provider-specific API is an anchor.

# Portable: the workload is a standard object, not a vendor API.
# The same manifest runs on GKE, EKS, AKS, or an EU-hosted cluster.

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ingest

spec:

  replicas: 3

  template:

    spec:

      containers:

        - name: ingest

          image: registry.example.eu/ingest:1.8.0 # your registry, your region

          envFrom:

            - secretRef:

                name: ingest-config

Portability does not mean never using a managed service. It means knowing, for each one, exactly what leaving would cost — so “we could move” is a measured exit plan, not a comforting slogan.

Who Holds the Keys: Residency Is Not Custody

Here is the trap that sinks most “our data is in an EU region, so we’re sovereign” claims.

Data residency chooses where the bytes sit. It says nothing about who can read them. A provider operating under a foreign legal regime — the US CLOUD Act is the canonical example — can be compelled to hand over data regardless of which region it lives in. Residency alone does not stop that.

The control that actually changes the outcome is key custody. The pattern that truly delivers it is HYOK (hold your own key) — an external key manager such as Google’s External Key Manager (EKM) or AWS XKS, where the provider calls out to your key service to decrypt and never holds the key material itself. Plain BYOK , where you import a key into the provider’s own KMS, is weaker: the provider does hold the key, so it defends against a different and smaller threat. With true external custody:

The provider stores your data encrypted , and ciphertext without your key is noise.
If they are legally compelled to hand data over, what they can produce is that same worthless ciphertext.
Revoke access to the key and new decryptions stop everywhere at once — already-cached data keys age out shortly after — which is effectively crypto-shredding the data.

Residency and key custody are complementary: residency answers “where,” custody answers “who can read it.” Custody is the one that turns a legal request into a non-event.

Keys are the whole game at the identity layer too. The same “no long-lived secret to seize” principle applies to workload credentials — see Kill Your Service Account Keys with Workload Identity Federation.

Operational Sovereignty: Who Can Read and Run It

The quietest layer is operational. Even with portable workloads and customer-held keys, sovereignty leaks if the people operating the plane can silently read or administer your systems from outside your jurisdiction.

Designing for operational sovereignty means:

EU-only operations for regulated workloads — support and administration performed within the jurisdiction, not routed globally.
Access transparency — every provider-side access to your environment is logged and visible to you, so “trust us” becomes “verify.”
Least privilege and just-in-time access — no standing administrative access; elevation is scoped, time-boxed, and audited.
Your own audit trail — logs shipped to storage you control, so the record of who did what does not depend on the provider’s goodwill.

None of this is exotic. It is the same access-control discipline you already apply to your own teams, extended to the provider as an untrusted operator.

Sovereignty Without Dogma: A Decision Framework

The failure mode on the other side is treating sovereignty as a purity test and paying a heavy velocity tax to make a marketing brochure with zero real workloads. Sovereignty is a spectrum , and you apply it by classification, not by reflex.

A pragmatic frame:

Classify the workload. Regulated or high-sensitivity data, or a system whose compromise is existential? It earns the full treatment: portable components, external key custody, operational controls. A stateless internal tool with no sensitive data? A convenient managed service is a perfectly rational trade.
Measure the lock-in, don’t assume it. For each proprietary dependency in the critical path, write down the real cost of leaving. Some are cheap to swap; some are anchors. You cannot manage what you have not measured.
Design the exit before you need it. Portability that has never been exercised is a hope, not a capability. Keep the option real: standard manifests, your own registry, keys you hold, infrastructure-as-code that can target a second platform.

Applied this way, sovereignty stops being a religious argument and becomes an engineering trade-off you make consciously, workload by workload.

The Honest Limits

Sovereignty has a cost, and pretending otherwise is how you end up resenting it. Portable, standards-based components sometimes mean giving up the slickest proprietary service. External key custody adds operational complexity and a failure mode of its own — lose the key and the data really is gone. Full operational sovereignty can raise support costs. And no architecture removes the legal reality that if you run on a provider at all, you are trusting something.

The point is not maximal sovereignty everywhere. It is that sovereignty becomes a property you designed on purpose — measured, classified, and exercised — instead of a sticker someone sold you. Build the three layers deliberately, keep the exit real, hold your own keys, and “sovereign” stops being a claim you hope survives scrutiny and becomes one you can actually demonstrate.

Originally published at alekseialeinikov.com

Sovereign by Design: Eine souveräne Plattform auf Kubernetes bauen

Aleksei Aleinikov — Sun, 12 Jul 2026 12:00:00 +0000

„Souveräne Cloud“ ist derzeit der lauteste Begriff in der europäischen IT — und das meiste davon ist ein Aufkleber. Anbieter kleben ihn auf eine Region, eine Vertragsklausel oder ein Compliance-Zertifikat und nennen die Plattform souverän. Aber Souveränität kauft man nicht an der Kasse — sie ist eine Eigenschaft davon, wie du entwirfst. Ist sie nicht eingebaut, bringt sie kein Label hinein.

Das hier ist eine praxisnahe, anbieterneutrale Architektur, um eine wirklich souveräne Plattform zu bauen. Die Kernidee: Souveränität nicht als eine zu beschaffende Sache behandeln, sondern als drei unabhängige Schichten, für die du entwirfst — mit Kubernetes als Portabilitäts-Rückgrat, das sie verbindet.

Das baut auf einem Sicherheitsfundament auf, ersetzt es nicht. Ist deine Plattform nicht zuerst gehärtet, ist Souveränität irrelevant — starte mit der Secure-by-Default-GKE-Referenzarchitektur und lege Souveränität darüber.

Souveränität besteht aus drei Schichten, nicht aus einer

Der größte Fehler ist, „souverän“ als Binärzustand zu behandeln, den man hat oder nicht. Es sind in Wahrheit drei getrennte Fragen — eine Plattform kann bei einer stark abschneiden und bei einer anderen durchfallen.

Datensouveränität — Wo liegen die Daten physisch, und wer kann rechtlich Zugriff erzwingen? Residency ist nur die halbe Miete; die rechtliche Reichweite über den Betreiber ist die andere.
Betriebssouveränität — Wer betreibt die Steuerungsebene? Wer kann das laufende System lesen, administrieren oder gezwungen werden, es offenzulegen?
Technische Souveränität — Kannst du gehen? Sind deine Workloads portabel oder an die proprietären APIs eines Anbieters geschweißt?

Ein typisches „souveränes“ Angebot deckt eine davon überzeugend ab und winkt beim Rest ab. Echte Souveränität heißt, für alle drei zu entwerfen — nehmen wir sie in der Reihenfolge, die den größten Hebel gibt.

Die Freiheit zu gehen: Portabilität als der echte Test

Technische Souveränität hat einen brutal einfachen Test: Was kostet es dich zu gehen?

Bedeutet das Verlassen eines Anbieters, deine Anwendungen neu zu schreiben und um andere proprietäre Dienste herum neu zu architektieren, bist du gefangen — und Lock-in ist das genaue Gegenteil von Souveränität. Bedeutet Weggehen, dieselben Manifeste auf einem anderen konformen Cluster neu auszurollen, bist du auf der technischen Schicht souverän.

Hier verdient sich Kubernetes seinen Platz — nicht als Container-Scheduler, sondern als Portabilitätsschicht. Standard-Kubernetes-Manifeste, OCI-Images, Helm-Charts und Infrastructure-as-Code sind über jede große Plattform und On-Premises konform. Der Workload ändert sich nicht, wenn sich der Boden darunter ändert.

Portabilität ist aber nicht gratis. Der Workload-Kern reist mit; die Ränder nicht — Storage Classes, Ingress-Controller, LoadBalancer-Annotationen und Cloud-Identity-Integration sind anbieterspezifisch und müssen bewusst abstrahiert oder getauscht werden. Echte Portabilität heißt, diesen Kern sauber und die anbieterspezifischen Ränder dünn und austauschbar zu halten — nicht so zu tun, als ändere sich beim Umzug nichts.

Die Disziplin besteht darin, deinen kritischen Pfad auf portablen, standardbasierten Komponenten zu halten und jeden proprietären Managed Service als bewussten Kompromiss zu behandeln. Eine Queue als Kubernetes-Workload zieht überallhin; eine Queue, die eine anbieterspezifische API ist, ist ein Anker.

# Portabel: der Workload ist ein Standard-Objekt, keine Vendor-API.
# Dasselbe Manifest läuft auf GKE, EKS, AKS oder einem EU-gehosteten Cluster.

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ingest

spec:

  replicas: 3

  template:

    spec:

      containers:

        - name: ingest

          image: registry.example.eu/ingest:1.8.0 # deine Registry, deine Region

          envFrom:

            - secretRef:

                name: ingest-config

Portabilität heißt nicht, nie einen Managed Service zu nutzen. Sie heißt, für jeden zu wissen, was das Verlassen genau kosten würde — damit „wir könnten wechseln“ ein gemessener Ausstiegsplan ist und kein beruhigender Slogan.

Wer hält die Schlüssel: Residency ist nicht Hoheit

Hier ist die Falle, die die meisten „unsere Daten liegen in einer EU-Region, also sind wir souverän“-Behauptungen versenkt.

Data Residency wählt, wo die Bytes liegen. Sie sagt nichts darüber, wer sie lesen kann. Ein Anbieter unter fremdem Rechtsregime — der US CLOUD Act ist das Paradebeispiel — kann gezwungen werden, Daten herauszugeben, egal in welcher Region sie liegen. Residency allein stoppt das nicht.

Der Kontrollpunkt, der das Ergebnis wirklich ändert, ist Schlüsselhoheit. Was sie wirklich liefert, ist HYOK (Hold Your Own Key) — ein externer Key Manager wie Googles External Key Manager (EKM) oder AWS XKS, bei dem der Anbieter zum Entschlüsseln deinen Key-Dienst aufruft und das Schlüsselmaterial nie selbst hält. Reines BYOK , bei dem du einen Schlüssel in das KMS des Anbieters importierst, ist schwächer: Der Anbieter hält den Schlüssel dann doch und schützt gegen eine andere, kleinere Bedrohung. Bei echter externer Hoheit gilt:

Der Anbieter speichert deine Daten verschlüsselt , und Ciphertext ohne deinen Schlüssel ist Rauschen.
Wird er rechtlich zur Herausgabe gezwungen, kann er nur denselben wertlosen Ciphertext produzieren.
Widerrufe den Zugriff auf den Schlüssel und neue Entschlüsselungen stoppen überall auf einmal — bereits gecachte Data Keys laufen kurz danach aus — was effektiv Crypto-Shredding der Daten ist.

Residency und Schlüsselhoheit ergänzen sich: Residency beantwortet „wo“, Hoheit beantwortet „wer kann es lesen“. Die Hoheit macht aus einer rechtlichen Anfrage einen Nicht-Vorfall.

Schlüssel sind auch auf der Identitätsschicht das ganze Spiel. Dasselbe Prinzip „kein langlebiges Geheimnis zum Beschlagnahmen“ gilt für Workload-Credentials — siehe Schluss mit Service-Account-Schlüsseln mit Workload Identity Federation.

Betriebssouveränität: Wer kann es lesen und betreiben

Die leiseste Schicht ist die betriebliche. Selbst mit portablen Workloads und kundengehaltenen Schlüsseln leckt Souveränität, wenn die Betreiber der Ebene deine Systeme still von außerhalb deiner Jurisdiktion lesen oder administrieren können.

Für Betriebssouveränität zu entwerfen heißt:

EU-only-Betrieb für regulierte Workloads — Support und Administration innerhalb der Jurisdiktion, nicht global geroutet.
Access Transparency — jeder anbieterseitige Zugriff auf deine Umgebung wird protokolliert und ist für dich sichtbar, sodass aus „vertrau uns“ ein „überprüfe“ wird.
Least Privilege und Just-in-Time-Zugriff — kein stehender Admin-Zugriff; Elevation ist scoped, zeitlich begrenzt und auditiert.
Dein eigener Audit-Trail — Logs in Speicher, den du kontrollierst, damit der Nachweis, wer was getan hat, nicht vom Wohlwollen des Anbieters abhängt.

Nichts davon ist exotisch. Es ist dieselbe Zugriffskontroll-Disziplin, die du bereits auf deine eigenen Teams anwendest — erweitert auf den Anbieter als nicht vertrauenswürdigen Betreiber.

Souveränität ohne Dogma: Ein Entscheidungsrahmen

Der Fehlermodus auf der anderen Seite ist, Souveränität als Reinheitstest zu behandeln und eine schwere Velocity-Steuer zu zahlen, um eine Marketing-Broschüre mit null echten Workloads zu bauen. Souveränität ist ein Spektrum , und du wendest sie per Klassifizierung an, nicht per Reflex.

Ein pragmatischer Rahmen:

Klassifiziere den Workload. Regulierte oder hochsensible Daten, oder ein System, dessen Kompromittierung existenziell ist? Es verdient die volle Behandlung: portable Komponenten, externe Schlüsselhoheit, Betriebskontrollen. Ein zustandsloses internes Tool ohne sensible Daten? Ein bequemer Managed Service ist ein völlig rationaler Kompromiss.
Miss das Lock-in, nimm es nicht an. Notiere für jede proprietäre Abhängigkeit im kritischen Pfad die echten Kosten des Weggehens. Manche sind billig zu tauschen; manche sind Anker. Du kannst nicht steuern, was du nicht gemessen hast.
Entwirf den Ausstieg, bevor du ihn brauchst. Portabilität, die nie geübt wurde, ist Hoffnung, keine Fähigkeit. Halte die Option echt: Standard-Manifeste, deine eigene Registry, Schlüssel, die du hältst, Infrastructure-as-Code, die eine zweite Plattform ansteuern kann.

So angewandt hört Souveränität auf, ein Glaubensstreit zu sein, und wird zu einem Engineering-Kompromiss, den du bewusst triffst — Workload für Workload.

Die ehrlichen Grenzen

Souveränität hat einen Preis, und das Gegenteil zu behaupten führt dazu, sie zu bereuen. Portable, standardbasierte Komponenten bedeuten manchmal, auf den schicksten proprietären Dienst zu verzichten. Externe Schlüsselhoheit fügt Betriebskomplexität und einen eigenen Fehlermodus hinzu — verlierst du den Schlüssel, sind die Daten wirklich weg. Volle Betriebssouveränität kann Support-Kosten erhöhen. Und keine Architektur entfernt die rechtliche Realität, dass du, wenn du überhaupt bei einem Anbieter läufst, etwas vertraust.

Der Punkt ist nicht maximale Souveränität überall. Er ist, dass Souveränität zu einer Eigenschaft wird, die du bewusst entworfen hast — gemessen, klassifiziert und geübt — statt zu einem Aufkleber, den dir jemand verkauft hat. Baue die drei Schichten bewusst, halte den Ausstieg echt, halte deine eigenen Schlüssel, und „souverän“ hört auf, eine Behauptung zu sein, die hoffentlich der Prüfung standhält, und wird zu einer, die du tatsächlich belegen kannst.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Podman 2026: Rootless und daemonlose Container ohne Docker

Aleksei Aleinikov — Sat, 11 Jul 2026 12:00:00 +0000

Wer schon einmal einen Container von Hand gebaut hat — ein Overlay-Mount, eine cgroup, ein paar Namespaces, ein pivot_root — versteht Podman bereits besser als die meisten Docker-Nutzer. Podman ist im Kern genau dieselben Kernel-Primitive, verpackt in eine freundliche CLI, bei der zwei von Dockers ältesten Design-Entscheidungen leise entfernt wurden: der Root-Daemon und die Annahme, dass man als Root arbeitet.

Neu hier? Am besten spürst du, was ein Container wirklich ist, wenn du einen von Grund auf zusammensetzt — siehe Einen kleinen Linux-Container ohne Docker bauen. Dieser Artikel macht dort weiter: Was passiert, wenn jemand diese Primitive ordentlich zum Produkt macht.

Das ist kein „Docker ist tot“-Text. Docker ist weiterhin exzellent und überall. Aber 2026 ist podman das Werkzeug, zu dem ich auf Servern und in CI zuerst greife — und es lohnt sich zu verstehen warum, statt nur das Binary zu tauschen.

Dockers zwei Design-Entscheidungen, die schlecht gealtert sind

Docker hat Container populär gemacht, traf aber zwei frühe Entscheidungen, die heute schwerer wirken als 2013.

Die erste ist der Daemon. Der docker-Befehl, den du tippst, ist nur ein dünner Client; die eigentliche Arbeit macht dockerd, ein dauerhaft laufender Hintergrunddienst. Dieser Daemon lief historisch als Root , und alles, was du startest, ist ein Kindprozess davon.

Die zweite ist genau diese Root -Haltung. Jahrelang bedeutete Container-Betrieb, einem root-eigenen Daemon die Kontrolle über deinen Prozessbaum, deine Mounts und dein Netzwerk zu geben.

Keine der Entscheidungen ist ein Fehler. Aber beide konzentrieren Risiko. Ein einziger dauerhaft als Root laufender Prozess ist ein einziges, permanentes, hochwertiges Ziel — und ein Single Point of Failure. Stirbt dockerd, sind alle beaufsichtigten Container betroffen. Wird er kompromittiert, ist der Host kompromittiert.

Podman entfernt den Daemon vollständig.

Was „daemonlos“ tatsächlich bringt

Wenn du podman run ausführst, gibt es keinen Hintergrunddienst, mit dem geredet wird. Die CLI forkt und exect den Container direkt. Ein kleiner Helfer namens conmon bleibt angehängt, um den Container zu überwachen und seine Logs zu halten, und die OCI-Runtime (runc oder crun) erledigt die Low-Level-Arbeit — aber es gibt keinen privilegierten, dauerhaft laufenden Vermittler dazwischen.

Terminal window


podman run --rm -it alpine sh

Der Befehl sieht identisch zu Docker aus. Unter der Haube ist er grundlegend anders: Vorher lief nichts, und nach dem Beenden des Containers bleibt kein Root-Dienst zurück.

Die praktischen Vorteile:

Kleinere Angriffsfläche. Es gibt keinen Root-Daemon-Socket, den man schützen, leaken oder versehentlich in einen Container mounten könnte.
Saubere Prozessüberwachung. Weil jeder Container nur ein Kindprozess ist, kann dein Init-System ihn direkt beaufsichtigen — kein „Wer startet den Daemon neu, der den Container neu startet“-Rätsel.
Kein Single Point of Failure. Podman neu zu starten oder zu aktualisieren legt laufende Container nicht lahm, wie es ein Daemon-Neustart tun kann.

Der Kompromiss ist real und gehört benannt: Manche Bequemlichkeiten eines Daemons — ein zentraler Event-Stream, immer warmer Zustand, ein Hintergrund-API-Socket — brauchen nun einen anderen Mechanismus. Dazu kommen wir mit systemd.

Rootless: Das Container-Root ist nicht das Host-Root

Das ist die Funktion, die verändert hat, wie ich deploye.

Im Rootless-Modus läuft der gesamte Container-Stack als dein normaler, unprivilegierter Benutzer. Es gibt keinen root-eigenen Daemon und kein setuid-Binary im heißen Pfad. Trotzdem sehen sich Prozesse im Container weiterhin als root (UID 0) und verhalten sich normal — weil Podman einen User-Namespace nutzt, um Identitäten zu mappen.

Das Mapping stammt aus zwei Dateien, /etc/subuid und /etc/subgid, die deinem Benutzer einen Bereich untergeordneter IDs zuweisen:

Terminal window


cat /etc/subuid

# alex:100000:65536

Diese Zeile sagt: Der Benutzer alex besitzt die Host-UIDs 100000 bis 165535 zur Nutzung in Containern. Podman mappt Container-UID 0 auf 100000, Container-UID 1 auf 100001 und so weiter.

Die Sicherheitsfolge ist der ganze Punkt. Bricht ein Angreifer aus einem rootless Container aus, landet er nicht als Host-Root. Er landet als UID 100000 — ein Konto, das auf dem Host nichts besitzt. Der Schaden schrumpft von „die Maschine gehört mir“ auf „ein Namespace gehört mir, der nichts Wichtiges anfassen kann“.

Der Einstieg ist bewusst langweilig:

Terminal window

# kein sudo, kein Daemon-Setup

podman info | grep -i rootless

# rootless: true

podman run -d --name web -p 8080:80 docker.io/library/nginx

curl -s localhost:8080 | head -1

Rootless-Portbindung unter 1024 ist der eine Stolperstein, den die meisten treffen — unprivilegierte Benutzer dürfen niedrige Ports standardmäßig nicht binden, deshalb mappt das Beispiel 8080. Du kannst die Schwelle per sysctl senken, wenn du wirklich :80 brauchst, aber ein hoher Port ist die sauberere Gewohnheit.

`podman unshare`: Dieselben Namespaces, mit Netz

Wer die Von-Hand-Container-Übung gemacht hat, hat unshare --user --mount --pid ... getippt und danach alles sorgfältig selbst verdrahtet. podman unshare gibt dir dieselbe Welt — eine Shell in deinem User-Namespace — aber mit bereits angewandtem UID-Mapping und ohne die scharfen Kanten.

Terminal window


podman unshare cat /proc/self/uid_map

# 0 100000 65536

In dieser Shell bist du Root (UID 0), um Dateien zu bearbeiten, die ein Container erstellt hat. So korrigierst du Besitzrechte auf einem rootless Volume ohne sudo:

Terminal window


podman unshare chown -R 0:0 ./data

Es ist die freundliche, abgesicherte Version des rohen unshare-Tanzes — derselbe Kernel-Mechanismus, weit weniger Chance, den Host zu verletzen.

Pods: Die Idee, die Kubernetes übernommen hat

Podmans Name ist ein Hinweis. Ein Pod ist eine Gruppe von Containern, die sich einen Netzwerk- und IPC-Namespace teilen und sich daher über localhost erreichen — ohne Bridge und ohne veröffentlichte Ports dazwischen.

Terminal window


podman pod create --name app -p 8080:8080

podman run -d --pod app --name api my-api:latest

podman run -d --pod app --name cache docker.io/library/redis

Der api-Container erreicht Redis unter 127.0.0.1:6379, weil sie sich einen Netzwerk-Namespace teilen. Das ist exakt das Modell, das Kubernetes nutzt — kein Zufall. Podman kann sogar Kubernetes-YAML ausgeben und lesen:

Terminal window


podman kube generate app > app.yaml

podman kube play app.yaml

Das macht Podman zu einer wirklich nützlichen lokalen Dev-Schleife für alle, die nach Kubernetes ausliefern: Prototype den Pod auf dem Laptop, übergib dann dasselbe Manifest ans Cluster.

Quadlet: systemd deine Container betreiben lassen

Hier löst sich die „kein Daemon“-Geschichte auf. Dockers Daemon startet deine Container beim Boot und nach Absturz neu. Podman hat dafür keinen Daemon — also delegiert es an das Init-System, dem du ohnehin vertraust: systemd.

Der moderne Weg dafür ist Quadlet. Du schreibst eine kleine deklarative Unit-Datei, legst sie in ~/.config/containers/systemd/, und systemd macht daraus einen voll verwalteten Dienst.

~/.config/containers/systemd/web.container

[Container]

Image=docker.io/library/nginx:latest

PublishPort=8080:80

[Service]

Restart=always

[Install]

WantedBy=default.target

Neu laden und starten wie jeden anderen Dienst:

Terminal window


systemctl --user daemon-reload

systemctl --user start web

Du hast jetzt einen Container, der beim Boot startet, nach Absturz neu startet, in journald loggt und vollständig rootless läuft — beaufsichtigt vom selben Werkzeug, das den Rest deines Systems verwaltet. Kein Hintergrund-Container-Daemon nötig.

Wer Podman schon genutzt hat, erinnert sich vielleicht an podman generate systemd. Quadlet ersetzt es. Der alte Befehl erzeugte brüchige, schwer editierbare Unit-Dateien; Quadlet-Units sind deklarativ, lesbar und der offiziell empfohlene Weg.

Docker vs. Podman auf einen Blick

Docker vs. Podman auf einen Blick| | Docker | Podman |
| --- | --- | --- |
| Architektur | Client + dauerhafter Daemon | Daemonlos (fork/exec + conmon) |
| Standard-Privileg | Historisch Root-Daemon | Rootless standardmäßig |
| Container-Ausbruch landet als | Potenziell Host-Root | Unprivilegierte Host-UID |
| Boot-/Neustart-Aufsicht | Docker-Daemon | systemd (via Quadlet) |
| Pods | Kein natives Konzept | Erstklassig, Kubernetes-kompatibel |
| CLI | docker | podman (gleiche Verben) |
| Kubernetes-YAML | Drittanbieter-Tools | generate kube / play kube eingebaut |

Wo Podman noch nicht Docker ist

Ein ehrlicher Leitfaden benennt die rauen Kanten. Podman ist keine strikte Obermenge von Docker, und ein paar Dinge brauchen Anpassung:

macOS und Windows führen Container in einer Linux-VM aus (podman machine), genau wie Docker Desktop. Der Daemonlos-Vorteil ist ein Linux-Host-Vorteil; auf einem Mac redest du weiter mit einer VM.
Compose funktioniert über podman compose (delegiert an die Compose-Engine) oder podman-compose, und die Abdeckung ist sehr gut — aber es ist Kompatibilität, nicht dieselbe Codebasis, sodass exotische Compose-Dateien überraschen können.
Das Ökosystem aus GUIs, IDE-Integrationen und Drittanbieter-Tools nimmt weiter zuerst Docker an. Podman Desktop hat das meiste davon geschlossen, aber „Docker zuerst, Podman auch“ ist noch der übliche Default.
Eine Hintergrund-API für Tools, die einen Socket pollen wollen, braucht Podmans optionalen Dienst (podman system service) — ironischerweise ein Daemon, den du bewusst einschaltest, statt einer, den du zwingend betreiben musst.

Keiner dieser Punkte ist ein K.-o.-Kriterium auf Linux-Servern oder in CI — genau dort, wo daemonlos und rootless am meisten zahlen.

Namespaces und cgroups sind stark, aber sie bleiben eine Grenze mit geteiltem Kernel. Wenn du wirklich nicht vertrauenswürdigen Code ausführen musst — Multi-Tenant-Workloads, beliebige Nutzer-Einreichungen — greif zu einer stärkeren Isolationsschicht: siehe microVMs: Firecracker vs. gVisor, wo die Container-Grenze endet und eine Hardware- oder Syscall-Sandbox beginnt.

Solltest du wechseln?

Auf einem Linux-Server oder CI-Runner ist der Fall einfach: rootless, daemonloses Podman entfernt ein permanentes root-eigenes Ziel und übergibt die Aufsicht an systemd, das ohnehin läuft. Die CLI ist nah genug an Docker, dass die meiste Muskelerinnerung unverändert überträgt — oft mit einem einzigen alias docker=podman.

Auf einem Entwickler-Laptop — besonders macOS oder Windows — ist der Gewinn kleiner, weil du wieder in einer VM sitzt und dich auf Compose-Kompatibilität stützt. Dort ist „wechsle, wenn es hilft, bleib, wenn nicht“ eine völlig vernünftige Antwort.

Der tiefere Grund, Podman zu lernen, ist nicht das Logo. Es ist, dass Podman die Gestalt eines Containers wieder offensichtlich macht: ein Kindprozess, in einem User-Namespace, beaufsichtigt von Init. Wenn du einmal einen von Hand gebaut und dann Podman dasselbe sauber tun gesehen hast, hören Container auf, Magie zu sein — und dieses Verständnis überdauert, welche CLI du auch tippst.

Podman in 2026: Rootless, Daemonless Containers Without Docker

Aleksei Aleinikov — Sat, 11 Jul 2026 12:00:00 +0000

If you have ever built a container by hand — an overlay mount, a cgroup, a few namespaces, a pivot_root — you already understand Podman better than most Docker users. Podman is essentially those same kernel primitives, wrapped in a friendly CLI, with two of Docker’s oldest design decisions quietly removed: the root daemon and the assumption that you run as root.

New here? The clearest way to feel what a container really is comes from assembling one from scratch — see Build a Tiny Linux Container without Docker. This article picks up where that leaves off: what happens when someone productizes those primitives properly.

This is not a “Docker is dead” piece. Docker is still excellent and still everywhere. But in 2026, podman is the tool I reach for first on servers and CI, and it is worth understanding why rather than just swapping the binary.

Docker’s Two Design Decisions That Aged Badly

Docker popularized containers, but it made two early choices that look heavier today than they did in 2013.

The first is the daemon. The docker command you type is just a thin client; the real work happens in dockerd, a long-running background service. That daemon has historically run as root , and everything you launch is a child of it.

The second is that root posture. For years, running containers meant handing a root-owned daemon control over your process tree, your mounts, and your network.

Neither choice is a bug. But both concentrate risk. A single always-on process running as root is a single, permanent, high-value target — and a single point of failure. If dockerd dies, every container it supervises is affected. If it is compromised, the host is compromised.

Podman removes the daemon entirely.

What “Daemonless” Actually Buys You

When you run podman run, there is no background service to talk to. The CLI forks and execs the container directly. A small helper called conmon stays attached to monitor the container and keep its logs, and the OCI runtime (runc or crun) does the low-level work — but there is no privileged, always-on broker sitting in the middle.

Terminal window


podman run --rm -it alpine sh

That command looks identical to Docker. Under the hood it is fundamentally different: nothing was running before you typed it, and nothing lingers as a root service after the container exits.

The practical payoffs:

A smaller attack surface. There is no root daemon socket to protect, leak, or bind-mount into a container by accident.
Clean process supervision. Because each container is just a child process, your init system can supervise it directly — no “who restarts the daemon that restarts the container” puzzle.
No single point of failure. Restarting or upgrading Podman does not take down running containers the way bouncing a daemon can.

The trade-off is real and worth naming: some conveniences that a daemon provides — a central event stream, always-warm state, a background API socket — now need a different mechanism. We will get to that with systemd.

Rootless: The Container Root Is Not Host Root

This is the feature that changed how I deploy.

In rootless mode, the entire container stack runs as your normal, unprivileged user. There is no root-owned daemon and no setuid binary in the hot path. Yet inside the container, processes still see themselves as root (UID 0) and behave normally — because Podman uses a user namespace to map identities.

The mapping comes from two files, /etc/subuid and /etc/subgid, which grant your user a range of subordinate IDs:

Terminal window


cat /etc/subuid

# alex:100000:65536

That line says: the user alex owns host UIDs 100000 through 165535 for use inside containers. Podman maps container UID 0 to 100000, container UID 1 to 100001, and so on.

The security consequence is the whole point. If an attacker breaks out of a rootless container, they do not land as host root. They land as UID 100000 — an account that owns nothing on the host. The blast radius shrinks from “own the machine” to “own a namespace that can’t touch anything important.”

Getting started is deliberately boring:

Terminal window

# no sudo, no daemon setup

podman info | grep -i rootless

# rootless: true

podman run -d --name web -p 8080:80 docker.io/library/nginx

curl -s localhost:8080 | head -1

Rootless port binding below 1024 is the one gotcha most people hit — unprivileged users cannot bind low ports by default, which is why the example maps 8080. You can lower the threshold with a sysctl if you truly need :80, but mapping a high port is the cleaner habit.

`podman unshare`: The Same Namespaces, With a Net

If you have done the hand-built-container exercise, you have typed unshare --user --mount --pid ... and then carefully wired up everything yourself. podman unshare gives you that same world — a shell inside your user namespace — but with the UID mapping already applied and the sharp edges filed off.

Terminal window


podman unshare cat /proc/self/uid_map

# 0 100000 65536

Inside that shell, you are root (UID 0) for the purpose of manipulating files a container created. This is how you fix ownership on a rootless volume without sudo:

Terminal window


podman unshare chown -R 0:0 ./data

It is the friendly, guard-railed version of the raw unshare dance — same kernel mechanism, far less chance of hurting the host.

Pods: The Idea Kubernetes Borrowed

Podman’s name is a hint. A pod is a group of containers that share a network and IPC namespace, so they talk to each other over localhost with no bridge and no published ports between them.

Terminal window


podman pod create --name app -p 8080:8080

podman run -d --pod app --name api my-api:latest

podman run -d --pod app --name cache docker.io/library/redis

The api container reaches Redis at 127.0.0.1:6379 because they share one network namespace. This is the exact model Kubernetes uses — which is not a coincidence. Podman can even emit and consume Kubernetes YAML:

Terminal window


podman kube generate app > app.yaml

podman kube play app.yaml

That makes Podman a genuinely useful local dev loop for people who ship to Kubernetes: prototype the pod on your laptop, then hand the same manifest to the cluster.

Quadlet: Let systemd Run Your Containers

Here is where the “no daemon” story resolves. Docker’s daemon restarts your containers on boot and on crash. Podman does not have a daemon to do that — so it delegates to the init system you already trust: systemd.

The modern way to wire this up is Quadlet. You write a small declarative unit file, drop it in ~/.config/containers/systemd/, and systemd turns it into a fully managed service.

~/.config/containers/systemd/web.container

[Container]

Image=docker.io/library/nginx:latest

PublishPort=8080:80

[Service]

Restart=always

[Install]

WantedBy=default.target

Reload and start it like any other service:

Terminal window


systemctl --user daemon-reload

systemctl --user start web

You now have a container that starts on boot, restarts on crash, logs to journald, and runs entirely rootless — supervised by the same tool that manages the rest of your system. No background container daemon required.

If you have used Podman before, you might remember podman generate systemd. Quadlet replaces it. The old command generated brittle, hard-to-edit unit files; Quadlet units are declarative, readable, and the officially recommended path.

Docker vs Podman at a Glance

	Docker	Podman
Architecture	Client + long-running daemon	Daemonless (fork/exec + conmon)
Default privilege	Historically root daemon	Rootless by default
Container escape lands as	Potentially host root	Unprivileged host UID
Boot / restart supervision	Docker daemon	systemd (via Quadlet)
Pods	No native concept	First-class, Kubernetes-compatible
CLI	`docker`	`podman` (same verbs)
Kubernetes YAML	Third-party tools	`generate kube` / `play kube` built in

Where Podman Still Isn’t Docker

An honest guide names the rough edges. Podman is not a strict superset of Docker, and a few things need adjusting:

macOS and Windows run containers inside a Linux VM (podman machine), exactly like Docker Desktop does. The daemonless benefit is a Linux-host benefit; on a Mac you are still talking to a VM.
Compose works through podman compose (delegating to the Compose engine) or podman-compose, and coverage is very good — but it is compatibility, not the same codebase, so exotic Compose files can surprise you.
The ecosystem of GUIs, IDE integrations, and third-party tooling still assumes Docker first. Podman Desktop has closed most of this gap, but “Docker first, Podman also” is still the common default.
A background API for tools that expect to poll a socket needs Podman’s optional service (podman system service) — which, ironically, is a daemon you opt into rather than one you are forced to run.

None of these are dealbreakers on Linux servers or CI, which is exactly where daemonless and rootless pay off most.

Namespaces and cgroups are strong, but they are still a shared-kernel boundary. When you need to run genuinely untrusted code — multi-tenant workloads, arbitrary user submissions — reach for a stronger isolation layer: see microVMs: Firecracker vs gVisor for where the container boundary ends and a hardware or syscall sandbox begins.

Should You Switch?

On a Linux server or a CI runner, the case is easy: rootless, daemonless Podman removes a permanent root-owned target and hands supervision to systemd, which is already running. The CLI is close enough to Docker that most muscle memory transfers untouched, often with a single alias docker=podman.

On a developer laptop — especially macOS or Windows — the win is smaller, because you are back inside a VM and leaning on Compose compatibility. There, “switch if it helps, stay if it doesn’t” is a perfectly sane answer.

The deeper reason to learn Podman is not the logo. It is that Podman makes the shape of a container obvious again: a child process, in a user namespace, supervised by init. Once you have built one by hand and then watched Podman do the same thing cleanly, containers stop being magic — and that understanding outlasts whichever CLI you happen to type.

Originally published at alekseialeinikov.com