DEV Community: Aleksei Aleinikov

vLLM vs Ollama: Which Inference Server You Actually Need in 2026

Aleksei Aleinikov — Tue, 15 Sep 2026 12:00:00 +0000

ollama run llama3 gets a model answering questions in about thirty seconds, on a laptop, with zero configuration. That is a genuinely remarkable thing to be able to say about a large language model in 2026, and it is also completely irrelevant to a different question: what happens when 200 people hit that same model at once?

Those are two different engineering problems, and most “vLLM vs Ollama” content collapses them into one, as if the two projects were competing for the same job. They aren’t. This article covers what each one actually optimizes for, the two ideas — PagedAttention and continuous batching — that explain the entire performance gap under load, and a straight answer to which one you need for the workload you actually have.

What Ollama Actually Is

Ollama is a thin, well-designed operational layer over llama.cpp — Georgi Gerganov’s C/C++ inference engine, the same engine that made running LLaMA-family models on ordinary laptops practical in the first place. Ollama adds the parts that make it feel like a product rather than a research project: a CLI (ollama run llama3), a REST API, a model library of pre-quantized GGUF files you can pull by name, and a Modelfile format for customizing prompts and parameters.

No batching queue exists to configure — which is exactly why there is nothing to tune when a second request shows up.

That simplicity is the entire point, not a limitation to apologize for. llama.cpp can offload as many transformer layers to GPU as will fit (Metal on Apple Silicon, CUDA, ROCm, Vulkan) and run the rest on CPU, which is why Ollama runs acceptably on hardware that has no business running a modern LLM at all. It was designed around one machine, one user at a time, and it does that job better than almost anything else available.

What it was not designed around is a request scheduler. Ollama does queue concurrent requests, but there is no mechanism comparable to what’s described next — no iteration-level batching, no purpose-built memory manager for many simultaneous KV caches. That isn’t a bug; the entire design brief was “run a model with essentially no setup,” and every one of those decisions is correct for that brief.

What vLLM Actually Is

vLLM comes out of a research paper, not a product roadmap: “Efficient Memory Management for Large Language Model Serving with PagedAttention” (Kwon et al., UC Berkeley, published at SOSP 2023). The paper’s headline claim — 2-4x higher throughput than serving systems available at the time, such as FasterTransformer and Orca, at the same latency — came from solving one specific, unglamorous problem: GPU memory was being wasted on the KV cache.

PagedAttention is the fix. Every token generated needs the attention mechanism to reference a growing cache of key/value tensors for everything generated so far. Naive serving reserves one contiguous memory block per request, sized for the worst case, which means memory sits unused whenever the real output is shorter — and that unused memory can’t be reassigned to a different request without stopping and reshuffling everything. PagedAttention borrows the idea straight from operating-system virtual memory: split the KV cache into small, fixed-size blocks, allocate them on demand, and reference them indirectly through a block table. Waste shrinks to almost nothing, and — a secondary benefit that matters for things like parallel sampling or beam search — identical prefixes across requests can share the same physical blocks via copy-on-write.

Static batching waits for the slowest member of the batch. Continuous batching never lets a freed slot sit idle.

The second piece is continuous batching — sometimes called iteration-level scheduling, an idea introduced by Orca (Yu et al., OSDI 2022) before vLLM productionized it at scale. Older serving systems form a batch, run every request in it to completion, and only then start the next batch — so a single long-running request holds the whole GPU batch hostage while shorter requests finish and their slots sit empty. Continuous batching schedules at the level of individual generation steps: the instant one sequence in a batch finishes, its slot is handed to the next waiting request, on the very next iteration. The GPU stays saturated instead of idling on stragglers.

Put those two together and the result isn’t “vLLM makes the model smarter or faster per token” — it’s “vLLM keeps far more concurrent requests in flight on the same hardware, with less memory wasted and less GPU sitting idle.” That is a throughput story, and it is the entire reason vLLM exists.

Getting Started With Each

Neither of these takes more than a few minutes to try, and running both side by side is the fastest way to feel the difference this article describes rather than just read about it.

Ollama — already shown above, one command pulls and runs a quantized model:

ollama pull llama3
ollama run llama3 "Explain PagedAttention in one sentence"

vLLM exposes an OpenAI-compatible API server out of the box:

pip install vllm
vllm serve mistralai/Mistral-7B-Instruct-v0.2
# now POST to http://localhost:8000/v1/chat/completions

That single vllm serve command already gives you continuous batching and PagedAttention — there’s no separate flag to turn them on; they’re the engine’s default request path, not an opt-in mode. If you’re wiring the result into agent tooling — MCP servers or a coding assistant like the ones compared in AI Coding Agents in 2026 — that OpenAI-compatible endpoint is exactly what makes either engine a drop-in replacement for a hosted API, without touching client code.

The Real Trade-off

Neither engine is “better.” They’re optimized for different points on the same curve, and the decision comes down to one question: is your bottleneck the number of concurrent requests, or the operational complexity of running a GPU fleet?

Most serious projects don't pick one forever — they start on Ollama and graduate to vLLM once real concurrency shows up.

Prototyping and internal tools with a handful of users — Ollama wins on setup cost alone. There is no batching behavior to reason about because there is essentially no contention to manage.
A customer-facing API serving many concurrent users — this is the scenario PagedAttention and continuous batching exist for. The gap between the two engines widens as concurrency rises; it is close to invisible at 1 request and large at 50.
A multi-GPU fleet where cost per token matters — vLLM supports tensor and pipeline parallelism to spread a large model across GPUs, often on a managed Kubernetes GPU node pool (see GKE Autopilot vs Standard for how that scheduling choice plays out for GPU workloads specifically), and higher achievable GPU utilization translates directly into fewer GPUs needed for the same load.
Edge devices or environments with no dedicated GPU ops team — Ollama’s CPU/GPU-offload flexibility and minimal footprint are the right fit; vLLM’s value proposition assumes GPU infrastructure you’re actively managing.

Quantization is where the two projects diverge in a way worth knowing before you commit to one. Ollama’s GGUF models (K-quants like Q4_K_M) are built for the CPU/GPU-split use case and are covered in depth in Quantization Explained: How to Run a 70B Model on Consumer Hardware — that article’s VRAM math applies directly to sizing an Ollama deployment. vLLM instead leans on GPU-first formats such as AWQ and GPTQ, which tend to be faster when the model fits entirely in VRAM, plus growing FP8 support on newer hardware. If you’re planning to serve a model you’re currently only running locally, that quantization format is one of the first decisions the migration forces on you.

Who Else Is in This Space

vLLM and Ollama are the two names that come up most, but they aren’t the only options, and it’s worth knowing where the others sit:

Text Generation Inference (TGI), from Hugging Face, targets the same production-throughput niche as vLLM with its own continuous-batching implementation and a Rust-based serving core. A reasonable pick if your stack already lives in the Hugging Face ecosystem.
SGLang , from the same research lineage as vLLM, adds structured generation and constrained decoding on top of a similarly optimized backend — relevant if your workload leans heavily on structured output or agentic tool-calling rather than open-ended chat.
LM Studio and llama.cpp’s own bundled server sit closer to Ollama’s niche: local-first, single-user-oriented, with LM Studio adding a desktop GUI on top.

None of these change the underlying decision. They’re variations on the same two poles — optimized for concurrent throughput, or optimized for zero-friction local use — and the honest answer to “which one” starts with being honest about which of those two problems you actually have.

The Bottom Line

ollama run llama3 and a production inference endpoint serving 200 people are not the same engineering problem wearing different clothes — they’re genuinely different problems, and conflating them is why “vLLM vs Ollama” arguments so often talk past each other. Ollama’s entire value is refusing to force you to think about batching, scheduling, or GPU memory layout, and for a huge share of real use — prototyping, internal tools, small teams, edge deployment — that’s exactly the right trade to make. vLLM’s entire value is PagedAttention and continuous batching turning GPU memory and scheduling into something you actively manage, because at real concurrency that management is where the throughput comes from.

Most projects that matter end up using both, just not at the same time: Ollama while you’re figuring out whether the product works at all, vLLM once concurrent users are the thing standing between you and the next order of magnitude of scale. Picking based on which stage you’re actually in, rather than which name sounds more serious, is the whole decision.

Originally published at alekseialeinikov.com

vLLM vs. Ollama: Welchen Inference-Server Sie 2026 wirklich brauchen

Aleksei Aleinikov — Tue, 15 Sep 2026 12:00:00 +0000

ollama run llama3 bringt in rund dreißig Sekunden ein antwortendes Modell — auf einem Laptop, ohne jede Konfiguration. Das ist 2026 eine bemerkenswerte Sache, die man über ein großes Sprachmodell sagen kann, und gleichzeitig für eine andere Frage völlig irrelevant: Was passiert, wenn 200 Menschen dasselbe Modell gleichzeitig anfragen?

Das sind zwei verschiedene Engineering-Probleme, und die meisten “vLLM vs. Ollama”-Inhalte werfen sie in einen Topf, als würden beide Projekte um denselben Job konkurrieren. Tun sie nicht. Dieser Artikel behandelt, worauf jedes der beiden tatsächlich optimiert ist, die zwei Ideen — PagedAttention und Continuous Batching —, die die gesamte Performance-Lücke unter Last erklären, und eine klare Antwort darauf, welches Sie für die Last brauchen, die Sie tatsächlich haben.

Was Ollama wirklich ist

Ollama ist eine schlanke, gut gestaltete Betriebsschicht über llama.cpp — Georgi Gerganovs C/C++-Inferenz-Engine, dieselbe Engine, die das Ausführen von LLaMA-Familien-Modellen auf gewöhnlichen Laptops überhaupt erst praktikabel gemacht hat. Ollama fügt die Teile hinzu, die es wie ein fertiges Produkt statt ein Forschungsprojekt wirken lassen: eine CLI (ollama run llama3), eine REST-API, eine Modellbibliothek vorquantisierter GGUF -Dateien, die per Name gezogen werden können, und ein Modelfile-Format zum Anpassen von Prompts und Parametern.

Es gibt keine Batching-Warteschlange zu konfigurieren — genau deshalb gibt es nichts zu tunen, sobald eine zweite Anfrage eintrifft.

Diese Einfachheit ist der ganze Sinn der Sache, keine Einschränkung, für die man sich entschuldigen müsste. llama.cpp kann so viele Transformer-Layer wie möglich auf die GPU auslagern (Metal auf Apple Silicon, CUDA, ROCm, Vulkan) und den Rest auf der CPU ausführen — deshalb läuft Ollama akzeptabel auf Hardware, die eigentlich gar kein modernes LLM ausführen sollte. Es wurde für eine Maschine, einen Nutzer zur Zeit entworfen, und diese Aufgabe erledigt es besser als fast alles andere Verfügbare.

Wofür es nicht entworfen wurde, ist ein Anfrage-Scheduler. Ollama reiht gleichzeitige Anfragen durchaus in eine Warteschlange ein, aber es gibt keinen Mechanismus vergleichbar mit dem, was als Nächstes beschrieben wird — kein Iteration-Level-Batching, keinen zweckgebauten Speichermanager für viele gleichzeitige KV-Caches. Das ist kein Fehler; das gesamte Design-Briefing lautete “ein Modell mit praktisch keinem Setup laufen lassen”, und jede dieser Entscheidungen ist für genau dieses Briefing richtig.

Was vLLM wirklich ist

vLLM stammt aus einem Forschungspapier, nicht aus einer Produkt-Roadmap: “Efficient Memory Management for Large Language Model Serving with PagedAttention” (Kwon et al., UC Berkeley, veröffentlicht auf der SOSP 2023). Die Kernaussage des Papers — 2- bis 4-fach höherer Durchsatz als damals verfügbare Serving-Systeme wie FasterTransformer und Orca, bei gleicher Latenz — kam aus der Lösung eines konkreten, unglamourösen Problems: GPU-Speicher wurde für den KV-Cache verschwendet.

PagedAttention ist die Lösung. Jedes generierte Token braucht den Aufmerksamkeitsmechanismus, um auf einen wachsenden Cache von Key/Value-Tensoren für alles bisher Generierte zurückzugreifen. Naives Serving reserviert pro Anfrage einen zusammenhängenden Speicherblock, dimensioniert für den schlechtesten Fall — das heißt, Speicher bleibt ungenutzt, sobald die tatsächliche Ausgabe kürzer ist, und dieser ungenutzte Speicher kann keiner anderen Anfrage zugewiesen werden, ohne alles anzuhalten und neu zu ordnen. PagedAttention übernimmt die Idee direkt aus dem virtuellen Speicher von Betriebssystemen: den KV-Cache in kleine, feste Blöcke aufteilen, sie bei Bedarf zuweisen und indirekt über eine Blocktabelle referenzieren. Die Verschwendung schrumpft auf nahezu null, und — ein Nebeneffekt, der etwa bei parallelem Sampling oder Beam Search zählt — identische Präfixe über mehrere Anfragen hinweg können sich per Copy-on-Write dieselben physischen Blöcke teilen.

Statisches Batching wartet auf das langsamste Mitglied des Batches. Continuous Batching lässt einen frei gewordenen Slot nie im Leerlauf.

Das zweite Element ist Continuous Batching — manchmal Iteration-Level-Scheduling genannt, eine Idee, die Orca (Yu et al., OSDI 2022) einführte, bevor vLLM sie im großen Maßstab produktionsreif machte. Ältere Serving-Systeme bilden einen Batch, führen jede Anfrage darin bis zum Abschluss aus und starten erst danach den nächsten Batch — eine einzelne lang laufende Anfrage hält damit den gesamten GPU-Batch als Geisel, während kürzere Anfragen fertig sind und ihre Slots leer bleiben. Continuous Batching plant auf Ebene einzelner Generierungsschritte: Sobald eine Sequenz in einem Batch fertig ist, wird ihr Slot in der nächsten Iteration sofort der nächsten wartenden Anfrage übergeben. Die GPU bleibt ausgelastet, statt auf Nachzügler zu warten.

Kombiniert man beides, lautet das Ergebnis nicht “vLLM macht das Modell klüger oder pro Token schneller” — sondern “vLLM hält deutlich mehr gleichzeitige Anfragen auf derselben Hardware in Bearbeitung, mit weniger verschwendetem Speicher und weniger GPU-Leerlauf.” Das ist eine Durchsatz-Geschichte, und das ist der gesamte Grund, warum es vLLM gibt.

Erste Schritte mit beiden

Keines von beiden braucht mehr als ein paar Minuten zum Ausprobieren, und beide nebeneinander laufen zu lassen ist der schnellste Weg, den Unterschied aus diesem Artikel selbst zu spüren statt nur darüber zu lesen.

Ollama — bereits oben gezeigt, ein Befehl zieht ein quantisiertes Modell und startet es:

ollama pull llama3
ollama run llama3 "Erkläre PagedAttention in einem Satz"

vLLM bringt von Haus aus einen OpenAI-kompatiblen API-Server mit:

pip install vllm
vllm serve mistralai/Mistral-7B-Instruct-v0.2
# jetzt POST an http://localhost:8000/v1/chat/completions

Schon dieser einzelne vllm serve-Befehl liefert Continuous Batching und PagedAttention mit — es gibt kein separates Flag, um sie einzuschalten; sie sind der Standard-Anfragepfad der Engine, kein Opt-in-Modus. Wer das Ergebnis in Agenten-Tooling einbindet — MCP-Server oder einen Coding-Assistenten wie die in KI-Coding-Agents 2026 verglichenen — profitiert genau von diesem OpenAI-kompatiblen Endpunkt: Er macht beide Engines zu einem Drop-in-Ersatz für eine gehostete API, ohne Client-Code anzufassen.

Der eigentliche Trade-off

Keine der beiden Engines ist “besser”. Sie sind für unterschiedliche Punkte auf derselben Kurve optimiert, und die Entscheidung läuft auf eine Frage hinaus: Ist Ihr Engpass die Anzahl gleichzeitiger Anfragen, oder die operative Komplexität, eine GPU-Flotte zu betreiben?

Die meisten ernsthaften Projekte entscheiden sich nicht für immer — sie starten mit Ollama und wechseln zu vLLM, sobald echte Nebenläufigkeit auftaucht.

Prototyping und interne Tools mit einer Handvoll Nutzer — Ollama gewinnt allein durch den Setup-Aufwand. Es gibt praktisch kein Konkurrenzverhalten zu managen, also gibt es auch kein Batching-Verhalten, über das man nachdenken müsste.
Eine kundenseitige API mit vielen gleichzeitigen Nutzern — genau für dieses Szenario existieren PagedAttention und Continuous Batching. Die Lücke zwischen beiden Engines wächst mit steigender Nebenläufigkeit; bei einer Anfrage ist sie kaum sichtbar, bei fünfzig groß.
Eine Multi-GPU-Flotte, bei der die Kosten pro Token zählen — vLLM unterstützt Tensor- und Pipeline-Parallelismus, um ein großes Modell über mehrere GPUs zu verteilen, oft auf einem verwalteten Kubernetes-GPU-Node-Pool (siehe GKE Autopilot vs. Standard dafür, wie sich diese Scheduling-Entscheidung speziell bei GPU-Workloads auswirkt), und höhere erreichbare GPU-Auslastung bedeutet direkt weniger benötigte GPUs für dieselbe Last.
Edge-Geräte oder Umgebungen ohne dediziertes GPU-Ops-Team — Ollamas Flexibilität beim CPU/GPU-Split und der geringe Footprint sind hier die richtige Wahl; vLLMs Wertversprechen setzt GPU-Infrastruktur voraus, die aktiv betrieben wird.

Die Quantisierung ist der Punkt, an dem sich die beiden Projekte auf eine Weise unterscheiden, die man kennen sollte, bevor man sich festlegt. Ollamas GGUF-Modelle (K-Quants wie Q4_K_M) sind für den CPU/GPU-Split-Anwendungsfall gebaut und werden ausführlich in Quantisierung erklärt: 70B-Modell auf normaler Hardware behandelt — die dortige VRAM-Rechnung gilt direkt für die Dimensionierung eines Ollama-Deployments. vLLM setzt stattdessen eher auf GPU-first-Formate wie AWQ und GPTQ, die tendenziell schneller sind, wenn das Modell vollständig in den VRAM passt, plus wachsende FP8-Unterstützung auf neuerer Hardware. Wer plant, ein bisher nur lokal laufendes Modell zu servieren, stößt auf genau diese Formatfrage als eine der ersten Entscheidungen der Migration.

Wer sonst noch in diesem Feld mitspielt

vLLM und Ollama sind die beiden am häufigsten genannten Namen, aber nicht die einzigen Optionen, und es lohnt sich zu wissen, wo die anderen stehen:

Text Generation Inference (TGI) von Hugging Face zielt mit eigener Continuous-Batching-Implementierung und einem Rust-basierten Serving-Kern auf dieselbe Produktions-Durchsatz-Nische wie vLLM. Eine sinnvolle Wahl, wenn der eigene Stack ohnehin im Hugging-Face-Ökosystem lebt.
SGLang , aus derselben Forschungslinie wie vLLM, ergänzt strukturierte Generierung und Constrained Decoding auf einem ähnlich optimierten Backend — relevant, wenn die Last stark auf strukturierter Ausgabe oder agentischem Tool-Calling statt offenem Chat liegt.
LM Studio und llama.cpps eigener mitgelieferter Server liegen näher an Ollamas Nische: lokal-first, auf Einzelnutzer ausgerichtet, wobei LM Studio zusätzlich eine Desktop-GUI mitbringt.

Keine dieser Optionen ändert die zugrunde liegende Entscheidung. Es sind Variationen derselben zwei Pole — optimiert für gleichzeitigen Durchsatz oder optimiert für reibungslose lokale Nutzung —, und die ehrliche Antwort auf “welches von beiden” beginnt damit, ehrlich zu sein, welches der beiden Probleme man tatsächlich hat.

Fazit

ollama run llama3 und ein Produktions-Inference-Endpunkt für 200 Nutzer sind nicht dasselbe Engineering-Problem in anderem Gewand — es sind wirklich unterschiedliche Probleme, und sie zu vermischen ist der Grund, warum “vLLM vs. Ollama”-Debatten so oft aneinander vorbeireden. Ollamas gesamter Wert liegt darin, dass man nicht über Batching, Scheduling oder GPU-Speicherlayout nachdenken muss, und für einen großen Teil der realen Nutzung — Prototyping, interne Tools, kleine Teams, Edge-Deployment — ist das genau der richtige Tausch. vLLMs gesamter Wert liegt darin, dass PagedAttention und Continuous Batching GPU-Speicher und Scheduling zu etwas machen, das man aktiv verwaltet, weil bei echter Nebenläufigkeit genau dort der Durchsatz herkommt.

Die meisten Projekte, die zählen, nutzen am Ende beides — nur nicht gleichzeitig: Ollama, solange man herausfindet, ob das Produkt überhaupt funktioniert, vLLM, sobald gleichzeitige Nutzer das sind, was zwischen einem und der nächsten Größenordnung an Skalierung steht. Die Wahl danach zu treffen, in welcher Phase man tatsächlich ist, statt danach, welcher Name ernsthafter klingt, ist die ganze Entscheidung.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Passkeys vs Passwords: How WebAuthn Actually Works, Who Builds What, and How to Roll It Out

Aleksei Aleinikov — Mon, 14 Sep 2026 12:00:00 +0000

A password is a secret two parties have to keep at the same time: you, and every server you ever typed it into. That is the entire design flaw. It does not matter how long or random the string is — if it can be typed, it can be phished, and if it is stored anywhere else, it can be breached and reused.

A passkey is not a stronger secret. It is not a secret at all, on the server side. It is one half of a key pair, and the half the server gets is mathematically useless to an attacker.

That distinction gets lost in most “turn on passkeys” marketing copy, which is a shame, because the protocol underneath is genuinely elegant and worth understanding at the message level — especially if you are the one who has to implement it. This article covers how the two core WebAuthn ceremonies actually work, what “synced” versus “device-bound” really means, who ships passkeys today and what they each hold, how to implement support without breaking account recovery, and an honest read on where this is still rough.

What a Passkey Actually Is

Strip away the product framing and a passkey is a WebAuthn public-key credential, and WebAuthn is a W3C standard that, paired with the FIDO Alliance’s CTAP2 protocol, forms FIDO2. Three parties are involved in every ceremony, and it is worth naming them precisely because the vendor documentation rarely does:

The relying party (RP) — the website or app that wants to authenticate you. This is your server. It never sees, stores, or transmits a private key at any point.
The client — the browser or OS, which mediates between the RP’s JavaScript (navigator.credentials) and the authenticator, and — this part matters — independently verifies the origin before anything is signed.
The authenticator — the thing that actually holds the private key: a phone’s secure enclave, a laptop’s TPM, or a roaming hardware key (YubiKey, Titan). It never talks to the network directly; it only talks to the client over CTAP2.

A password login has two parties and one shared secret. A passkey login has three parties and zero shared secrets — the public key that sits on your server is, by definition, safe to leak. That is the whole point, and everything else in this article is detail on how that property is achieved and where it leaks back into “well, actually, it’s complicated.”

How Registration Works

“Adding a passkey” to an account is a WebAuthn registration ceremony (navigator.credentials.create()). Six messages, three parties, and the private key touches exactly one of them.

The private key is generated in step 3 and never appears in any of the other five messages.

A few details that matter once you actually implement this:

The challenge is single-use and server-generated. It exists purely to prevent replay — the signature the authenticator eventually produces is only valid for that exact challenge, so a captured registration response cannot be replayed against a different session.
Attestation is optional and mostly not worth requiring. The authenticator can cryptographically prove what make/model it is (attestation: "direct"), but doing so leaks device fingerprinting information, requires you to maintain a metadata trust store, and most consumer flows use attestation: "none". Reach for direct attestation only in regulated/enterprise contexts where you must enforce a specific hardware allow-list.
Discoverable (resident) credentials are what make “passkey” different from old-style WebAuthn 2FA. Setting residentKey: "required" tells the authenticator to store the credential such that it can be found without the RP sending a username first — that is what powers the “sign in with a passkey” account picker instead of “type your username, then use your security key.”
The credential ID and public key are what you store — never anything else. A minimal schema is (user_id, credential_id, public_key_cose, sign_count, transports, created_at). sign_count is a legacy anti-cloning counter from single-device authenticators; most synced passkeys report it as a flat 0, so treat it as advisory, not a security boundary.

How Login Works

Logging in is the authentication ceremony (navigator.credentials.get()), and it is the mirror image of registration — a challenge goes out, a signature comes back, and this time the server has something to check the signature against.

Same user, same tap, two different origins — the browser decides the outcome before a signature is ever produced.

The detail that actually delivers the anti-phishing property is easy to skim past: the client — not the user — checks that the origin requesting the assertion matches the origin the credential was registered to. A pixel-perfect clone of your login page hosted on a look-alike domain can render an identical navigator.credentials.get() call, and the browser will simply refuse to produce a valid signature for it. There is no “type the password into the wrong box” failure mode, because there is no box.

Two implementation notes:

Conditional UI (autofill) is what makes this feel like a password field. Calling get() with mediation: "conditional" on page load lets the browser surface saved passkeys in the normal username autofill dropdown, so the login form still looks like a plain input — it just also offers a one-tap passkey option. Skipping this is the single biggest reason “we added passkeys” rollouts get low adoption: users never see the option because it is hidden behind a separate button.
User verification (userVerification: "preferred" vs "required") decides whether a bare “is a device present” check is enough, or whether the local biometric/PIN unlock is mandatory. For anything beyond a trivial account, require it — otherwise an unlocked, unattended device becomes a full authentication bypass.

Who Actually Holds the Private Key

Here is where the “just use passkeys” pitch gets less simple, and it is worth being precise about it because it changes your account-recovery design.

Four sync fabrics, one cross-ecosystem fallback — and it is a transport bridge, not a credential-migration path.

Synced passkeys live inside a platform vendor’s end-to-end-encrypted cloud and follow the user’s account, not their device:

Apple syncs through iCloud Keychain across macOS, iOS, iPadOS and visionOS, gated behind the Apple ID and (for viewing) device passcode.
Google syncs through Google Password Manager across Android, ChromeOS and Chrome on any OS, tied to the Google account.
Microsoft anchors platform passkeys to Windows Hello and the Microsoft account; on the workforce side, Entra ID adds policy control over which authenticators are acceptable.
1Password, Bitwarden, Dashlane and other password managers sync passkeys through their own vault, cross-platform by design — the whole point of a password manager is not being locked to one OS vendor.

Device-bound passkeys are the other model: the private key is generated inside one specific piece of hardware and is never exported, backed up, or synced anywhere, by design. This is the default (and often the only option) for FIDO2 hardware security keys, and it is a mode some enterprise MDM policies force even for platform authenticators, trading recoverability for a much narrower attack surface — the key can only ever be exfiltrated by physically compromising that one device.

What does not yet work cleanly: moving a synced passkey from one vendor’s fabric to another. A passkey created in iCloud Keychain does not appear in Google Password Manager. The practical bridge across ecosystems is FIDO2 CTAP2 hybrid transport — scan a QR code on a laptop, approve on a phone over Bluetooth, and that phone acts as a one-time roaming authenticator for that browser session. It is a genuinely useful fallback for “I’m on a friend’s computer” or a platform gap, but the private key still never leaves the phone, and it is not a migration tool. The FIDO Alliance’s Credential Exchange Protocol (CXP) is the standardization effort aimed at proper cross-vendor export/import; as of 2026 it is still early.

Who Offers What in 2026

For most teams the real decision is not “should we implement raw WebAuthn,” it is “which layer do we implement it at.” Here is the landscape, roughly ordered from consumer platform down to identity infrastructure:

Provider	What it is	Passkey role
Apple, Google, Microsoft	OS / browser platforms	Ship the authenticator + sync fabric (iCloud Keychain, Google Password Manager, Windows Hello) that end users already have on their device
1Password, Bitwarden, Dashlane	Password managers	Store and sync passkeys across any OS/browser as a vault item, independent of any single platform vendor
Okta, Auth0, Microsoft Entra ID, Ping Identity	Enterprise IdPs	Let you turn on passkey sign-in for your workforce or customer app without touching WebAuthn code directly — the IdP is the relying party
Keycloak, Authentik	Self-hosted IdPs	Same idea, open source — see Keycloak vs Authentik if you are choosing between them; both support WebAuthn as a self-service credential
AWS Cognito, Clerk	Managed app-auth platforms	Ship WebAuthn/passkey sign-in as a built-in configuration option — no custom ceremony code required
SimpleWebAuthn, `webauthn4j`, `go-webauthn/webauthn`, py_webauthn	Open-source relying-party libraries	What you reach for if you are building the identity layer yourself — parse/verify the ceremony without hand-rolling CBOR/COSE
Yubico, Google (Titan), SoloKeys	Hardware security keys	Device-bound roaming authenticators for workforce/high-assurance accounts, independent of any OS sync fabric

The honest read: if your product already sits behind Okta, Auth0, Entra ID, or a self-hosted Keycloak/Authentik instance, turning on passkeys is a configuration change, not an engineering project. The IdP is already the relying party; you are enabling a credential type it already knows how to handle. The engineering project described below is for the case where you are the relying party — you run your own auth stack and want to add passkeys as a first-class credential.

How to Actually Implement It

Assume you are the relying party. The shape of the work:

1. Pick a server library — do not parse CBOR/COSE by hand. The WebAuthn wire format (attestation objects, COSE public keys, CBOR-encoded authenticator data) is exactly the kind of thing that is easy to get subtly wrong in a way that only shows up as a security bug later. Use a maintained library for your stack: SimpleWebAuthn (TypeScript/Node, also ships a browser helper), webauthn4j (Java), Fido2NetLib (.NET), go-webauthn/webauthn (Go, the actively maintained fork of the original Duo Labs library), py_webauthn (Python), webauthn-rs (Rust). All of them expose roughly the same two functions you need: “generate registration/authentication options” and “verify registration/authentication response.”

2. Get the Relying Party ID right before anything else. The rpID is the domain the credential is bound to (no scheme, no port) — example.com, not https://example.com or app.example.com if you also need it valid on www.example.com. Get this wrong and passkeys registered in one environment silently fail to authenticate in another (a very common “works locally, breaks in staging” bug, because localhost and your staging subdomain are different RP IDs).

3. Require resident keys and conditional UI from day one , not as a later enhancement — a passkey rollout without the autofill-picker UX gets a fraction of the adoption, because users never discover it is an option.

4. Design account recovery before you ship, not after the first support ticket. This is the part every “add passkeys” tutorial skips. At minimum:

Let users register more than one authenticator (phone + a backup security key, or two synced devices) — a single point of failure with an unrecoverable credential is worse than a password.
Keep a fallback path (email magic link, backup codes generated at enrollment, or a human-verified support flow) for the case where every registered authenticator is lost.
Decide explicitly whether you allow downgrading to a password/OTP fallback per-account, and if so, gate it behind extra friction — it is the path an attacker will try first once passkeys make direct credential theft useless.

5. Migrate gradually, not as a hard cutover. Add passkeys as an additional credential option alongside existing password/MFA, prompt existing users to enroll one after a successful login (when you already have a trusted session to authorize the enrollment), and only consider removing password login once enrollment is high and recovery paths are proven. If your session/token layer needs work in parallel, see Stop Storing JWTs in localStorage — the two problems (how you authenticate, how you keep someone authenticated) are separate and often get conflated.

6. Test the failure paths, not just the happy path : a user who cancels the OS biometric prompt, a browser with no platform authenticator (older desktop Safari/Firefox configurations), a user switching from a lost Android phone to a new iPhone mid-session. Passkeys degrade differently than passwords do, and “no fallback UI for a cancelled ceremony” is the most common bug in first passkey implementations.

What Still Breaks in Practice

Cross-ecosystem migration is genuinely unfinished. A user moving from Android to iPhone today re-enrolls passkeys per-site rather than carrying them over, unless they were using a cross-platform manager like 1Password or Bitwarden from the start.
Enterprise device loss is an operational problem, not just a cryptographic one. Someone’s laptop with device-bound corporate passkeys is stolen — who revokes it, how fast, and does your IdP even expose per-credential revocation cleanly? Test this before you need it.
Not every user has a passkey-capable device. Older phones, shared/kiosk devices, and some enterprise-locked-down machines cannot register a platform authenticator; you need a real fallback, not a workaround bolted on.
“Passkey” as a support term is confusing precisely because it hides the sync-fabric question. Support staff need to know to ask “which device and which account” was used to create it, because the recovery path is completely different for a synced iCloud Keychain passkey versus a device-bound YubiKey.

The Bottom Line

The cryptography is not the hard part — WebAuthn is a well-specified, narrow protocol, and the registration/login ceremonies above are genuinely all there is to the core exchange. The hard part is everything the protocol deliberately leaves to you: account recovery, fallback UX, and the fact that “passkey” quietly means four different sync fabrics with different failure modes depending on which vendor’s cloud a user happens to be in.

If you are not already an identity provider, the pragmatic move is to let one absorb this problem for you — Okta, Auth0, Entra ID, or a self-hosted Keycloak/Authentik — and spend your own engineering time on account recovery and rollout sequencing instead of CBOR parsing. If you are the relying party, the protocol rewards careful reading far more than most auth features do, and the payoff is real: there is no password database left to breach, and no login page left to phish in the way that has worked for thirty years.

Originally published at alekseialeinikov.com

Passkeys vs. Passwörter: Wie WebAuthn wirklich funktioniert, wer was anbietet und wie man es einführt

Aleksei Aleinikov — Mon, 14 Sep 2026 12:00:00 +0000

Ein Passwort ist ein Geheimnis, das zwei Parteien gleichzeitig aufbewahren müssen: Sie selbst und jeder Server, in den Sie es je eingetippt haben. Das ist der eigentliche Konstruktionsfehler. Es spielt keine Rolle, wie lang oder zufällig die Zeichenfolge ist — wenn sie getippt werden kann, kann sie gephisht werden, und wenn sie noch irgendwo anders gespeichert ist, kann sie durch einen Breach abgegriffen und wiederverwendet werden.

Ein Passkey ist kein stärkeres Geheimnis. Auf Serverseite ist er überhaupt kein Geheimnis. Er ist eine Hälfte eines Schlüsselpaars, und die Hälfte, die der Server bekommt, ist für einen Angreifer mathematisch wertlos.

Diese Unterscheidung geht in den meisten “Aktiviere Passkeys”-Marketingtexten unter, was schade ist, denn das zugrunde liegende Protokoll ist wirklich elegant und lohnt sich, es auf Nachrichtenebene zu verstehen — besonders wenn Sie es implementieren müssen. Dieser Artikel behandelt, wie die beiden zentralen WebAuthn-Zeremonien tatsächlich funktionieren, was “synchronisiert” versus “geräte-gebunden” wirklich bedeutet, wer 2026 Passkeys anbietet und was diese jeweils vorhalten, wie man Unterstützung implementiert, ohne die Kontowiederherstellung zu zerstören, und eine ehrliche Einschätzung, wo es noch hakt.

Was ein Passkey wirklich ist

Entfernt man das Produkt-Framing, ist ein Passkey ein WebAuthn-Public-Key-Credential, und WebAuthn ist ein W3C-Standard, der zusammen mit dem CTAP2-Protokoll der FIDO Alliance FIDO2 bildet. Drei Parteien sind an jeder Zeremonie beteiligt, und es lohnt sich, sie präzise zu benennen, weil die Anbieter-Dokumentation das selten tut:

Die Relying Party (RP) — die Website oder App, die Sie authentifizieren möchte. Das ist Ihr Server. Er sieht, speichert oder überträgt zu keinem Zeitpunkt einen privaten Schlüssel.
Der Client — Browser oder Betriebssystem, der zwischen dem JavaScript der RP (navigator.credentials) und dem Authenticator vermittelt und — das ist der wichtige Teil — den Origin unabhängig prüft, bevor irgendetwas signiert wird.
Der Authenticator — das Ding, das den privaten Schlüssel tatsächlich hält: die Secure Enclave eines Smartphones, das TPM eines Laptops, oder ein Roaming-Hardware-Key (YubiKey, Titan). Er spricht nie direkt mit dem Netzwerk, sondern nur über CTAP2 mit dem Client.

Ein Passwort-Login hat zwei Parteien und ein gemeinsames Geheimnis. Ein Passkey-Login hat drei Parteien und null gemeinsame Geheimnisse — der öffentliche Schlüssel, der auf Ihrem Server liegt, darf per Definition geleakt werden. Das ist der ganze Punkt, und alles Weitere in diesem Artikel beschreibt, wie diese Eigenschaft erreicht wird und wo sie doch wieder mit einem “na ja, es ist kompliziert” zurückkommt.

Wie die Registrierung funktioniert

Einem Konto “einen Passkey hinzuzufügen” ist eine WebAuthn- Registrierungszeremonie (navigator.credentials.create()). Sechs Nachrichten, drei Parteien, und der private Schlüssel berührt genau eine davon.

Der private Schlüssel entsteht in Schritt 3 und taucht in keiner der übrigen fünf Nachrichten auf.

Ein paar Details, die relevant werden, sobald man das tatsächlich implementiert:

Die Challenge ist Einmalgebrauch und wird serverseitig erzeugt. Sie dient rein der Replay-Prävention — die Signatur, die der Authenticator am Ende erzeugt, ist nur für genau diese Challenge gültig, sodass eine abgefangene Registrierungsantwort nicht gegen eine andere Session wiederverwendet werden kann.
Attestation ist optional und meist nicht erzwingenswert. Der Authenticator kann kryptografisch belegen, welches Modell er ist (attestation: "direct"), aber das leakt Geräte-Fingerprinting-Informationen, erfordert die Pflege eines Metadata-Trust-Stores, und die meisten Consumer-Flows nutzen attestation: "none". Direkte Attestation nur in regulierten Enterprise-Kontexten einsetzen, in denen eine bestimmte Hardware-Allowlist durchgesetzt werden muss.
Entdeckbare (Resident) Credentials sind das, was “Passkey” vom alten WebAuthn-2FA unterscheidet. residentKey: "required" weist den Authenticator an, das Credential so zu speichern, dass es ohne vorherige Übermittlung eines Benutzernamens gefunden werden kann — genau das treibt die “Mit Passkey anmelden”-Kontoauswahl an, statt “Benutzernamen eingeben, dann Security-Key benutzen”.
Credential-ID und öffentlicher Schlüssel sind das, was gespeichert wird — sonst nichts. Ein minimales Schema ist (user_id, credential_id, public_key_cose, sign_count, transports, created_at). sign_count ist ein Legacy-Anti-Klon-Zähler aus Einzelgeräte-Authenticatoren; die meisten synchronisierten Passkeys melden ihn konstant als 0 — als Hinweis behandeln, nicht als Sicherheitsgrenze.

Wie der Login funktioniert

Das Anmelden ist die Authentifizierungszeremonie (navigator.credentials.get()) und das Spiegelbild der Registrierung — eine Challenge geht raus, eine Signatur kommt zurück, nur dass der Server diesmal etwas hat, gegen das er die Signatur prüfen kann.

Gleicher Nutzer, gleicher Tap, zwei verschiedene Origins — der Browser entscheidet das Ergebnis, bevor überhaupt eine Signatur entsteht.

Das Detail, das die eigentliche Anti-Phishing-Eigenschaft liefert, überliest man leicht: der Client — nicht der Nutzer — prüft, ob der Origin, der die Assertion anfordert, mit dem Origin übereinstimmt, gegen den das Credential registriert wurde. Ein pixelgenauer Klon Ihrer Login-Seite auf einer Fake-Domain kann einen identischen navigator.credentials.get()-Aufruf rendern, und der Browser wird schlicht keine gültige Signatur dafür erzeugen. Es gibt kein “Passwort in die falsche Box eingetippt”-Fehlerbild, weil es keine Box gibt.

Zwei Implementierungshinweise:

Conditional UI (Autofill) ist das, was sich wie ein Passwortfeld anfühlt. Ruft man get() beim Laden der Seite mit mediation: "conditional" auf, zeigt der Browser gespeicherte Passkeys im normalen Autofill-Dropdown des Benutzernamens an — das Login-Formular sieht also weiterhin wie ein einfaches Eingabefeld aus, bietet aber zusätzlich eine Ein-Klick-Passkey-Option. Das auszulassen ist der häufigste Grund, warum “wir haben Passkeys eingeführt”-Rollouts eine geringe Adoption erzielen: Nutzer sehen die Option nie, weil sie hinter einem separaten Button versteckt ist.
User Verification (userVerification: "preferred" vs. "required") entscheidet, ob eine reine “Gerät ist anwesend”-Prüfung ausreicht oder ob die lokale biometrische/PIN-Entsperrung zwingend ist. Für alles jenseits eines trivialen Kontos sollte sie verpflichtend sein — sonst wird ein entsperrtes, unbeaufsichtigtes Gerät zu einem vollständigen Authentifizierungs-Bypass.

Wer den privaten Schlüssel tatsächlich hält

Hier wird das “nimm einfach Passkeys”-Versprechen weniger einfach, und es lohnt sich, präzise zu sein, weil es das Design der Kontowiederherstellung verändert.

Vier Sync-Ökosysteme, ein ökosystemübergreifender Fallback — und das ist eine Transportbrücke, kein Credential-Migrationspfad.

Synchronisierte Passkeys leben in der Ende-zu-Ende-verschlüsselten Cloud eines Plattformanbieters und folgen dem Konto des Nutzers, nicht seinem Gerät:

Apple synchronisiert über iCloud Keychain über macOS, iOS, iPadOS und visionOS hinweg, abgesichert durch die Apple ID und (zum Anzeigen) den Geräte-Passcode.
Google synchronisiert über den Google Passwortmanager über Android, ChromeOS und Chrome auf jedem Betriebssystem, gebunden an das Google-Konto.
Microsoft verankert Plattform-Passkeys an Windows Hello und das Microsoft-Konto; auf der Workforce-Seite fügt Entra ID Richtlinienkontrolle hinzu, welche Authenticatoren akzeptabel sind.
1Password, Bitwarden, Dashlane und andere Passwortmanager synchronisieren Passkeys über den eigenen Tresor, plattformübergreifend per Design — genau darum geht es bei einem Passwortmanager: nicht an einen OS-Anbieter gebunden zu sein.

Geräte-gebundene Passkeys sind das andere Modell: Der private Schlüssel wird in genau einem Stück Hardware erzeugt und niemals exportiert, gesichert oder synchronisiert — per Design. Das ist der Standard (und oft die einzige Option) bei FIDO2-Hardware-Security-Keys, und manche Enterprise-MDM-Richtlinien erzwingen das sogar für Plattform-Authenticatoren — Wiederherstellbarkeit gegen eine deutlich schmalere Angriffsfläche eingetauscht: Der Schlüssel kann nur durch physische Kompromittierung genau dieses einen Geräts exfiltriert werden.

Was noch nicht sauber funktioniert: Einen synchronisierten Passkey von einem Anbieter-Ökosystem in ein anderes zu übertragen. Ein in iCloud Keychain erzeugter Passkey taucht nicht im Google Passwortmanager auf. Die praktische Brücke über Ökosysteme hinweg ist der FIDO2-CTAP2-Hybrid-Transport — einen QR-Code auf einem Laptop scannen, auf dem Smartphone per Bluetooth bestätigen, und das Smartphone fungiert für diese Browser-Session als einmaliger Roaming-Authenticator. Das ist ein echt nützlicher Fallback für “ich bin am Rechner eines Freundes” oder eine Plattformlücke, aber der private Schlüssel verlässt das Smartphone nach wie vor nie, und es ist kein Migrationswerkzeug. Das Credential Exchange Protocol (CXP) der FIDO Alliance ist die Standardisierungsinitiative für einen sauberen anbieterübergreifenden Export/Import; Stand 2026 ist das noch früh.

Wer 2026 was anbietet

Für die meisten Teams ist die eigentliche Entscheidung nicht “sollen wir rohes WebAuthn implementieren”, sondern “auf welcher Ebene implementieren wir es”. Hier die Landschaft, grob geordnet von der Consumer-Plattform bis zur Identitätsinfrastruktur:

Anbieter	Was es ist	Rolle bei Passkeys
Apple, Google, Microsoft	Betriebssystem-/Browser-Plattformen	Stellen Authenticator + Sync-Ökosystem (iCloud Keychain, Google Passwortmanager, Windows Hello), die Endnutzer bereits auf ihrem Gerät haben
1Password, Bitwarden, Dashlane	Passwortmanager	Speichern und synchronisieren Passkeys über jedes Betriebssystem/jeden Browser als Tresor-Eintrag, unabhängig von einem einzelnen Plattformanbieter
Okta, Auth0, Microsoft Entra ID, Ping Identity	Enterprise-IdPs	Ermöglichen Passkey-Login für Workforce oder Kunden-App, ohne selbst WebAuthn-Code anzufassen — der IdP ist die Relying Party
Keycloak, Authentik	Selbst gehostete IdPs	Dieselbe Idee, Open Source — siehe Keycloak vs. authentik, falls Sie zwischen beiden wählen; beide unterstützen WebAuthn als Self-Service-Credential
AWS Cognito, Clerk	Verwaltete App-Auth-Plattformen	Bieten WebAuthn-/Passkey-Login als eingebaute Konfigurationsoption — kein eigener Zeremonie-Code nötig
SimpleWebAuthn, `webauthn4j`, `go-webauthn/webauthn`, py_webauthn	Open-Source-Relying-Party-Libraries	Das, worauf man zurückgreift, wenn man die Identitätsebene selbst baut — die Zeremonie parsen/verifizieren, ohne CBOR/COSE selbst zu implementieren
Yubico, Google (Titan), SoloKeys	Hardware-Security-Keys	Geräte-gebundene Roaming-Authenticatoren für Workforce-/High-Assurance-Konten, unabhängig von jedem OS-Sync-Ökosystem

Die ehrliche Einschätzung: Wenn Ihr Produkt bereits hinter Okta, Auth0, Entra ID oder einer selbst gehosteten Keycloak-/Authentik-Instanz sitzt, ist das Aktivieren von Passkeys eine Konfigurationsänderung, kein Engineering-Projekt. Der IdP ist bereits die Relying Party; Sie aktivieren nur einen Credential-Typ, den er bereits kennt. Das im Folgenden beschriebene Engineering-Projekt gilt für den Fall, dass Sie selbst die Relying Party sind — Sie betreiben Ihren eigenen Auth-Stack und wollen Passkeys als vollwertiges Credential hinzufügen.

Wie man es tatsächlich implementiert

Angenommen, Sie sind die Relying Party. So sieht die Arbeit aus:

1. Eine Server-Library wählen — CBOR/COSE nicht von Hand parsen. Das WebAuthn-Wire-Format (Attestation-Objekte, COSE-Public-Keys, CBOR-kodierte Authenticator-Daten) ist genau die Art von Sache, bei der es leicht passiert, sie subtil falsch zu machen — auf eine Weise, die erst später als Sicherheitslücke auffällt. Eine gepflegte Library für den eigenen Stack verwenden: SimpleWebAuthn (TypeScript/Node, liefert auch einen Browser-Helper), webauthn4j (Java), Fido2NetLib (.NET), go-webauthn/webauthn (Go, der aktiv gepflegte Fork der ursprünglichen Duo-Labs-Library), py_webauthn (Python), webauthn-rs (Rust). Alle stellen ungefähr dieselben zwei Funktionen bereit: “Registrierungs-/Authentifizierungs-Optionen erzeugen” und “Registrierungs-/Authentifizierungs-Antwort verifizieren”.

2. Die Relying Party ID von Anfang an richtig setzen. Die rpID ist die Domain, an die das Credential gebunden wird (kein Schema, kein Port) — example.com, nicht https://example.com, und nicht app.example.com, falls es auch auf www.example.com gültig sein muss. Hier einen Fehler zu machen führt dazu, dass in einer Umgebung registrierte Passkeys in einer anderen still und leise nicht authentifizieren (ein sehr häufiger “funktioniert lokal, bricht in Staging”-Bug, weil localhost und die Staging-Subdomain unterschiedliche RP-IDs sind).

3. Resident Keys und Conditional UI von Tag eins an erzwingen , nicht als spätere Erweiterung — ein Passkey-Rollout ohne die Autofill-Kontoauswahl-UX erreicht nur einen Bruchteil der Adoption, weil Nutzer nie entdecken, dass es die Option gibt.

4. Kontowiederherstellung entwerfen, bevor man live geht, nicht nach dem ersten Support-Ticket. Das ist der Teil, den jedes “Passkeys hinzufügen”-Tutorial auslässt. Mindestens:

Nutzern erlauben, mehr als einen Authenticator zu registrieren (Smartphone plus ein Backup-Security-Key, oder zwei synchronisierte Geräte) — ein Single Point of Failure mit einem unwiederbringlichen Credential ist schlimmer als ein Passwort.
Einen Fallback-Pfad vorhalten (E-Mail-Magic-Link, bei der Registrierung generierte Backup-Codes, oder ein menschlich verifizierter Support-Flow) für den Fall, dass jeder registrierte Authenticator verloren ist.
Explizit entscheiden, ob ein Downgrade auf Passwort/OTP pro Konto erlaubt ist, und falls ja, es hinter zusätzlicher Friktion absichern — das ist der Pfad, den ein Angreifer als Erstes probieren wird, sobald Passkeys direkten Credential-Diebstahl nutzlos machen.

5. Schrittweise migrieren, nicht als harten Cutover. Passkeys als zusätzliche Credential-Option neben bestehendem Passwort/MFA anbieten, bestehende Nutzer nach einem erfolgreichen Login zur Registrierung auffordern (wenn bereits eine vertrauenswürdige Session existiert, um die Registrierung zu autorisieren), und Passwort-Login erst dann entfernen, wenn die Registrierungsrate hoch und die Wiederherstellungspfade bewährt sind. Falls parallel an der Session-/Token-Ebene gearbeitet werden muss, siehe JWTs nicht in localStorage — die beiden Probleme (wie man authentifiziert, wie man jemanden authentifiziert hält) sind getrennt und werden häufig vermischt.

6. Die Fehlerpfade testen, nicht nur den Happy Path : ein Nutzer, der den biometrischen OS-Prompt abbricht, ein Browser ohne Plattform-Authenticator (ältere Desktop-Safari-/Firefox-Konfigurationen), ein Nutzer, der mitten in der Session von einem verlorenen Android-Smartphone auf ein neues iPhone wechselt. Passkeys degradieren anders als Passwörter, und “keine Fallback-UI für eine abgebrochene Zeremonie” ist der häufigste Bug in ersten Passkey-Implementierungen.

Was in der Praxis noch hakt

Ökosystemübergreifende Migration ist wirklich noch unfertig. Ein Nutzer, der heute von Android auf iPhone wechselt, registriert Passkeys pro Website neu, außer er nutzte von Anfang an einen plattformübergreifenden Manager wie 1Password oder Bitwarden.
Geräteverlust im Unternehmen ist ein operatives Problem, nicht nur ein kryptografisches. Jemandes Laptop mit geräte-gebundenen Firmen-Passkeys wird gestohlen — wer widerruft das, wie schnell, und legt der eigene IdP überhaupt einen sauberen Weg für Credential-Widerruf frei? Das testen, bevor man es braucht.
Nicht jeder Nutzer hat ein passkey-fähiges Gerät. Ältere Smartphones, geteilte/Kiosk-Geräte und manche unternehmenseigene, gesperrte Rechner können keinen Plattform-Authenticator registrieren; ein echter Fallback wird gebraucht, kein angeflanschter Workaround.
“Passkey” als Support-Begriff ist gerade deshalb verwirrend, weil er die Sync-Ökosystem-Frage verdeckt. Support-Mitarbeiter müssen wissen, dass sie fragen müssen, “mit welchem Gerät und welchem Konto” er erstellt wurde, weil der Wiederherstellungspfad für einen synchronisierten iCloud-Keychain-Passkey völlig anders ist als für einen geräte-gebundenen YubiKey.

Fazit

Die Kryptografie ist nicht der schwierige Teil — WebAuthn ist ein gut spezifiziertes, eng gefasstes Protokoll, und die oben beschriebenen Registrierungs-/Login-Zeremonien sind wirklich alles, was zum Kernaustausch gehört. Der schwierige Teil ist alles, was das Protokoll bewusst offenlässt: Kontowiederherstellung, Fallback-UX, und die Tatsache, dass “Passkey” leise für vier verschiedene Sync-Ökosysteme mit unterschiedlichen Fehlermodi steht, je nachdem, in welcher Anbieter-Cloud ein Nutzer gerade zufällig ist.

Wer noch kein Identity Provider ist, für den ist der pragmatische Schritt, dieses Problem von einem übernehmen zu lassen — Okta, Auth0, Entra ID, oder ein selbst gehostetes Keycloak/Authentik — und die eigene Engineering-Zeit in Kontowiederherstellung und Rollout-Reihenfolge zu stecken statt in CBOR-Parsing. Wer selbst die Relying Party ist, für den belohnt das Protokoll sorgfältiges Lesen weit mehr als die meisten Auth-Features, und die Auszahlung ist real: keine Passwort-Datenbank mehr, die man breachen kann, und keine Login-Seite mehr, die sich phishen lässt auf die Art, wie es dreißig Jahre lang funktioniert hat.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Scalability: The Bottleneck Is Almost Never the CPU

Aleksei Aleinikov — Fri, 11 Sep 2026 09:00:00 +0000

Your dashboard shows 28% CPU. Your p99 latency is 4 seconds. Someone suggests adding more pods.

This is the most common wrong turn in scaling work, and it comes from a reasonable assumption: that a slow system must be a busy system. It usually is not. It is a system where requests are queuing for something that is not CPU, and adding instances often makes it worse.

Here is what is actually limiting you, and the arithmetic to find it.

One formula that sizes almost everything

Little’s Law is the most useful thing in capacity planning, and it fits on one line:

concurrency = arrival rate x latency

L = λ × W

If 500 requests arrive per second and each spends 40 ms in the database, then at any instant you need:

500 req/s × 0.04 s = 20 concurrent database connections

Twenty. Not two hundred.

Now run it backwards, which is where it earns its keep. You have a pool of 20 connections and each query takes 50 ms :

20 / 0.05 s = 400 requests per second

That is your ceiling. Not a soft limit — a hard one. You can run forty pods; the pool still admits 400 requests per second and everything else waits. CPU stays low because the CPU is not doing anything. It is waiting.

Every queue in your system obeys this. Thread pools, connection pools, worker counts, in-flight request limits. If you know two of the three terms, you know the third.

Why 80% utilisation is not 80% fine

Here is the part that explains why capacity planning feels counter-intuitive.

For a simple queue, response time relates to utilisation like this:

response time = service time / (1 - utilisation)

R = S / (1 - ρ)

That denominator is the whole story. As utilisation approaches 1, response time does not rise gently — it goes to infinity.

Utilisation	Response time vs. an idle system
50%	2×
80%	5×
90%	10×
95%	20×
99%	100×

Going from 50% to 80% utilisation does not cost you 30% of your latency budget. It costs you 150% — response time goes from twice service time to five times it.

This is why experienced teams keep what looks like wasteful headroom, and why a system that was fine yesterday at 70% falls over today at 85% after a modest traffic increase. Nothing changed except your position on a curve that turns vertical.

The honest caveat: this exact formula assumes a single server with Poisson arrivals and exponentially distributed service times — an M/M/1 queue. Real systems have multiple servers and burstier traffic, so your constants will differ. But the shape is universal: queueing delay is hyperbolic in utilisation, not linear. Every queue you own has a knee, and it is closer to the left than intuition suggests.

Practical consequence: stop setting autoscaling targets at 80% CPU. By the time you are there you are already deep into the curve, and the new instance takes time to become useful.

The ceilings, in the order they usually bite

1. Database connections

This is the most common real limit, and it has a number you can look up.

PostgreSQL defaults to max_connections = 100 , of which 3 are reserved for superusers by default. So roughly 97 are actually available to your application.

Now count what you are asking for. Twelve pods with a pool of 10 each is 120 connections against a limit of 97. The twelfth pod gets connection errors, and the error looks like a database problem rather than an arithmetic one.

Two things make this sharper:

PostgreSQL forks a process per connection , so connections cost real memory. The docs are explicit that raising max_connections raises shared memory allocation with it. This is why a pooler like PgBouncer exists.
A bigger pool is not more throughput. Past the point where the database can genuinely execute queries in parallel, extra connections add lock contention and context switching. Throughput flattens, then falls.

MySQL uses a thread per connection and is cheaper here, which is one of the structural differences between Postgres and MySQL worth knowing before you pick.

2. File descriptors

Every socket, every open file, every connection is a file descriptor. The per-process limit is often 1024 by default on the soft limit, which sounds generous until you notice it covers inbound connections, outbound connections, log files and library internals simultaneously.

Terminal window


ulimit -n # soft limit for this shell

cat /proc/<pid>/limits # what the running process actually has

ls /proc/<pid>/fd | wc -l # how many it is using right now

The failure mode is memorable: EMFILE: too many open files, usually under exactly the load where you least want to be reading a stack trace.

3. Ephemeral ports and TIME_WAIT

This one surprises people because nothing in the application mentions it.

When your service opens an outbound connection, the kernel picks a source port from the ephemeral range. On Linux:

Terminal window


cat /proc/sys/net/ipv4/ip_local_port_range

# typically: 32768 60999

That is about 28,000 ports per unique destination address and port combination.

Then the closing side holds the socket in TIME_WAIT for 60 seconds — and on Linux that duration is compiled into the kernel, not a sysctl you can turn down.

Do the arithmetic. Open 500 short-lived connections per second to the same downstream service:

500 conn/s × 60 s = 30,000 sockets in TIME_WAIT

You have run out. New connections fail, and the error will be a connect timeout that looks like the downstream service is down.

The fix is not raising the range. It is not opening the connections: HTTP keep-alive, connection pooling, HTTP/2 multiplexing. Reuse beats provisioning.

4. Connection tracking

If your traffic passes through a NAT gateway, a firewall or a Kubernetes node using iptables, the kernel keeps a conntrack entry for every flow. That table is finite, and when it fills, packets are dropped silently — no error, no log line in your application, just latency and retries.

Terminal window


sysctl net.netfilter.nf_conntrack_max

sysctl net.netfilter.nf_conntrack_count

The gap between those two numbers is a metric worth alerting on, and almost nobody exports it.

5. Threads and event loops

A thread-per-request server is a pool by another name, and Little’s Law applies unchanged. An event-loop server has no such limit — which is its own hazard, because it will happily accept ten thousand concurrent requests and serve all of them slowly instead of refusing some quickly.

One blocking call on an event loop stalls every request on that loop. The CPU graph will look calm throughout.

Horizontal scaling and the shared denominator

Adding instances multiplies capacity for the independent part of a request and does nothing for the shared part.

Amdahl’s Law puts a ceiling on the speedup available from parallelising anything with a serial fraction. The Universal Scalability Law adds the part people miss, and it is worth writing out because the second term is the one that bites:

C(N) = N / (1 + σ(N-1) + κN(N-1))

  N number of workers

  σ contention — the serial fraction, queueing for a shared resource

  κ coherency — the cost of keeping workers consistent with each other

With κ = 0 this reduces to Amdahl’s Law: throughput flattens but never falls. With κ > 0 something worse happens — there is a maximum, and past it throughput decreases :

peak at N* = sqrt((1 - σ) / κ)

The coherency term is why adding capacity can make a system slower. It covers cache-line bouncing between cores, lock handoffs, cluster gossip, distributed consensus, cross-region replication — anything whose cost grows with the square of the number of participants because each one must agree with every other.

Concretely, if every new pod opens more connections to the same primary database, you are not scaling. You are converting a connection limit into a queue and then into a timeout. If every new node must gossip with every other node, you have bought yourself a κ term.

Ask this before adding instances:

What does a request touch that is shared?
What is the current concurrency limit on that shared thing?
Does another instance raise that limit, or compete for it?

If the answer to 3 is “compete”, scaling out makes it worse.

Load balancing: what the diagrams leave out

The box labelled “LB” in your architecture diagram hides three decisions that determine whether scaling works.

Health checks that lie. A check that returns 200 whenever the process is alive will keep routing traffic into an instance whose database pool is exhausted and whose queue is thirty seconds deep. A useful check verifies the dependencies a request actually needs — and distinguishes liveness (restart me) from readiness (stop sending me traffic). Conflating them causes restart loops under load, exactly when you need stability.

L4 versus L7 under HTTP/2. L4 balances connections. With HTTP/2 or gRPC, one long-lived connection carries many multiplexed requests — so connection-level balancing can leave one backend doing most of the work while the others idle. The graph shows even connection counts and wildly uneven CPU. For HTTP/2 and gRPC you generally want request-level balancing.

Sticky sessions. Pinning a user to an instance defeats balancing on purpose. It also means a restart drops those users’ state, and a hot user becomes a hot instance you cannot spread.

Then there is the retry trap: when a system is already saturated, automatic retries multiply the load that saturated it. Retries need rate limiting and a budget, plus jitter, or they turn a brown-out into an outage.

Queues absorb bursts, not overload

A queue in front of a slow consumer buys you time across a burst. It does nothing about a sustained arrival rate above your service rate — it just moves where the failure appears.

If arrivals exceed service capacity indefinitely, the queue grows without bound, and latency grows with it. Callers time out. They retry. Arrivals increase. This is a feedback loop with the sign pointing the wrong way.

Backpressure is the answer, and it means being willing to say no:

Bounded queues. An unbounded queue is an out-of-memory error with extra steps.
Reject fast. A 429 with Retry-After in 5 ms is far kinder than a timeout at 30 seconds — to the caller and to you.
Shed by value. Under pressure, drop the batch export before you drop the checkout.
Cap in-flight work. Concurrency limits per dependency stop one slow downstream from consuming every worker you have.

The instinct is that rejecting requests is failure. The alternative is accepting requests you cannot serve, which is also failure — just later, and for everyone at once.

What multi-region does and does not give you

Multi-region buys you availability when a region fails and lower latency for users near a region.

It does not buy you throughput on anything that must stay consistent. A globally consistent write still costs at least one cross-region round trip, and the speed of light is not a configuration parameter — roughly 5 ms per 1,000 km in fibre before any equipment touches the packet. Frankfurt to Virginia is a physical floor of tens of milliseconds, per round trip.

If your write path crosses regions, you have not scaled writes. You have added latency and a partition mode to test.

Finding the actual bottleneck

Brendan Gregg’s USE method is the fastest route. For every resource, measure three things:

	What it means	Why it matters
Utilisation	% of time the resource is busy	Misleads on its own
Saturation	How much work is queued	Usually the real signal
Errors	Rejections, timeouts, drops	Tells you what already broke

Most teams export utilisation and stop. But a pool at 100% utilisation with an empty queue is perfectly healthy, while a pool at 60% with a queue thirty deep is your outage. Saturation is the metric that names the bottleneck, and it is the one almost nobody graphs.

Practical version: for every pool in your system — database connections, HTTP clients, thread pools, worker queues — export the queue depth and the wait time , not just the in-use count.

Your load test is lying to you

This one deserves its own section, because it invalidates the measurement most teams trust most.

Most load generators work in a closed loop : send a request, wait for the response, send the next one. It seems reasonable. It produces latency numbers that are quietly, systematically wrong.

Picture a generator with 100 virtual users hammering a service that stalls for 2 seconds. During that stall, each user is blocked waiting. They send nothing. When the stall clears, everyone resumes and records a normal-looking latency.

The result: the worst two seconds of your test contributed almost no samples. Your p99 is computed over a set of measurements that excludes the period you actually care about.

This is coordinated omission , named by Gil Tene. The load generator has unwittingly coordinated with the system under test to only sample it when it is healthy.

Real users do not behave that way. They arrive on their own schedule. A user who clicks during your 2-second stall waits the full 2 seconds — plus however long the queue in front of them takes to drain.

How to tell if you have it: if your p99 under load is suspiciously close to your median, and your users report freezes you cannot reproduce, you almost certainly do.

The fixes:

Measure against the intended schedule, not the actual one. If you meant to send a request at t=0 and only sent it at t=1.8s because you were blocked, that request’s latency starts at t=0.
Use a corrected tool. wrk2 was written specifically for this. HdrHistogram provides recordValueWithExpectedInterval to backfill the missing samples.
Prefer an open model. Generate load at a fixed arrival rate regardless of whether previous responses came back — which is what real traffic does.

Until you fix this, every latency number you have collected under saturation is an underestimate, and the worse the stall, the bigger the lie.

Finding it in practice

Enough theory. Here is the actual sequence when latency is up and CPU is not.

Start with the database, because it usually is.

-- What is everyone waiting on, right now?

SELECT state, wait_event_type, wait_event, count(*)

FROM pg_stat_activity

GROUP BY 1, 2, 3

ORDER BY 4 DESC;

A pile of rows in Client / ClientRead means the database is idle and waiting on you — the bottleneck is elsewhere. A pile in Lock or LWLock means contention inside the database. Many idle in transaction means your application is holding connections open without using them, which is the same as having a smaller pool than you think.

-- How much connection headroom is left?

SELECT count(*) AS used,

       current_setting('max_connections')::int AS max_conn

FROM pg_stat_activity;

Then the sockets.

Terminal window


ss -s # totals, including TIME_WAIT

ss -tan state time-wait | wc -l # how deep is the TIME_WAIT hole

ss -tan state established | wc -l # what you actually have open

If TIME_WAIT is in the tens of thousands, you are not reusing connections. That is a client configuration problem, not a capacity problem.

Then the kernel tables.

Terminal window


cat /proc/sys/net/ipv4/ip_local_port_range

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Then the process limits.

Terminal window


cat /proc/<pid>/limits | grep 'open files'

ls /proc/<pid>/fd | wc -l

The whole sequence takes about three minutes and will identify the binding constraint far more often than another dashboard will.

The checklist

Symptom	Likely cause	First thing to check
Low CPU, high latency	Queuing on a pool	Pool wait time, queue depth
Errors at N pods but not N-1	`max_connections` exceeded	Pods × pool size vs DB limit
`too many open files`	FD limit	`ulimit -n`, `/proc/<pid>/limits`
Connect timeouts to one downstream	Ephemeral ports / TIME_WAIT	Connection reuse, keep-alive
Silent packet loss under load	conntrack table full	`nf_conntrack_count` vs `max`
Uneven backend CPU, even connections	L4 balancing HTTP/2	Move to request-level balancing
Latency grows, never recovers	No backpressure	Bound the queue, shed load
Adding pods makes it slower	Shared-resource contention	What do all pods compete for?

The bottom line

CPU is the easiest thing to graph, which is why it is the first thing people look at and the last thing that is usually wrong.

Requests queue for connections, descriptors, ports, locks and threads — and every one of those queues follows the same arithmetic. Concurrency equals arrival rate times latency. Know two terms and you know the third, which means you can calculate your ceiling instead of discovering it during an incident.

Before adding capacity, answer one question: what is the request waiting for? If you cannot name it, another instance will not fix it — it will just give the same queue more customers.

Originally published at alekseialeinikov.com

Skalierbarkeit: Der Engpass ist fast nie die CPU

Aleksei Aleinikov — Fri, 11 Sep 2026 09:00:00 +0000

Ihr Dashboard zeigt 28 Prozent CPU. Ihre p99-Latenz liegt bei vier Sekunden. Jemand schlägt vor, mehr Pods zu starten.

Das ist die häufigste Fehlabbiegung bei Skalierungsarbeit, und sie folgt aus einer nachvollziehbaren Annahme: dass ein langsames System ein ausgelastetes System sein müsse. Meistens ist es das nicht. Es ist ein System, in dem Anfragen auf etwas warten, das keine CPU ist — und zusätzliche Instanzen machen es oft schlimmer.

Hier steht, was Sie tatsächlich begrenzt, und die Rechnung, mit der Sie es finden.

Eine Formel, die fast alles dimensioniert

Littles Gesetz ist das Nützlichste in der Kapazitätsplanung und passt in eine Zeile:

Nebenläufigkeit = Ankunftsrate x Latenz

L = λ × W

Treffen 500 Anfragen pro Sekunde ein und verbringt jede 40 ms in der Datenbank, brauchen Sie zu jedem Zeitpunkt:

500 Anf./s × 0,04 s = 20 gleichzeitige Datenbankverbindungen

Zwanzig. Nicht zweihundert.

Jetzt rückwärts — dort verdient die Formel ihr Geld. Sie haben einen Pool mit 20 Verbindungen , jede Abfrage dauert 50 ms :

20 / 0,05 s = 400 Anfragen pro Sekunde

Das ist Ihre Decke. Kein weiches Limit, ein hartes. Sie können vierzig Pods betreiben; der Pool lässt weiterhin 400 Anfragen pro Sekunde durch, alles andere wartet. Die CPU bleibt niedrig, weil die CPU nichts tut. Sie wartet.

Jede Warteschlange in Ihrem System folgt dem. Thread-Pools, Connection-Pools, Worker-Zahlen, In-Flight-Limits. Kennen Sie zwei der drei Größen, kennen Sie die dritte.

Warum 80 Prozent Auslastung nicht zu 80 Prozent in Ordnung sind

Hier steht der Teil, der erklärt, warum Kapazitätsplanung unintuitiv wirkt.

Bei einer einfachen Warteschlange hängt die Antwortzeit so von der Auslastung ab:

Antwortzeit = Bedienzeit / (1 - Auslastung)

R = S / (1 - ρ)

Der Nenner ist die ganze Geschichte. Nähert sich die Auslastung der Eins, steigt die Antwortzeit nicht sanft an — sie geht gegen unendlich.

Auslastung	Antwortzeit gegenüber Leerlauf
50%	2×
80%	5×
90%	10×
95%	20×
99%	100×

Der Schritt von 50 auf 80 Prozent Auslastung kostet Sie nicht 30 Prozent Ihres Latenzbudgets. Er kostet 150 Prozent — die Antwortzeit springt vom Doppelten auf das Fünffache der Bedienzeit.

Deshalb halten erfahrene Teams scheinbar verschwenderische Reserven vor. Und deshalb fällt ein System, das gestern bei 70 Prozent stabil lief, heute bei 85 Prozent nach einem moderaten Lastanstieg um. Geändert hat sich nichts außer Ihrer Position auf einer Kurve, die senkrecht wird.

Die ehrliche Einschränkung: Diese Formel setzt einen einzelnen Server mit Poisson-Ankünften und exponentialverteilten Bedienzeiten voraus — eine M/M/1-Warteschlange. Reale Systeme haben mehrere Server und stößeren Verkehr, Ihre Konstanten werden also abweichen. Die Form aber ist universell: Wartezeit ist hyperbolisch in der Auslastung, nicht linear. Jede Ihrer Warteschlangen hat ein Knie, und es liegt weiter links, als die Intuition nahelegt.

Praktische Folge: hören Sie auf, Autoscaling-Ziele auf 80 Prozent CPU zu setzen. Dort sind Sie bereits tief in der Kurve, und die neue Instanz braucht Zeit, bis sie nützt.

Die Decken, in der Reihenfolge ihres Auftretens

1. Datenbankverbindungen

Das häufigste echte Limit — und es hat eine Zahl, die Sie nachschlagen können.

PostgreSQL erlaubt standardmäßig max_connections = 100 , davon sind drei für Superuser reserviert. Für Ihre Anwendung bleiben also rund 97.

Zählen Sie nun, was Sie anfordern. Zwölf Pods mit je zehn Verbindungen sind 120 gegen ein Limit von 97. Der zwölfte Pod bekommt Verbindungsfehler, und der Fehler sieht aus wie ein Datenbankproblem statt wie ein Rechenfehler.

Zwei Dinge verschärfen das:

PostgreSQL forkt einen Prozess pro Verbindung , Verbindungen kosten also echten Speicher. Die Dokumentation sagt ausdrücklich, dass ein höheres max_connections auch die Shared-Memory-Zuteilung erhöht. Genau dafür gibt es PgBouncer.
Ein größerer Pool ist nicht mehr Durchsatz. Jenseits des Punktes, an dem die Datenbank Abfragen wirklich parallel ausführen kann, bringen zusätzliche Verbindungen Lock-Contention und Context-Switches. Der Durchsatz flacht ab und fällt dann.

MySQL nutzt einen Thread pro Verbindung und ist hier günstiger — einer der strukturellen Unterschiede zwischen Postgres und MySQL, den man vor der Wahl kennen sollte.

2. Dateideskriptoren

Jeder Socket, jede offene Datei, jede Verbindung ist ein Dateideskriptor. Das Limit pro Prozess liegt beim Soft-Limit oft bei 1024 — klingt großzügig, bis man merkt, dass es eingehende Verbindungen, ausgehende Verbindungen, Logdateien und Bibliotheks-Interna gleichzeitig abdeckt.

Terminal window


ulimit -n # Soft-Limit dieser Shell

cat /proc/<pid>/limits # was der laufende Prozess wirklich hat

ls /proc/<pid>/fd | wc -l # wie viele er gerade nutzt

Der Fehlermodus ist einprägsam: EMFILE: too many open files, meist genau unter der Last, bei der man am wenigsten Lust auf einen Stacktrace hat.

3. Ephemere Ports und TIME_WAIT

Dieser Punkt überrascht, weil nichts in der Anwendung ihn erwähnt.

Öffnet Ihr Dienst eine ausgehende Verbindung, wählt der Kernel einen Quellport aus dem ephemeren Bereich. Unter Linux:

Terminal window


cat /proc/sys/net/ipv4/ip_local_port_range

# typischerweise: 32768 60999

Das sind rund 28.000 Ports je eindeutiger Kombination aus Zieladresse und Zielport.

Anschließend hält die schließende Seite den Socket 60 Sekunden im TIME_WAIT — und unter Linux ist diese Dauer in den Kernel einkompiliert, kein sysctl, das Sie herunterdrehen können.

Rechnen Sie nach. 500 kurzlebige Verbindungen pro Sekunde zum selben nachgelagerten Dienst:

500 Verb./s × 60 s = 30.000 Sockets im TIME_WAIT

Der Bereich ist aufgebraucht. Neue Verbindungen scheitern, und der Fehler ist ein Connect-Timeout, der aussieht, als sei der andere Dienst ausgefallen.

Die Lösung ist nicht, den Bereich zu vergrößern. Sie ist, die Verbindungen gar nicht erst zu öffnen: HTTP-Keep-Alive, Connection-Pooling, HTTP/2-Multiplexing. Wiederverwendung schlägt Bereitstellung.

4. Connection Tracking

Läuft Ihr Verkehr über ein NAT-Gateway, eine Firewall oder einen Kubernetes-Node mit iptables, führt der Kernel für jeden Flow einen conntrack -Eintrag. Diese Tabelle ist endlich, und wenn sie voll ist, werden Pakete stillschweigend verworfen — kein Fehler, keine Logzeile in Ihrer Anwendung, nur Latenz und Retries.

Terminal window


sysctl net.netfilter.nf_conntrack_max

sysctl net.netfilter.nf_conntrack_count

Der Abstand zwischen diesen beiden Zahlen ist eine Alarmschwelle wert — und fast niemand exportiert sie.

5. Threads und Event Loops

Ein Server mit einem Thread pro Anfrage ist ein Pool unter anderem Namen, Littles Gesetz gilt unverändert. Ein Event-Loop-Server hat dieses Limit nicht — was seine eigene Gefahr ist, denn er nimmt bereitwillig zehntausend gleichzeitige Anfragen an und bedient alle langsam, statt einige schnell abzulehnen.

Ein einziger blockierender Aufruf im Event Loop legt jede Anfrage auf diesem Loop lahm. Der CPU-Graph bleibt dabei ruhig.

Horizontale Skalierung und der gemeinsame Nenner

Zusätzliche Instanzen vervielfachen die Kapazität für den unabhängigen Teil einer Anfrage und ändern nichts am geteilten Teil.

Amdahls Gesetz deckelt den Gewinn aus Parallelisierung bei allem, was einen seriellen Anteil hat. Das Universal Scalability Law ergänzt den Teil, den die meisten übersehen — und es lohnt sich, ihn auszuschreiben, denn der zweite Term ist der gefährliche:

C(N) = N / (1 + σ(N-1) + κN(N-1))

  N Anzahl der Worker

  σ Contention — serieller Anteil, Warten auf geteilte Ressourcen

  κ Coherency — Kosten, die Worker untereinander konsistent zu halten

Mit κ = 0 wird daraus Amdahls Gesetz: Der Durchsatz flacht ab, fällt aber nie. Mit κ > 0 passiert etwas Schlimmeres — es gibt ein Maximum, und dahinter sinkt der Durchsatz:

Maximum bei N* = sqrt((1 - σ) / κ)

Der Coherency-Term erklärt, warum zusätzliche Kapazität ein System verlangsamen kann. Er umfasst Cache-Line-Bouncing zwischen Kernen, Lock-Übergaben, Cluster-Gossip, verteilten Konsens und regionsübergreifende Replikation — alles, dessen Kosten mit dem Quadrat der Teilnehmerzahl wachsen, weil jeder sich mit jedem abstimmen muss.

Konkret: Wenn jeder neue Pod weitere Verbindungen zur selben Primärdatenbank öffnet, skalieren Sie nicht. Sie verwandeln ein Verbindungslimit in eine Warteschlange und danach in einen Timeout. Wenn jeder neue Knoten mit jedem anderen gossipen muss, haben Sie sich einen κ-Term gekauft.

Fragen Sie vor jeder zusätzlichen Instanz:

Was berührt eine Anfrage, das geteilt ist?
Wie hoch ist das aktuelle Nebenläufigkeitslimit dieser geteilten Sache?
Erhöht eine weitere Instanz dieses Limit oder konkurriert sie darum?

Lautet die Antwort auf 3 „konkurriert”, macht Skalieren es schlimmer.

Load Balancing: was die Diagramme weglassen

Der Kasten mit der Aufschrift „LB” verbirgt drei Entscheidungen, die darüber bestimmen, ob Skalierung funktioniert.

Health Checks, die lügen. Eine Prüfung, die 200 zurückgibt, sobald der Prozess lebt, leitet Verkehr weiter in eine Instanz, deren Datenbank-Pool erschöpft und deren Warteschlange dreißig Sekunden tief ist. Eine nützliche Prüfung verifiziert die Abhängigkeiten, die eine Anfrage wirklich braucht — und trennt Liveness (starte mich neu) von Readiness (schick mir keinen Verkehr). Beides zu vermischen erzeugt Neustartschleifen unter Last, also genau dann, wenn Sie Stabilität brauchen.

L4 gegen L7 unter HTTP/2. L4 verteilt Verbindungen. Bei HTTP/2 oder gRPC trägt eine langlebige Verbindung viele gemultiplexte Anfragen — Verteilung auf Verbindungsebene kann einem Backend also den Großteil der Arbeit überlassen, während die übrigen nichts tun. Der Graph zeigt gleichmäßige Verbindungszahlen und völlig ungleiche CPU. Für HTTP/2 und gRPC wollen Sie Verteilung auf Anfrageebene.

Sticky Sessions. Einen Nutzer an eine Instanz zu binden hebelt die Verteilung absichtlich aus. Außerdem verliert ein Neustart den Zustand dieser Nutzer, und ein heißer Nutzer wird zu einer heißen Instanz, die Sie nicht verteilen können.

Dazu die Retry-Falle: Ist ein System bereits gesättigt, vervielfachen automatische Wiederholungen genau die Last, die es gesättigt hat. Retries brauchen Rate Limiting und ein Budget sowie Jitter — sonst wird aus einem Brown-out ein Ausfall.

Warteschlangen puffern Spitzen, nicht Überlast

Eine Warteschlange vor einem langsamen Konsumenten verschafft Ihnen Zeit über eine Spitze hinweg. Gegen eine dauerhaft über der Bedienrate liegende Ankunftsrate hilft sie nicht — sie verschiebt nur, wo das Scheitern sichtbar wird.

Übersteigen die Ankünfte die Bedienkapazität auf Dauer, wächst die Warteschlange unbegrenzt und die Latenz mit ihr. Aufrufer laufen in Timeouts. Sie wiederholen. Die Ankünfte steigen. Das ist eine Rückkopplung mit falschem Vorzeichen.

Backpressure ist die Antwort, und sie bedeutet, Nein sagen zu können:

Begrenzte Warteschlangen. Eine unbegrenzte Warteschlange ist ein Out-of-Memory mit Zwischenschritten.
Schnell ablehnen. Ein 429 mit Retry-After nach 5 ms ist deutlich freundlicher als ein Timeout nach 30 Sekunden — für den Aufrufer und für Sie.
Nach Wert verwerfen. Unter Druck kippen Sie den Batch-Export, bevor Sie den Checkout kippen.
In-Flight-Arbeit deckeln. Nebenläufigkeitslimits je Abhängigkeit verhindern, dass ein langsamer Downstream alle Worker verbraucht.

Der Reflex sagt, Anfragen abzulehnen sei Scheitern. Die Alternative ist, Anfragen anzunehmen, die Sie nicht bedienen können — das ist ebenfalls Scheitern, nur später und für alle gleichzeitig.

Was Multi-Region leistet und was nicht

Multi-Region kauft Ihnen Verfügbarkeit beim Ausfall einer Region und niedrigere Latenz für Nutzer in der Nähe einer Region.

Es kauft Ihnen keinen Durchsatz für irgendetwas, das konsistent bleiben muss. Ein global konsistenter Schreibvorgang kostet mindestens einen regionsübergreifenden Roundtrip, und die Lichtgeschwindigkeit ist kein Konfigurationsparameter — grob 5 ms je 1.000 km in Glasfaser, bevor irgendein Gerät das Paket anfasst. Frankfurt nach Virginia hat eine physikalische Untergrenze von mehreren Dutzend Millisekunden pro Roundtrip.

Kreuzt Ihr Schreibpfad Regionen, haben Sie Schreibvorgänge nicht skaliert. Sie haben Latenz und einen Partitionsmodus zum Testen hinzugefügt.

Den echten Engpass finden

Brendan Greggs USE-Methode ist der schnellste Weg. Messen Sie für jede Ressource drei Dinge:

	Was es bedeutet	Warum es zählt
Utilisation	Anteil der Zeit, in der die Ressource beschäftigt ist	Für sich genommen irreführend
Saturation	Wie viel Arbeit wartet	Meist das eigentliche Signal
Errors	Ablehnungen, Timeouts, Verwürfe	Sagt, was bereits kaputt ist

Die meisten Teams exportieren Auslastung und hören dort auf. Aber ein Pool mit 100 Prozent Auslastung und leerer Warteschlange ist kerngesund, während ein Pool mit 60 Prozent und einer dreißig Einträge tiefen Warteschlange Ihr Ausfall ist. Die Sättigung benennt den Engpass — und genau sie zeichnet fast niemand auf.

Praktisch: Exportieren Sie für jeden Pool im System — Datenbankverbindungen, HTTP-Clients, Thread-Pools, Worker-Queues — Warteschlangentiefe und Wartezeit , nicht nur die Zahl der belegten Slots.

Ihr Lasttest lügt Sie an

Dieser Punkt verdient einen eigenen Abschnitt, denn er entwertet genau die Messung, der die meisten Teams am meisten vertrauen.

Die meisten Lastgeneratoren arbeiten in einer geschlossenen Schleife : Anfrage senden, auf die Antwort warten, nächste senden. Klingt vernünftig. Liefert Latenzzahlen, die still und systematisch falsch sind.

Stellen Sie sich einen Generator mit 100 virtuellen Nutzern vor, der einen Dienst belastet, welcher zwei Sekunden hängt. Während dieses Hängers ist jeder Nutzer blockiert. Sie senden nichts. Löst sich der Stau, machen alle weiter und verbuchen eine normal aussehende Latenz.

Das Ergebnis: Die schlimmsten zwei Sekunden Ihres Tests haben fast keine Messpunkte beigesteuert. Ihr p99 wird über eine Menge berechnet, die genau den Zeitraum ausschließt, der Sie interessiert.

Das ist Coordinated Omission , benannt von Gil Tene. Der Lastgenerator hat sich unfreiwillig mit dem Testsystem abgestimmt und misst es nur dann, wenn es gesund ist.

Echte Nutzer verhalten sich nicht so. Sie kommen nach eigenem Fahrplan. Wer während Ihres Zwei-Sekunden-Hängers klickt, wartet die vollen zwei Sekunden — plus die Zeit, die die Warteschlange davor zum Abbau braucht.

Woran Sie es erkennen: Liegt Ihr p99 unter Last verdächtig nah am Median, während Nutzer von Einfrierern berichten, die Sie nicht reproduzieren können, haben Sie es mit ziemlicher Sicherheit.

Die Gegenmittel:

Gegen den geplanten Fahrplan messen, nicht gegen den tatsächlichen. Wollten Sie bei t=0 senden und kamen blockiert erst bei t=1,8 s dazu, beginnt die Latenz dieser Anfrage bei t=0.
Ein korrigiertes Werkzeug nutzen. wrk2 wurde genau dafür geschrieben. HdrHistogram bietet recordValueWithExpectedInterval, um die fehlenden Messpunkte nachzutragen.
Offenes Modell bevorzugen. Last mit fester Ankunftsrate erzeugen, unabhängig davon, ob vorherige Antworten zurückkamen — genau so verhält sich echter Verkehr.

Bis Sie das beheben, ist jede unter Sättigung erhobene Latenzzahl eine Untertreibung — und je schlimmer der Hänger, desto größer die Lüge.

In der Praxis finden

Genug Theorie. Hier die tatsächliche Reihenfolge, wenn die Latenz oben ist und die CPU nicht.

Bei der Datenbank anfangen, denn dort liegt es meistens.

-- Worauf wartet gerade wer?

SELECT state, wait_event_type, wait_event, count(*)

FROM pg_stat_activity

GROUP BY 1, 2, 3

ORDER BY 4 DESC;

Viele Zeilen mit Client / ClientRead bedeuten, dass die Datenbank untätig ist und auf Sie wartet — der Engpass liegt woanders. Viele Lock oder LWLock bedeuten Contention innerhalb der Datenbank. Viele idle in transaction bedeuten, dass Ihre Anwendung Verbindungen offen hält, ohne sie zu nutzen — das entspricht einem kleineren Pool, als Sie denken.

-- Wie viel Verbindungsreserve ist übrig?

SELECT count(*) AS used,

       current_setting('max_connections')::int AS max_conn

FROM pg_stat_activity;

Dann die Sockets.

Terminal window


ss -s # Summen, inklusive TIME_WAIT

ss -tan state time-wait | wc -l # wie tief ist das TIME_WAIT-Loch

ss -tan state established | wc -l # was wirklich offen ist

Liegt TIME_WAIT im Zehntausenderbereich, verwenden Sie Verbindungen nicht wieder. Das ist ein Client-Konfigurationsproblem, kein Kapazitätsproblem.

Dann die Kernel-Tabellen.

Terminal window


cat /proc/sys/net/ipv4/ip_local_port_range

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Dann die Prozesslimits.

Terminal window


cat /proc/<pid>/limits | grep 'open files'

ls /proc/<pid>/fd | wc -l

Die ganze Sequenz dauert etwa drei Minuten und benennt die bindende Randbedingung deutlich häufiger als ein weiteres Dashboard.

Die Checkliste

Symptom	Wahrscheinliche Ursache	Was zuerst prüfen
Niedrige CPU, hohe Latenz	Warten an einem Pool	Wartezeit im Pool, Warteschlangentiefe
Fehler bei N Pods, nicht bei N-1	`max_connections` überschritten	Pods × Poolgröße gegen DB-Limit
`too many open files`	FD-Limit	`ulimit -n`, `/proc/<pid>/limits`
Connect-Timeouts zu einem Downstream	Ephemere Ports / TIME_WAIT	Wiederverwendung, Keep-Alive
Stiller Paketverlust unter Last	conntrack-Tabelle voll	`nf_conntrack_count` gegen `max`
Ungleiche Backend-CPU, gleiche Verbindungen	L4 verteilt HTTP/2	Auf Anfrageebene verteilen
Latenz wächst und erholt sich nie	Keine Backpressure	Warteschlange begrenzen, Last abwerfen
Mehr Pods machen es langsamer	Contention um geteilte Ressourcen	Worum konkurrieren alle Pods?

Das Fazit

CPU ist am leichtesten zu graphen — deshalb schaut man zuerst dorthin, und deshalb ist es meist das Falsche.

Anfragen warten auf Verbindungen, Deskriptoren, Ports, Locks und Threads, und jede dieser Warteschlangen folgt derselben Rechnung. Nebenläufigkeit gleich Ankunftsrate mal Latenz. Kennen Sie zwei Größen, kennen Sie die dritte — und können Ihre Decke ausrechnen, statt sie während eines Incidents zu entdecken.

Beantworten Sie vor jeder zusätzlichen Kapazität eine Frage: Worauf wartet die Anfrage? Können Sie es nicht benennen, behebt eine weitere Instanz nichts — sie verschafft derselben Warteschlange nur mehr Kundschaft.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Postgres vs MySQL in 2026: Performance, Syntax and the Real Differences

Aleksei Aleinikov — Thu, 10 Sep 2026 09:00:00 +0000

Most Postgres versus MySQL comparisons are a feature checklist from 2015 with the dates changed. Both databases have added most of what the other used to have, so the checklist tells you almost nothing.

What still differs is deeper: how they store rows, how they handle concurrent versions of those rows, how they treat a connection, and what happens when a migration fails halfway. Those differences do not show up in a feature table, and they are the ones you live with.

The 30-second answer

Complex queries, analytics, JSON, geospatial, extensions? Postgres.
Huge numbers of simple connections, key-based lookups, read replicas? MySQL.
Team already fluent in one of them? That one. Seriously.
Starting fresh with no constraint? Postgres, because the extension ecosystem gives you more escape hatches later.
Single process, no network, no ops? Neither — that is SQLite.

Everything below is why.

What actually differs under the hood

Storage: clustered vs heap

This single choice explains most performance differences.

MySQL (InnoDB) clusters the table on the primary key. The row data physically lives inside the primary key index. Look up by primary key and you traverse one B-tree and you are holding the row.

The cost: secondary indexes store the primary key, not a row location. So a lookup via a secondary index traverses that index to find a primary key, then traverses the primary key index to find the row. Two traversals. It also means a wide primary key inflates every secondary index on the table.

Postgres stores rows in a heap — an unordered pile of pages — and every index, including the primary key, points into it. Every index lookup costs an extra fetch to reach the row.

The benefit: all indexes are equal, so a wide primary key does not tax the others, and Postgres can use index-only scans when its visibility map says a page is fully visible.

What this means in practice: MySQL is excellent at “give me the row with this ID”. Postgres is more even-handed when your access patterns are varied.

MVCC: where old row versions live

Both give you readers that never block writers. They pay for it differently.

Postgres writes a new version of the row into the table itself and leaves the old one behind until VACUUM reclaims it. Heavy-update tables therefore bloat , and autovacuum keeping up is a real operational concern rather than a theoretical one.

MySQL writes old versions into undo logs , so the table stays compact. The cost moves elsewhere: long-running transactions force the undo log to grow, and a reader on an old snapshot has to walk back through those versions.

Neither approach is free. Postgres makes you think about vacuum; MySQL makes you think about long transactions and undo growth.

Connections: process vs thread

Postgres forks a process per connection. A process is not cheap. A few hundred mostly-idle connections consume real memory, and you will want PgBouncer or an equivalent pooler in front of any serious deployment. Serverless platforms that open a connection per request make this acute.

MySQL uses a thread per connection , which is dramatically cheaper. Thousands of connections is an ordinary configuration.

If your architecture opens many short-lived connections and you cannot pool, that fact alone may pick your database.

Postgres vs MySQL performance

Nobody can honestly tell you which is faster, because they are fast at different shapes of work. Here is what each actually favours.

MySQL tends to win at:

Primary-key point lookups — one traversal, row in hand
Very high connection counts
Simple, high-volume OLTP where the query plan is obvious
Read-scaling via replicas, with a long-mature binlog replication story

Postgres tends to win at:

Complex joins, subqueries and aggregations — a stronger planner
Analytical queries alongside transactional ones
Anything with partial, expression or covering indexes
Write patterns that benefit from HOT updates avoiding index churn
JSON, arrays, geospatial and vector work, because of extensions

A word on benchmarks. Any number you read — including any I could publish — is one workload, one schema, one hardware profile and one configuration. Tuning moves results more than the engine choice does. If performance is genuinely your deciding factor, benchmark your queries on your data. Everything else is someone else’s workload.

If you are optimising rather than choosing, the techniques in SQL query optimisation apply to both engines.

Postgres vs MySQL syntax differences

This is the section that matters when you are porting something. These are the ones that actually break.

What	Postgres	MySQL
String concatenation	`'a'
Quote an identifier	{% raw %}`"my table"`	`my table`
Auto-incrementing key	`GENERATED ALWAYS AS IDENTITY`	`AUTO_INCREMENT`
Upsert	`INSERT ... ON CONFLICT DO UPDATE`	`INSERT ... ON DUPLICATE KEY UPDATE`
Return the inserted row	`INSERT ... RETURNING *`	not supported
Boolean	real `BOOLEAN` type	alias for `TINYINT(1)`
String comparison	case-sensitive by default	case-insensitive in common collations
Limit with offset	`LIMIT 10 OFFSET 20`	`LIMIT 10 OFFSET 20` or `LIMIT 20, 10`
Current timestamp	`NOW()`, `CURRENT_TIMESTAMP`	`NOW()`, `CURRENT_TIMESTAMP`
Arrays	native array types	not supported
Regex match	`~`, `~*`	`REGEXP`, `RLIKE`

Three of these cause most of the pain:

RETURNING. Postgres hands you back the row you just wrote in the same statement. MySQL does not support it, so you insert and then select, which is a second round trip and a race unless you are careful. MariaDB does support it.

-- Postgres: one statement

INSERT INTO users (email) VALUES ('a@b.com')

RETURNING id, created_at;

Case sensitivity. In Postgres, WHERE email = 'Bob@x.com' will not match a stored bob@x.com. In MySQL with a typical collation, it will. Ports in either direction silently change behaviour, and the bug surfaces in production as “login sometimes doesn’t work”.

Unquoted identifier folding. Postgres lowercases unquoted identifiers, so CREATE TABLE MyTable produces mytable. Once you quote something as "MyTable", you must quote it forever. The usual advice — stick to lower_snake_case and never quote — is worth following in both.

Operations: the difference nobody mentions

Postgres has transactional DDL. You can wrap schema changes in a transaction and roll them back:


BEGIN;

ALTER TABLE orders ADD COLUMN status text;

-- something fails here

ROLLBACK; -- the column never existed

MySQL commits implicitly on DDL. A migration that fails on step four of six leaves you with three applied changes and no way back except a hand-written down migration.

If you deploy schema changes often, this is a bigger day-to-day quality-of-life difference than any query benchmark.

Two more operational notes:

Extensions. Postgres lets you add PostGIS for geospatial, pgvector for embeddings, TimescaleDB for time series — inside the same database, with the same backups and the same transactions. MySQL has no comparable mechanism. If you might need a vector database, this matters.
Replication. MySQL’s binlog replication is old, well understood and has excellent tooling. Postgres has streaming physical replication and logical replication; both work well, and logical replication has improved substantially in recent releases.

Where SQLite fits

SQLite is frequently put in this comparison, and the framing is usually wrong.

SQLite is not a small server database. It is a library that runs inside your process. There is no server, no port, no user accounts and no network round trip — a function call reads a file.

That makes it excellent for:

Application-local state, caches and config
Test suites, where a database per test costs microseconds
Edge and embedded deployments
Read-heavy workloads served from a single machine

And unsuitable the moment you need several application servers writing concurrently. SQLite serialises writers: one at a time.

The honest rule: if exactly one process ever touches the data, SQLite is likely the right answer and the simplest one. If two might, you want a server.

MariaDB vs MySQL

MariaDB began as a MySQL fork after Oracle’s acquisition. Years later, “drop-in replacement” is no longer accurate.

They have diverged : separate optimiser development, different storage engines, and features on each side the other lacks. MariaDB has RETURNING; MySQL does not. Version numbers no longer correspond at all.

Drivers and basic dumps are largely interchangeable. Replication between them and any recent syntax are not.

Choose MariaDB for community governance and its specific feature set. Choose MySQL if you depend on Oracle’s ecosystem, a managed offering built on it, or its exact replication semantics.

Which versions to run

As of September 2026:

Database	Current	Notes
PostgreSQL	18 (18.6)	19 in beta; 14 reaches EOL Nov 2026
MySQL	9.7 LTS (9.7.3)	8.4 LTS supported to 2029; 8.0 hit EOL Apr 2026
MariaDB	12.3 LTS (12.3.3)	11.8 and 11.4 LTS still supported

Two things to act on: if you are on MySQL 8.0 , it is out of support — plan the move to 8.4 or 9.7. If you are on Postgres 14 , you have until November.

Postgres ships a major version yearly with five years of support. MySQL splits into quarterly Innovation releases and roughly biennial LTS releases; unless you need a specific new feature, run LTS.

The decision table

Your situation	Pick
Complex queries, reporting alongside OLTP	Postgres
Geospatial, vectors, time series in one database	Postgres — extensions
Frequent schema migrations	Postgres — transactional DDL
Thousands of connections, no pooler possible	MySQL
Key-value style access by primary key	MySQL — clustered index
Heavy read scaling via replicas	MySQL — mature binlog tooling
One process owns the data, no network	SQLite
Want community governance over Oracle	MariaDB or Postgres
Team already deeply fluent in one	That one

The bottom line

The feature gap that made this an interesting argument a decade ago has mostly closed. What is left is structural: clustered versus heap storage , old row versions in the table versus in undo logs , a process versus a thread per connection , and whether a failed migration can roll back.

Those four differences will shape your operational life far more than any feature checklist. Pick on those, and on which one your team can debug at 3am.

And if you find yourself deciding on a benchmark you did not run, you are choosing based on someone else’s workload.

Originally published at alekseialeinikov.com

Postgres vs. MySQL 2026: Performance, Syntax und die echten Unterschiede

Aleksei Aleinikov — Thu, 10 Sep 2026 09:00:00 +0000

Die meisten Vergleiche von Postgres und MySQL sind eine Feature-Checkliste von 2015 mit aktualisierten Jahreszahlen. Beide Datenbanken haben inzwischen das meiste nachgeholt, was die jeweils andere früher exklusiv hatte — die Checkliste sagt also fast nichts mehr aus.

Was sich weiterhin unterscheidet, liegt tiefer: wie Zeilen gespeichert werden, wie gleichzeitige Versionen dieser Zeilen verwaltet werden, was eine Verbindung kostet, und was passiert, wenn eine Migration auf halbem Weg scheitert. Diese Unterschiede tauchen in keiner Feature-Tabelle auf — und mit ihnen leben Sie täglich.

Die Antwort in 30 Sekunden

Komplexe Abfragen, Analytik, JSON, Geodaten, Erweiterungen? Postgres.
Sehr viele einfache Verbindungen, Zugriffe über Schlüssel, Read-Replicas? MySQL.
Team beherrscht bereits eine der beiden? Diese. Ernsthaft.
Grüne Wiese ohne Randbedingungen? Postgres, weil das Erweiterungs-Ökosystem später mehr Notausgänge bietet.
Ein Prozess, kein Netzwerk, kein Betrieb? Keine von beiden — das ist SQLite.

Alles Weitere ist die Begründung.

Was sich unter der Haube wirklich unterscheidet

Speicherung: geclustert gegen Heap

Diese eine Entscheidung erklärt die meisten Performance-Unterschiede.

MySQL (InnoDB) clustert die Tabelle über den Primärschlüssel. Die Zeilendaten liegen physisch im Primärschlüsselindex. Ein Zugriff über den Primärschlüssel traversiert einen B-Baum — und Sie halten die Zeile in der Hand.

Der Preis: Sekundärindizes speichern den Primärschlüssel, keine Zeilenposition. Ein Zugriff über einen Sekundärindex traversiert also erst diesen Index bis zum Primärschlüssel und dann den Primärschlüsselindex bis zur Zeile. Zwei Traversierungen. Außerdem bläht ein breiter Primärschlüssel jeden Sekundärindex der Tabelle auf.

Postgres legt Zeilen in einem Heap ab — einem ungeordneten Haufen von Seiten — und jeder Index, auch der Primärschlüssel, zeigt dort hinein. Jeder Indexzugriff kostet einen zusätzlichen Zugriff auf die Zeile.

Der Vorteil: Alle Indizes sind gleichwertig, ein breiter Primärschlüssel belastet die übrigen nicht, und Postgres kann Index-Only-Scans nutzen, wenn die Visibility Map eine Seite als vollständig sichtbar meldet.

Praktisch heißt das: MySQL ist hervorragend in „gib mir die Zeile mit dieser ID”. Postgres ist ausgewogener, wenn Ihre Zugriffsmuster vielfältig sind.

MVCC: wo alte Zeilenversionen liegen

Beide liefern Leser, die Schreiber nie blockieren. Sie bezahlen es unterschiedlich.

Postgres schreibt eine neue Zeilenversion in die Tabelle selbst und lässt die alte liegen, bis VACUUM sie freigibt. Änderungsintensive Tabellen blähen dadurch auf, und ob Autovacuum hinterherkommt, ist eine reale Betriebsfrage, keine theoretische.

MySQL schreibt alte Versionen in Undo-Logs , die Tabelle bleibt also kompakt. Die Kosten wandern woandershin: Lang laufende Transaktionen lassen das Undo-Log wachsen, und ein Leser auf einem alten Snapshot muss sich durch diese Versionen zurückarbeiten.

Keiner der beiden Wege ist gratis. Postgres zwingt Sie, über Vacuum nachzudenken; MySQL über lange Transaktionen und Undo-Wachstum.

Verbindungen: Prozess gegen Thread

Postgres forkt einen Prozess pro Verbindung. Ein Prozess ist nicht billig. Einige hundert überwiegend untätige Verbindungen kosten echten Speicher, und vor jedem ernsthaften Deployment wollen Sie PgBouncer oder einen vergleichbaren Pooler. Serverless-Plattformen, die pro Request eine Verbindung öffnen, verschärfen das.

MySQL nutzt einen Thread pro Verbindung , was dramatisch günstiger ist. Tausende Verbindungen sind dort eine gewöhnliche Konfiguration.

Wenn Ihre Architektur viele kurzlebige Verbindungen öffnet und Sie nicht poolen können, entscheidet allein diese Tatsache womöglich Ihre Datenbankwahl.

Postgres vs. MySQL: Performance

Niemand kann Ihnen ehrlich sagen, welche schneller ist, weil sie bei unterschiedlichen Arbeitsformen schnell sind. Was jede tatsächlich begünstigt:

MySQL liegt tendenziell vorn bei:

Punktzugriffen über den Primärschlüssel — eine Traversierung, Zeile da
sehr hohen Verbindungszahlen
einfachem OLTP mit hohem Volumen, wo der Ausführungsplan offensichtlich ist
Leseskalierung über Replicas, mit ausgereifter Binlog-Replikation

Postgres liegt tendenziell vorn bei:

komplexen Joins, Unterabfragen und Aggregationen — stärkerer Planer
analytischen Abfragen neben dem transaktionalen Betrieb
allem mit Teil-, Ausdrucks- oder abdeckenden Indizes
Schreibmustern, die von HOT-Updates ohne Index-Churn profitieren
JSON, Arrays, Geodaten und Vektoren — dank Erweiterungen

Ein Wort zu Benchmarks. Jede Zahl, die Sie lesen — auch jede, die ich veröffentlichen könnte — ist eine Last, ein Schema, ein Hardwareprofil, eine Konfiguration. Tuning verschiebt Ergebnisse stärker als die Wahl der Engine. Wenn Performance wirklich Ihr Entscheidungskriterium ist, messen Sie Ihre Abfragen auf Ihren Daten. Alles andere ist die Last von jemand anderem.

Wenn Sie nicht wählen, sondern optimieren: Die Techniken aus SQL-Query-Optimierung gelten für beide Engines.

Postgres vs. MySQL: Syntaxunterschiede

Der Abschnitt, der bei einer Portierung zählt. Diese Punkte brechen tatsächlich.

Thema	Postgres	MySQL
String-Verkettung	`'a'
Bezeichner quoten	{% raw %}`"meine tabelle"`	`meine tabelle`
Auto-inkrementierender Schlüssel	`GENERATED ALWAYS AS IDENTITY`	`AUTO_INCREMENT`
Upsert	`INSERT ... ON CONFLICT DO UPDATE`	`INSERT ... ON DUPLICATE KEY UPDATE`
Eingefügte Zeile zurückgeben	`INSERT ... RETURNING *`	nicht unterstützt
Boolean	echter `BOOLEAN`-Typ	Alias für `TINYINT(1)`
String-Vergleich	standardmäßig case-sensitiv	in üblichen Kollationen case-insensitiv
Limit mit Offset	`LIMIT 10 OFFSET 20`	`LIMIT 10 OFFSET 20` oder `LIMIT 20, 10`
Aktueller Zeitstempel	`NOW()`, `CURRENT_TIMESTAMP`	`NOW()`, `CURRENT_TIMESTAMP`
Arrays	native Array-Typen	nicht unterstützt
Regex-Vergleich	`~`, `~*`	`REGEXP`, `RLIKE`

Drei davon verursachen den meisten Schmerz:

RETURNING. Postgres gibt Ihnen die soeben geschriebene Zeile in derselben Anweisung zurück. MySQL unterstützt das nicht — Sie fügen ein und selektieren danach, also ein zweiter Roundtrip und ein Wettlauf, wenn Sie nicht aufpassen. MariaDB unterstützt es.

-- Postgres: eine Anweisung

INSERT INTO users (email) VALUES ('a@b.com')

RETURNING id, created_at;

Groß-/Kleinschreibung. In Postgres findet WHERE email = 'Bob@x.com' ein gespeichertes bob@x.com nicht. In MySQL mit üblicher Kollation schon. Portierungen in beide Richtungen ändern das Verhalten stillschweigend, und der Fehler zeigt sich in Produktion als „Login geht manchmal nicht”.

Faltung ungequoteter Bezeichner. Postgres schreibt ungequotete Bezeichner klein, CREATE TABLE MyTable erzeugt also mytable. Sobald Sie etwas als "MyTable" quoten, müssen Sie es für immer quoten. Der übliche Rat — durchgehend lower_snake_case, niemals quoten — lohnt sich in beiden.

Betrieb: der Unterschied, den niemand erwähnt

Postgres beherrscht transaktionales DDL. Sie können Schemaänderungen in eine Transaktion packen und zurückrollen:


BEGIN;

ALTER TABLE orders ADD COLUMN status text;

-- hier scheitert etwas

ROLLBACK; -- die Spalte hat nie existiert

MySQL committet bei DDL implizit. Eine Migration, die bei Schritt vier von sechs scheitert, hinterlässt drei angewandte Änderungen und keinen Rückweg außer einer handgeschriebenen Down-Migration.

Wer häufig Schemaänderungen ausrollt, spürt das im Alltag stärker als jeden Query-Benchmark.

Zwei weitere Betriebsnotizen:

Erweiterungen. Postgres erlaubt PostGIS für Geodaten, pgvector für Embeddings, TimescaleDB für Zeitreihen — in derselben Datenbank, mit denselben Backups und denselben Transaktionen. MySQL hat keinen vergleichbaren Mechanismus. Falls Sie womöglich eine Vektordatenbank brauchen, zählt das.
Replikation. MySQLs Binlog-Replikation ist alt, gut verstanden und hervorragend mit Werkzeugen versorgt. Postgres bietet physische Streaming-Replikation und logische Replikation; beides funktioniert gut, und die logische Replikation hat in jüngeren Releases deutlich zugelegt.

Wo SQLite hingehört

SQLite landet oft in diesem Vergleich, meist mit falschem Rahmen.

SQLite ist keine kleine Serverdatenbank, sondern eine Bibliothek in Ihrem Prozess. Kein Server, kein Port, keine Benutzerkonten, kein Netzwerk-Roundtrip — ein Funktionsaufruf liest eine Datei.

Das macht es hervorragend für:

lokalen Anwendungszustand, Caches und Konfiguration
Testsuites, wo eine Datenbank pro Test Mikrosekunden kostet
Edge- und eingebettete Deployments
leseintensive Lasten auf einer einzelnen Maschine

Und ungeeignet, sobald mehrere Anwendungsserver gleichzeitig schreiben müssen. SQLite serialisiert Schreiber: einer nach dem anderen.

Die ehrliche Regel: Fasst genau ein Prozess die Daten an, ist SQLite wahrscheinlich richtig — und die einfachste Antwort. Könnten es zwei sein, wollen Sie einen Server.

MariaDB gegen MySQL

MariaDB entstand nach Oracles Übernahme als MySQL-Fork. Jahre später ist „Drop-in-Ersatz” nicht mehr zutreffend.

Beide haben sich auseinanderentwickelt : getrennte Optimizer-Arbeit, unterschiedliche Storage-Engines, und auf jeder Seite Funktionen, die der anderen fehlen. MariaDB hat RETURNING, MySQL nicht. Die Versionsnummern korrespondieren überhaupt nicht mehr.

Treiber und einfache Dumps sind weitgehend austauschbar. Replikation zwischen beiden und neuere Syntax sind es nicht.

MariaDB für Community-Governance und den konkreten Funktionsumfang. MySQL , wenn Sie an Oracles Ökosystem, einem darauf aufbauenden verwalteten Angebot oder der exakten Replikationssemantik hängen.

Welche Versionen betreiben

Stand September 2026:

Datenbank	Aktuell	Anmerkungen
PostgreSQL	18 (18.6)	19 in der Beta; 14 endet im Nov. 2026
MySQL	9.7 LTS (9.7.3)	8.4 LTS bis 2029; 8.0 endete im Apr. 2026
MariaDB	12.3 LTS (12.3.3)	11.8 und 11.4 LTS weiterhin unterstützt

Zwei Handlungspunkte: Wer auf MySQL 8.0 ist, läuft ohne Support — planen Sie den Wechsel auf 8.4 oder 9.7. Wer auf Postgres 14 ist, hat Zeit bis November.

Postgres liefert jährlich eine Hauptversion mit fünf Jahren Support. MySQL teilt sich in quartalsweise Innovation-Releases und etwa zweijährliche LTS-Releases; betreiben Sie LTS, sofern Sie kein konkretes neues Feature brauchen.

Die Entscheidungstabelle

Ihre Situation	Wahl
Komplexe Abfragen, Reporting neben OLTP	Postgres
Geodaten, Vektoren, Zeitreihen in einer Datenbank	Postgres — Erweiterungen
Häufige Schema-Migrationen	Postgres — transaktionales DDL
Tausende Verbindungen, kein Pooler möglich	MySQL
Key-Value-artiger Zugriff über Primärschlüssel	MySQL — geclusterter Index
Starke Leseskalierung über Replicas	MySQL — ausgereifte Binlog-Werkzeuge
Ein Prozess besitzt die Daten, kein Netzwerk	SQLite
Community-Governance statt Oracle	MariaDB oder Postgres
Team beherrscht eine davon tiefgehend	Diese

Das Fazit

Die Feature-Lücke, die diese Debatte vor einem Jahrzehnt interessant machte, ist weitgehend geschlossen. Geblieben ist Strukturelles: geclusterte gegen Heap-Speicherung , alte Zeilenversionen in der Tabelle gegen Undo-Logs , ein Prozess gegen ein Thread pro Verbindung , und ob eine gescheiterte Migration zurückrollbar ist.

Diese vier Unterschiede prägen Ihren Betriebsalltag weit stärker als jede Feature-Checkliste. Entscheiden Sie danach — und danach, welche Ihr Team um drei Uhr nachts debuggen kann.

Und wenn Sie sich anhand eines Benchmarks entscheiden, den Sie nicht selbst gefahren haben, entscheiden Sie anhand der Last von jemand anderem.

Ursprünglich veröffentlicht auf alekseialeinikov.com

npm Supply Chain Attack Mitigation: What Actually Works

Aleksei Aleinikov — Wed, 09 Sep 2026 09:00:00 +0000

If you last read about npm supply chain security after the Shai-Hulud worm, your mental model is a year out of date. A lot shipped during 2026, and some of the advice everyone was giving is now done for you by default.

This is what is actually true today: what you get for free, what is still opt-in, and what nobody is going to fix on your behalf.

The attack this all responds to

GitHub was notified on September 14, 2025 of the Shai-Hulud attack. Worth restating because every control below is shaped by it:

It got in through compromised maintainer accounts , not a vulnerability in any package.
It injected malicious post-install scripts into popular packages.
It was self-replicating — a worm.
It stole multiple kinds of secrets , not just npm tokens.

GitHub removed 500+ compromised packages and blocked uploads matching the malware’s indicators of compromise.

Every package involved was one you meant to install, from a maintainer you had reason to trust, at an unremarkable version number.

Why your scanner said the tree was clean

npm audit compares your dependency tree against an advisory database. For a finding to exist, somebody must first discover, report and publish it.

A malicious version pushed twenty minutes ago has been through none of that. No advisory, no match, clean report.

One honest update: in August 2026 GitHub wired OpenSSF’s malicious-packages data into the Advisory Database, so malware advisories now sit alongside CVEs. The gap is narrower than it was.

It is not closed. An advisory still trails the attack, and spreading inside that lag is the entire business model. Keep running npm audit. Just stop treating a clean result as evidence you are fine.

What you now get by default

This is the part that changed, and the reason most 2025-era advice needs rereading.

npm v12 disables install scripts

Announced June 2026 as a breaking change: npm v12 disables install scripts by default. Attackers used them to exfiltrate credentials at install time rather than waiting for your code to import anything. You re-enable them by approving specific scripts.

The same change blocks dependencies specified via git or remote URLs by default, closing another install-time execution path.

This is the single most important line in this article. The vector Shai-Hulud actually used is off by default — if you are on v12.

If you are not, it is still your job:

Terminal window


npm ci --ignore-scripts

Or in .npmrc:

ignore-scripts=true

The honest cost: packages with native components need their build step. A blanket ban across a large monorepo will break installs. Deny by default and allowlist the exceptions — the model pnpm has used for a while via allowBuilds, with dangerouslyAllowAllBuilds if you want out entirely. The name tells you what the maintainers think of that.

Dependabot waits three days

Since July 2026, Dependabot version updates wait until a release is at least three days old before opening a pull request. Detection signals get time to surface first. On by default , and security updates are exempt — critical fixes are not delayed.

Attackers depend on speed. This removes it, at almost no cost to you.

pnpm enforces a stricter version at install time:

pnpm-workspace.yaml


minimumReleaseAge: 10080 # minutes — one week

A version younger than that is not eligible for installation at all. minimumReleaseAgeExclude handles the packages you want immediately.

Classic tokens are gone

npm’s docs are unambiguous: as of November 2025, only granular access tokens are supported. Legacy access tokens have been removed.

Granular tokens scope by package, scope and organisation, restrict by IP range, and take an expiry at least one day out.

One footgun worth knowing: granular tokens have a Bypass 2FA option. It defaults to false, but when enabled it takes precedence over both account-level and package-level 2FA for publishing. If you enforce 2FA on a package and someone has a bypass token, your enforcement is not what you think it is.

Since August 2026 , bypass-2FA tokens can no longer perform account-identity or governance actions — changing email or password, touching 2FA config, managing tokens, adding maintainers. Those always require an interactive challenge. They can still publish directly.

Compromised accounts get a cooling-off period

Since June 2026, high-impact npm accounts drop into read-only mode for 72 hours when the email changes or a 2FA recovery code is used. Phishing is how these campaigns start; this buys the real maintainer time to recover before the account can publish.

What is still opt-in

Defaults handle the last attack. These are what you turn on yourself.

Trusted publishing

OIDC between npm and your CI provider. A named workflow is authorised to publish. Each publish mints a short-lived, signed credential that cannot be extracted from logs or reused.


permissions:

  id-token: write # required for OIDC

  contents: read

steps:

  - uses: actions/checkout@v6

  - uses: actions/setup-node@v6

    with:

      node-version: '24'

      registry-url: 'https://registry.npmjs.org'

      package-manager-cache: false # never cache in release builds

  - run: npm ci

  - run: npm test

  - run: npm publish

Constraints to plan around:

npm CLI 11.5.1+ , Node 22.14.0+
GitHub Actions, GitLab CI/CD, and CircleCI since April 2026
Cloud-hosted runners only — self-hosted is not supported
Up to 10 trusted publishers per package

Same idea as killing service account keys with Workload Identity Federation: stop storing a long-lived credential, mint a short-lived one per run against a verified identity.

Publishing this way from GitHub Actions or GitLab CI/CD generates provenance attestations automatically — no --provenance flag. Not supported for CircleCI, and not generated for packages published from private repositories , even when the package is public.

Staged publishing

Released May 2026, opt-in. Credentials alone no longer distribute a package: the version is staged until a maintainer approves it with 2FA , in the CLI or on npmjs.com.

This is the control that survives a fully compromised pipeline. An attacker with your CI credentials gets a staged version and a notification to a human, not a release.

Close the doors you stopped using

Setting up trusted publishing while the old automation token stays valid gains you little. Once the new flow works:

Package Settings → Publishing access → “Require two-factor authentication and disallow tokens”
Revoke the automation tokens you no longer need

And when configuring 2FA, npm’s guidance is explicit: WebAuthn, not TOTP. TOTP codes are phishable.

Watch what leaves your runner

GitHub’s Actions network firewall is in technical preview and logs all outbound traffic from workflow runs, so you can spot a job suddenly talking to a domain it has never talked to before.

This is the only item here that is detection rather than prevention, which makes it disproportionately valuable.

What none of this fixes

The section the vendor posts skip.

A compromised maintainer can still publish malicious code. Trusted publishing proves the package came from the right workflow in the right repository. It says nothing about whether that repository’s code is benign. Given commit access, provenance will faithfully attest to a malicious build.

Install scripts are not the only execution path. npm v12 closing them raises the cost of the current pattern. It does nothing if the payload is in the library you import and run.

Cooldowns are a trade, not a win. You accept a window running a version with a published vulnerability, to avoid being first to run a malicious one. Usually correct. Still a trade — which is exactly why Dependabot exempts security updates.

Almost none of this is detection. Every control above lowers the odds of executing malicious code. Only egress monitoring tells you that you already did. Assume the answer might be yes, and know how fast you can rotate every secret a build job can see.

Where to start

Control	Effort	Status
Move to npm v12 (install scripts off by default)	Hours	Default once upgraded
Dependabot cooldown	None	Already on
Read-only tokens for installs; no publish token in build jobs	Hours	On you
Trusted publishing + disallow tokens	Hours	Opt-in
Staged publishing	Hours	Opt-in
`minimumReleaseAge` (pnpm)	Hours	Opt-in
Audit granular tokens for the Bypass 2FA flag	Minutes	On you
WebAuthn instead of TOTP	Minutes	On you
Egress monitoring on CI runners	Days	Preview

Two things this week: upgrade to npm v12, or set ignore-scripts until you can , and get publish tokens out of every job that also installs dependencies. That covers the path Shai-Hulud actually used.

The bottom line

The 2025 advice was “do these things yourself because nobody else will”. Through 2026 the ecosystem made the two highest-impact ones — no install scripts, no instant updates — the default.

That is real progress, and it also means the remaining risk has moved. It now sits in the things still switched off: trusted publishing, staged publishing, and any idea of what your build machines talk to.

npm audit will keep telling you the tree is clean. It is answering a narrower question than the one you should be asking.

Originally published at alekseialeinikov.com

npm-Lieferkettenangriffe abwehren: Was wirklich hilft

Aleksei Aleinikov — Wed, 09 Sep 2026 09:00:00 +0000

Wenn Sie zuletzt nach dem Shai-Hulud-Wurm über npm-Lieferkettensicherheit gelesen haben, ist Ihr mentales Modell ein Jahr alt. 2026 kam vieles dazu, und ein Teil der damals überall empfohlenen Maßnahmen erledigt npm inzwischen selbst.

Hier steht, was heute tatsächlich gilt: was Sie geschenkt bekommen, was weiterhin optional ist, und was niemand für Sie löst.

Der Angriff, auf den das alles antwortet

GitHub wurde am 14. September 2025 über den Shai-Hulud -Angriff informiert. Die Wiederholung lohnt, weil jede Maßnahme unten von ihm geprägt ist:

Einstieg über kompromittierte Maintainer-Konten , nicht über eine Paketschwachstelle.
Eingeschleust wurden bösartige Post-Install-Skripte in populäre Pakete.
Der Code war selbstreplizierend — ein Wurm.
Gestohlen wurden mehrere Arten von Geheimnissen , nicht nur npm-Tokens.

GitHub entfernte über 500 kompromittierte Pakete und blockierte Uploads, die den Indicators of Compromise entsprachen.

Jedes beteiligte Paket war eines, das Sie installieren wollten, von einem Maintainer mit gutem Ruf, in einer unauffälligen Versionsnummer.

Warum Ihr Scanner „sauber” meldete

npm audit gleicht Ihren Abhängigkeitsbaum mit einer Advisory-Datenbank ab. Damit ein Befund existiert, muss ihn zuerst jemand entdecken, melden und veröffentlichen.

Eine vor zwanzig Minuten publizierte Schadversion hat davon nichts durchlaufen. Kein Advisory, keine Übereinstimmung, sauberer Bericht.

Eine ehrliche Aktualisierung: Im August 2026 hat GitHub die Malicious-Packages-Daten der OpenSSF in die Advisory-Datenbank eingebunden. Malware-Advisories stehen jetzt neben CVEs, die Lücke ist kleiner als zuvor.

Geschlossen ist sie nicht. Ein Advisory hinkt dem Angriff weiterhin hinterher, und sich in dieser Verzögerung auszubreiten ist das gesamte Geschäftsmodell. Lassen Sie npm audit laufen — hören Sie nur auf, ein sauberes Ergebnis als Beweis Ihrer Unversehrtheit zu lesen.

Was Sie jetzt standardmäßig bekommen

Das ist der Teil, der sich geändert hat — und der Grund, warum die meisten Ratschläge aus 2025 neu gelesen werden müssen.

npm v12 deaktiviert Install-Skripte

Im Juni 2026 als Breaking Change angekündigt: npm v12 deaktiviert Install-Skripte standardmäßig. Angreifer nutzten sie, um Zugangsdaten schon bei der Installation abzuziehen, statt darauf zu warten, dass Ihr Code irgendetwas importiert. Reaktivieren lässt sich das durch gezielte Freigabe einzelner Skripte.

Dieselbe Änderung blockiert Abhängigkeiten über Git- oder Remote-URLs und schließt damit einen weiteren Ausführungspfad zur Installationszeit.

Das ist die wichtigste Zeile dieses Artikels. Genau der Vektor, den Shai-Hulud nutzte, ist standardmäßig aus — sofern Sie auf v12 sind.

Falls nicht, bleibt es Ihre Aufgabe:

Terminal window


npm ci --ignore-scripts

Oder in .npmrc:

ignore-scripts=true

Die ehrlichen Kosten: Pakete mit nativen Bestandteilen brauchen ihren Build-Schritt. Ein pauschales Verbot in einem großen Monorepo bricht Installationen. Standardmäßig verbieten, Ausnahmen freigeben — dieses Modell fährt pnpm seit Längerem über allowBuilds, mit dangerouslyAllowAllBuilds für den kompletten Ausstieg. Der Name verrät, was die Maintainer davon halten.

Dependabot wartet drei Tage

Seit Juli 2026 warten Dependabot-Versionsupdates, bis ein Release mindestens drei Tage alt ist , bevor ein Pull Request geöffnet wird. Erkennungssignale bekommen so einen Vorsprung. Standardmäßig aktiv , und Sicherheitsupdates sind ausgenommen — kritische Fixes verzögern sich nicht.

Angreifer leben von Geschwindigkeit. Das nimmt sie ihnen, und kostet Sie praktisch nichts.

pnpm setzt eine strengere Variante schon bei der Installation durch:

pnpm-workspace.yaml


minimumReleaseAge: 10080 # Minuten — eine Woche

Eine jüngere Version kommt gar nicht erst infrage. minimumReleaseAgeExclude deckt die Pakete ab, die Sie sofort wollen.

Klassische Tokens gibt es nicht mehr

Die npm-Dokumentation ist eindeutig: Seit November 2025 werden nur noch granulare Zugriffstokens unterstützt, Legacy-Tokens wurden entfernt.

Granulare Tokens lassen sich nach Paket, Scope und Organisation eingrenzen, auf IP-Bereiche beschränken und mit einem Ablaufdatum von mindestens einem Tag versehen.

Ein Fallstrick, den man kennen sollte: Granulare Tokens haben eine Option Bypass 2FA. Sie ist standardmäßig aus, hebt aber im aktivierten Zustand sowohl konto- als auch paketweite 2FA beim Veröffentlichen aus. Wenn Sie 2FA für ein Paket erzwingen und jemand ein Bypass-Token besitzt, ist Ihre Durchsetzung nicht das, wofür Sie sie halten.

Seit August 2026 können Bypass-2FA-Tokens keine Konto- oder Governance-Aktionen mehr ausführen — E-Mail oder Passwort ändern, 2FA-Konfiguration anfassen, Tokens verwalten, Maintainer hinzufügen. Dafür ist immer eine interaktive Challenge nötig. Direkt veröffentlichen dürfen sie weiterhin.

Kompromittierte Konten bekommen eine Abkühlphase

Seit Juni 2026 gehen npm-Konten mit hoher Reichweite für 72 Stunden in einen Nur-Lese-Modus , wenn die E-Mail geändert oder ein 2FA-Wiederherstellungscode benutzt wird. Phishing steht am Anfang dieser Kampagnen; das verschafft dem echten Maintainer Zeit zur Rückgewinnung, bevor das Konto veröffentlichen kann.

Was weiterhin optional ist

Standardeinstellungen decken den letzten Angriff ab. Das Folgende schalten Sie selbst ein.

Trusted Publishing

OIDC zwischen npm und Ihrem CI-Anbieter. Ein benannter Workflow ist zum Veröffentlichen autorisiert. Jede Veröffentlichung erzeugt ein kurzlebiges, signiertes Credential, das sich weder aus Logs extrahieren noch wiederverwenden lässt.


permissions:

  id-token: write # für OIDC erforderlich

  contents: read

steps:

  - uses: actions/checkout@v6

  - uses: actions/setup-node@v6

    with:

      node-version: '24'

      registry-url: 'https://registry.npmjs.org'

      package-manager-cache: false # in Release-Builds nie cachen

  - run: npm ci

  - run: npm test

  - run: npm publish

Randbedingungen für die Planung:

npm CLI 11.5.1+ , Node 22.14.0+
GitHub Actions, GitLab CI/CD und CircleCI seit April 2026
Nur cloud-gehostete Runner — selbst gehostete werden nicht unterstützt
Bis zu 10 Trusted Publisher pro Paket

Dieselbe Idee wie beim Abschaffen von Service-Account-Schlüsseln mit Workload Identity Federation: kein langlebiges Credential speichern, sondern pro Lauf ein kurzlebiges gegen eine verifizierte Identität ausstellen.

Wer so aus GitHub Actions oder GitLab CI/CD veröffentlicht, erhält Provenance-Attestierungen automatisch — ohne --provenance. Für CircleCI nicht unterstützt, und für Pakete aus privaten Repositories wird keine erzeugt, selbst wenn das Paket öffentlich ist.

Staged Publishing

Mai 2026, optional. Credentials allein verteilen kein Paket mehr: Die Version bleibt im Staging, bis ein Maintainer sie mit 2FA freigibt , in der CLI oder auf npmjs.com.

Das ist die Maßnahme, die eine vollständig kompromittierte Pipeline überlebt. Ein Angreifer mit Ihren CI-Credentials bekommt eine gestagte Version und eine Benachrichtigung an einen Menschen — kein Release.

Die nicht mehr genutzten Türen schließen

Trusted Publishing einzurichten und den alten Automation-Token gültig zu lassen, bringt wenig. Sobald der neue Ablauf läuft:

Package Settings → Publishing access → „Require two-factor authentication and disallow tokens”
Nicht mehr benötigte Automation-Tokens widerrufen

Und bei der 2FA-Einrichtung ist npms Empfehlung eindeutig: WebAuthn statt TOTP. TOTP-Codes sind phishbar.

Beobachten, was den Runner verlässt

GitHubs Actions Network Firewall ist in der Technical Preview und protokolliert den gesamten ausgehenden Verkehr von Workflow-Läufen — Sie sehen also, wenn ein Job plötzlich mit einer Domain spricht, mit der er nie zuvor gesprochen hat.

Das ist der einzige Punkt hier, der Erkennung statt Prävention leistet, und deshalb überproportional wertvoll.

Was all das nicht löst

Der Abschnitt, den Hersteller-Posts weglassen.

Ein kompromittierter Maintainer kann weiterhin Schadcode veröffentlichen. Trusted Publishing belegt, dass das Paket aus dem richtigen Workflow im richtigen Repository kam. Über die Gutartigkeit des Codes sagt es nichts. Mit Commit-Zugriff attestiert die Provenance getreulich einen bösartigen Build.

Install-Skripte sind nicht der einzige Ausführungspfad. Dass npm v12 sie schließt, verteuert das aktuelle Muster. Gegen eine Nutzlast in der Bibliothek, die Sie importieren und ausführen, hilft es nicht.

Cooldowns sind ein Kompromiss, kein Gewinn. Sie akzeptieren ein Fenster mit einer bekannt verwundbaren Version, um nicht die Ersten mit einer bösartigen zu sein. Meist richtig. Ein Kompromiss bleibt es — genau deshalb nimmt Dependabot Sicherheitsupdates aus.

Fast nichts davon ist Erkennung. Jede Maßnahme senkt die Wahrscheinlichkeit, Schadcode auszuführen. Nur Egress-Monitoring sagt Ihnen, dass es bereits passiert ist. Gehen Sie davon aus, dass die Antwort ja lauten könnte — und wissen Sie, wie schnell Sie jedes Geheimnis rotieren können, das ein Build-Job sieht.

Womit anfangen

Maßnahme	Aufwand	Status
Auf npm v12 wechseln (Install-Skripte aus)	Stunden	Nach Upgrade Standard
Dependabot-Cooldown	Keiner	Bereits aktiv
Nur-Lese-Tokens fürs Installieren; kein Publish-Token im Build-Job	Stunden	Bei Ihnen
Trusted Publishing + Tokens verbieten	Stunden	Optional
Staged Publishing	Stunden	Optional
`minimumReleaseAge` (pnpm)	Stunden	Optional
Granulare Tokens auf Bypass-2FA prüfen	Minuten	Bei Ihnen
WebAuthn statt TOTP	Minuten	Bei Ihnen
Egress-Monitoring auf CI-Runnern	Tage	Preview

Zwei Dinge diese Woche: auf npm v12 wechseln oder bis dahin ignore-scripts setzen , und Publish-Tokens aus jedem Job entfernen, der auch Abhängigkeiten installiert. Damit ist der Weg abgedeckt, den Shai-Hulud tatsächlich genommen hat.

Das Fazit

Der Ratschlag von 2025 lautete: „Tun Sie das selbst, weil es sonst niemand tut.” Im Lauf von 2026 hat das Ökosystem die beiden wirksamsten Punkte — keine Install-Skripte, keine sofortigen Updates — zum Standard gemacht.

Das ist echter Fortschritt. Es bedeutet aber auch, dass sich das verbleibende Risiko verschoben hat: Es sitzt jetzt in dem, was weiterhin ausgeschaltet ist — Trusted Publishing, Staged Publishing und jede Vorstellung davon, mit wem Ihre Build-Maschinen sprechen.

npm audit wird Ihnen weiterhin sagen, der Baum sei sauber. Es beantwortet eine engere Frage als die, die Sie stellen sollten.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Iceberg vs. Delta Lake 2026: Ein verständlicher Leitfaden zur Auswahl

Aleksei Aleinikov — Tue, 08 Sep 2026 09:00:00 +0000

Die meisten Artikel über Iceberg und Delta Lake beginnen mit einem Funktionsvergleich. Das ist der falsche Anfang — denn 2026 sehen die Funktionslisten fast identisch aus, und weil den meisten, die diese Frage stellen, nie erklärt wurde, was ein Tabellenformat überhaupt ist.

Fangen wir also dort an, in einfacher Sprache, und vergleichen erst danach.

Was ein Tabellenformat wirklich ist

Sie haben einen Ordner im Objektspeicher. Darin liegen ein paar tausend Parquet-Dateien. Jemand nennt das „eine Tabelle“.

Das ist keine Tabelle. Das ist ein Ordner. Und daraus folgen drei echte Probleme:

Niemand ist sich einig, was drin ist. Eine Query-Engine muss den Ordner auflisten, um es herauszufinden. Schreibt ein Job gerade neue Dateien, sieht ein Leser sie und ein anderer nicht.

Sie können nichts sicher ändern. Eine Zeile zu löschen bedeutet, eine Datei neu zu schreiben. Tauschen Sie sie aus, während ein Leser mitten im Scan ist, sind die Ergebnisse falsch.

Sie können nicht zurück. Überschreiben Sie die Datei von gestern, ist gestern weg.

Ein Tabellenformat ist ein Regelwerk, das genau das löst. Es ergänzt eine Metadatenschicht, die verfolgt, welche Dateien zur Tabelle gehören, wie das Schema aussieht und wie die Tabelle zu jedem Zeitpunkt aussah. Leser fragen die Metadaten, nicht den Ordner.

Mehr ist es nicht. Apache Iceberg und Delta Lake sind zwei konkurrierende Regelwerke für dieselbe Aufgabe. Die Daten darunter sind in beiden Fällen weiterhin Parquet.

Die Antwort in 30 Sekunden

Falls Sie hier aufhören wollen:

Schon auf Databricks? Delta Lake. Es ist das native Format, die Integration ist dort am tiefsten.
Maximale Engine- und Anbieterunabhängigkeit? Iceberg. Es hat die breiteste Streuung unabhängiger Engines und Kataloge.
Neuanfang ohne starke Bindung? Iceberg ist 2026 die sicherere Voreinstellung, weil mehr unabhängige Engines es nativ sprechen.
Tief in Delta und besorgt wegen Lock-in? Möglicherweise müssen Sie gar nicht wechseln — siehe UniForm weiter unten.

Alles Weitere ist die Begründung.

Woher sie kommen, und warum das noch zählt

Dieser Teil erklärt die meisten Unterschiede.

Iceberg ist ein Projekt der Apache Software Foundation. ASF-Governance bedeutet, dass kein einzelner Anbieter die Spezifikation kontrolliert — und das zeigt sich im Ökosystem: BigQuery, Snowflake, Redshift, Athena, Trino, ClickHouse, DuckDB, Dremio, StarRocks, Doris, Druid, Firebolt und Microsoft OneLake lesen es alle, und die Katalogschicht hat mehrere unabhängige Implementierungen, darunter Apache Polaris, Apache Gravitino, AWS Glue, Nessie und Lakekeeper.

Delta Lake entstand bei Databricks und wurde 2019 zu einem Projekt der Linux Foundation. Das Projekt schreibt unmissverständlich, es sei „ein unabhängiges Open-Source-Projekt und wird nicht von einem einzelnen Unternehmen kontrolliert“, und nennt über 190 Entwickler aus mehr als 70 Organisationen. Sein Schwerpunkt liegt aber weiterhin bei Databricks, und die aktivste jüngere Entwicklung — die Unity Catalog Delta APIs — steht Databricks nahe.

Was das praktisch bedeutet: Wenn Ihre Sorge lautet „kann ich meine eigenen Daten in fünf Jahren mit einem Werkzeug lesen, das ich noch nicht gewählt habe“, ist Icebergs Governance die konservativere Wette. Ist Ihre Plattform ohnehin Databricks, ist diese Sorge weitgehend theoretisch und Delta bietet den besseren Alltag.

Was tatsächlich gleich ist

Mehr, als das Marketing nahelegt. Beide bieten:

Fähigkeit	Was das heißt
ACID-Transaktionen	Schreiber zerstören sich nicht gegenseitig; Leser sehen einen konsistenten Snapshot
Time Travel	Die Tabelle abfragen, wie sie gestern aussah; einen fehlerhaften Ladelauf zurückrollen
Schema-Evolution	Spalten hinzufügen, umbenennen, löschen und umsortieren, ohne Daten neu zu schreiben
Zeilenweise Löschungen und Updates	Einzelne Zeilen ändern, ohne ganze Dateien neu zu schreiben
Streaming und Batch	Dieselbe Tabelle bedient beides
Parquet darunter	Ihre eigentlichen Datendateien sind in beiden Fällen dieselben

Wenn Ihnen jemand eines davon als Alleinstellungsmerkmal verkauft, verkauft er Ihnen etwas.

Was tatsächlich anders ist

Drei Dinge unterscheiden sich wirklich.

1. Iceberg verbirgt die Partitionierung, Delta nicht.

Das ist Icebergs nützlichstes Alleinstellungsmerkmal und das, dessen Verständnis sich am meisten lohnt.

In älteren Systemen musste eine Abfrage explizit auf die Partitionsspalte filtern, sonst wurde alles gescannt. Nutzer mussten das physische Layout kennen.

Iceberg hinterlegt die Transformation — „partitioniere nach Tag dieser Zeitstempelspalte“ — als Tabellenkonfiguration. Sie schreiben einen normalen Filter auf den Zeitstempel, und Iceberg leitet den Partitionsfilter ab und überspringt Dateien für Sie.

Noch besser: Es unterstützt Partition Evolution. Beginnen Sie mit Monatspartitionen, stellen Sie fest, dass die Daten gewachsen sind, wechseln Sie auf Tage — ohne die bestehenden Daten neu zu schreiben. Alte Dateien behalten ihr altes Schema, neue nutzen das neue, und Abfragen funktionieren weiter, weil Filter abgeleitet und nicht fest verdrahtet sind.

2. Delta beantwortet Interoperabilität mit UniForm.

Deltas Antwort auf „aber alle anderen nutzen Iceberg“ ist das Delta Universal Format. UniForm erlaubt es, Delta-Tabellen mit Iceberg- und Hudi-Clients zu lesen.

Das ist ein ausgesprochen pragmatischer Zug. Hat Ihre Organisation vor drei Jahren auf Delta standardisiert, brauchen Sie nicht zwingend ein Migrationsprojekt — womöglich genügt es, UniForm einzuschalten und Iceberg-sprechende Engines lesen zu lassen, was ohnehin da ist.

3. Delta liefert einen Kernel, den Engines einbetten.

Delta pflegt einen Kernel, unter anderem in Rust, den andere Engines einbetten können, statt das Protokoll neu zu implementieren. ClickHouse hat den Rust Delta Kernel dieses Jahr integriert. Das senkt die Hürde für neue Engines, Delta korrekt zu unterstützen — wichtig, weil in Protokoll-Neuimplementierungen die subtilen Fehler wohnen.

Was tatsächlich entscheidet

Hier kommt der Teil, den die meisten Vergleiche auslassen.

Sie werden Ihr Tabellenformat leichter wechseln als Ihren Katalog.

Der Katalog verfolgt, welche Tabellen existieren, wo deren Metadaten liegen und wer sie lesen darf. Iceberg hat genau dafür eine REST-Catalog-Spezifikation, um das zu entkoppeln, und es gibt mehrere Implementierungen. Deltas jüngste Arbeit dreht sich um die Unity Catalog Delta APIs.

Ihr Katalog hängt an Ihrem Berechtigungsmodell, Ihrem Lineage-Tooling, Ihrer CI und jeder Pipeline, die Sie betreiben. Ein Tabellenformat zu migrieren ist ein dokumentiertes Verfahren — Iceberg veröffentlicht sogar einen Delta-Lake-Migrationsleitfaden. Einen Katalog zu migrieren ist ein Projekt.

Das ehrliche Entscheidungsverfahren lautet also:

Welcher Katalog wird diese Daten verwalten? Lautet die Antwort Unity Catalog, sind Sie bei Delta. Lautet sie Polaris, Glue, Gravitino, BigLake oder Nessie, sind Sie bei Iceberg.
Welche Engines müssen lesen? Listen Sie sie auf und prüfen Sie, welches Format jede nativ spricht — nicht über eine Brücke.
Erst dann schauen Sie auf Funktionen.

Wer direkt zu Schritt 3 springt, trifft eine Entscheidung, die Schritt 1 sechs Monate später still überstimmt.

Welche Spezifikationsversion

Erwähnenswert, weil es regelmäßig für Verwirrung sorgt.

Bei Iceberg sind die Spezifikationsversionen 1, 2 und 3 vollständig und von der Community übernommen. Version 3 brachte erweiterte Typen (Nanosekunden-Zeitstempel, Variant, Geometry und Geography), Standardwerte für Spalten, Row-Lineage-Tracking und binäre Deletion Vectors. Version 4 befindet sich in aktiver Entwicklung und wurde nicht formal übernommen — sie strukturiert Metadaten um und führt relative Pfade ein, damit Tabellen verschoben werden können, ohne Metadaten neu zu schreiben. Planen Sie noch nicht damit.

Bei Delta Lake ist die aktuelle Linie 4.4.0 auf Apache Spark 4.2.0.

Die Entscheidungstabelle

Ihre Situation	Wahl
Databricks ist Ihre Plattform	Delta Lake
Mehrere Query-Engines, mehrere Anbieter	Iceberg
BigQuery oder Snowflake als primäres Warehouse	Iceberg — beide lesen es nativ
Sie müssen die Partitionierung später ändern	Iceberg — Partition Evolution
Schon auf Delta, brauchen Iceberg-Leser	Bei Delta bleiben , UniForm aktivieren
Governance und Anbieterneutralität haben Priorität	Iceberg — ASF-Governance
Neuanfang, keine Randbedingungen	Iceberg — breitere native Unterstützung
Ihr Katalog ist Unity Catalog	Delta Lake — die Entscheidung ist bereits gefallen

Wenn Sie noch entscheiden, was über dem Tabellenformat sitzt: Der Warehouse-Vergleich in BigQuery vs. Snowflake behandelt die Schicht, die diese Tabellen konsumieren wird.

Das Fazit

Der Formatkrieg ist leiser, als die Blogposts vermuten lassen. Beide Formate erledigen dieselbe Kernaufgabe, beide sind produktionsreif, und die Interoperabilitätsschichten sorgen dafür, dass eine „falsche“ Wahl heilbar bleibt.

Nicht günstig heilbar sind dagegen eine Katalogentscheidung, eine Engine-Festlegung oder ein Berechtigungsmodell auf der falschen Annahme. Entscheiden Sie diese zuerst, dann entscheidet sich das Tabellenformat meist von selbst.

Und wenn Sie eine technische Sache mitnehmen: Hidden Partitioning und Partition Evolution sind der echte Iceberg-Vorteil. Nicht weil sie aufregend wären, sondern weil „wir haben das vor zwei Jahren falsch partitioniert und können es ohne Neuschreiben nicht korrigieren“ ein wirklich teurer Satz ist — und Iceberg ist dasjenige, das Ihnen erspart, ihn zu sagen.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Iceberg vs Delta Lake in 2026: A Plain Guide to Picking One

Aleksei Aleinikov — Tue, 08 Sep 2026 09:00:00 +0000

Most articles about Iceberg and Delta Lake start by comparing features. That is the wrong place to start, because in 2026 the feature lists look almost identical, and because most people asking the question have not been told what a table format actually is.

So let us start there, in plain language, and only then compare.

What a table format actually is

You have a folder in object storage. Inside are a few thousand Parquet files. Somebody calls this “a table”.

It is not a table. It is a folder. And that causes three real problems:

Nobody agrees what is in it. A query engine has to list the folder to find out. If a job is halfway through writing new files, one reader sees them and another does not.

You cannot safely change anything. Deleting a row means rewriting a file. If a reader is mid-scan when you swap it, results are wrong.

You cannot go back. Overwrite yesterday’s file and yesterday is gone.

A table format is a rulebook that fixes this. It adds a metadata layer that tracks which files belong to the table, what the schema is, and what the table looked like at each point in time. Readers ask the metadata, not the folder.

That is it. Apache Iceberg and Delta Lake are two competing rulebooks for the same job. The data underneath is still Parquet in both cases.

The 30-second answer

If you want to stop reading here:

Already on Databricks? Delta Lake. It is the native format and the integration is deepest there.
Want maximum engine and vendor independence? Iceberg. It has the broadest spread of independent engines and catalogs.
Starting fresh with no strong tie? Iceberg is the safer default in 2026, because more independent engines speak it natively.
Already deep in Delta and worried about lock-in? You may not need to move at all — see UniForm below.

Everything after this is the reasoning.

Where they came from, and why it still matters

This is the part that explains most of the differences.

Iceberg is an Apache Software Foundation project. ASF governance means no single vendor controls the spec, and that shows in the ecosystem: BigQuery, Snowflake, Redshift, Athena, Trino, ClickHouse, DuckDB, Dremio, StarRocks, Doris, Druid, Firebolt and Microsoft OneLake all read it, and the catalog layer has multiple independent implementations including Apache Polaris, Apache Gravitino, AWS Glue, Nessie and Lakekeeper.

Delta Lake came out of Databricks and became a Linux Foundation project in 2019. The project states plainly that it is “an independent open-source project and not controlled by any single company”, and it lists over 190 developers from more than 70 organisations. But its centre of gravity is still Databricks, and its most active recent development — the Unity Catalog Delta APIs — is Databricks-adjacent.

What this means in practice: if your worry is “will I be able to read my own data in five years with a tool I have not chosen yet”, Iceberg’s governance is the more conservative bet. If your platform is already Databricks, that worry is mostly theoretical and Delta gives you a better daily experience.

What is actually the same

More than the marketing suggests. Both give you:

Capability	What it means
ACID transactions	Writers do not corrupt each other; readers see a consistent snapshot
Time travel	Query the table as it looked yesterday; roll back a bad load
Schema evolution	Add, rename, drop and reorder columns without rewriting data
Row-level deletes and updates	Delete or update individual rows without rewriting whole files
Streaming and batch	The same table serves both
Parquet underneath	Your actual data files are the same in both

If someone tells you one of these is a differentiator, they are selling something.

What is actually different

Three things genuinely differ.

1. Iceberg hides partitioning; Delta does not.

This is Iceberg’s most useful distinctive feature and the one most worth understanding.

In older systems, if a table was partitioned by day, a query had to filter on the partition column explicitly or it would scan everything. Users had to know the physical layout.

Iceberg records the transform — “partition by day of this timestamp column” — as table configuration. You write a normal filter on the timestamp, and Iceberg derives the partition filter and skips files for you.

Better still, it supports partition evolution. Start partitioning by month, discover your data grew, switch to day — without rewriting the existing data. Old files keep their old scheme, new files use the new one, and queries still work because filters are derived, not hard-coded.

2. Delta answers interoperability with UniForm.

Delta’s response to “but everyone else uses Iceberg” is the Delta Universal Format. UniForm lets Delta tables be read by Iceberg and Hudi clients.

That is a genuinely pragmatic move. If your organisation standardised on Delta three years ago, you do not necessarily need a migration project — you may just need to turn on UniForm and let Iceberg-speaking engines read what you already have.

3. Delta ships a kernel that engines embed.

Delta maintains a Kernel, including a Rust implementation, that other engines can embed rather than reimplementing the protocol. ClickHouse integrated the Rust Delta Kernel this year. This lowers the cost of a new engine supporting Delta correctly, which matters because protocol reimplementation is where subtle bugs live.

The thing that actually decides it

Here is the part most comparisons skip.

You will change your table format more easily than you will change your catalog.

The catalog is what tracks which tables exist, where their metadata lives, and who is allowed to read them. Iceberg has a REST Catalog specification precisely to decouple this, and there are several implementations. Delta’s recent work centres on the Unity Catalog Delta APIs.

Your catalog is wired into your permission model, your lineage tooling, your CI, and every pipeline you run. Migrating a table format is a documented procedure — Iceberg even publishes a Delta Lake migration guide. Migrating a catalog is a project.

So the honest decision procedure is:

What catalog will govern this data? If the answer is Unity Catalog, you are on Delta. If it is Polaris, Glue, Gravitino, BigLake or Nessie, you are on Iceberg.
Which engines must read it? List them, then check which format each speaks natively rather than through a bridge.
Only then look at features.

If you skip to step 3 you will make a decision that step 1 quietly overrules six months later.

Which spec version to be on

Worth stating because it trips people up.

For Iceberg , spec versions 1, 2 and 3 are complete and adopted by the community. Version 3 added extended types (nanosecond timestamps, variant, geometry and geography), column default values, row lineage tracking and binary deletion vectors. Version 4 is under active development and has not been formally adopted — it restructures metadata and adds relative paths so tables can be relocated without rewriting metadata. Do not plan around v4 yet.

For Delta Lake , the current line is 4.4.0 on Apache Spark 4.2.0.

The decision table

Your situation	Pick
Databricks is your platform	Delta Lake
Multiple query engines, several vendors	Iceberg
BigQuery or Snowflake as primary warehouse	Iceberg — both read it natively
You need to change partitioning later	Iceberg — partition evolution
Already on Delta, need Iceberg readers	Stay on Delta , enable UniForm
Governance and vendor neutrality are the priority	Iceberg — ASF governance
Starting fresh, no constraints	Iceberg — broader native support
Your catalog is Unity Catalog	Delta Lake — the decision is already made

If you are still deciding what sits above the table format, the warehouse comparison in BigQuery vs Snowflake covers the layer that will consume these tables.

The bottom line

The format war is quieter than the blog posts suggest. Both formats do the same core job, both are production-grade, and the interoperability layers mean picking “wrong” is recoverable.

What is not recoverable cheaply is a catalog choice, an engine commitment, or a permission model built around the wrong assumption. Decide those first and the table format usually decides itself.

And if you take one technical thing away: hidden partitioning and partition evolution are the real Iceberg advantage. Not because they are exciting, but because “we partitioned this wrong two years ago and cannot fix it without a rewrite” is a genuinely expensive sentence, and Iceberg is the one that lets you avoid saying it.

Originally published at alekseialeinikov.com