Willkommen zu allesnurgecloud.com – Ausgabe #226
So, die letzte Woche war doch schon wieder maximal verrückt. Die USA greifen mit Israel den Iran an, Datacenter sind dann teilweise offline und Anthropic widersetzt sich der US Regierung und ist nun auf einer Supply Chain Risk Liste gelandet.
Das ist schon alles maximal verrückt – der Angriff und die Datacenter Outage hatte es nicht mehr in den NL geschafft, da ich den aus logistischen Gründen am Donnerstag Abend schon fertig hatte.
Daher verarbeite ich diese Themen dann auch mal erst eine Woche später – auch wenn du sie vielleicht schon bei X anderen Portalen gelesen hast.
Viel Spaß beim Lesen und wie immer freu ich mich über Feedback – gerne einfach Antworten, danke!
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 162 spreche ich mit Daniel Schreiber, der mit seinem Cloud-Backup-for-Podio 2.500€ MRR mit einem Backup Tool für ein SaaS Tool macht, da die Kunden eben auf Nummer sicher gehen wollen. Dazu baut er an einer einfach ins Deployment integrierbaren Translation Engine für deine Übersetzungsfiles. Das Tool heisst Doloc.io und lernt aus dem Kontext, was du für eine App baust und passt daher die Übersetzungen an. Auch diese Folge gibt es bei YouTube und wie immer bei Spotify, Apple und allen anderen Playern.
Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
Übrigens kannst Du meine Arbeit nun auf Patreon supporten, mir ein Bier ausgeben oder mal auf meiner Amazon-Wunschliste vorbeischauen – Danke! Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen oder mir einfach ne E-Mail als Antwort auf den NL schicken.
allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
Claude-Code-Erfinder Boris Cherny: 30 PRs am Tag mit 5 parallelen Agents
Boris Cherny, Erfinder und Head of Claude Code bei Anthropic, war zu Gast im Pragmatic Engineer Podcast bei Gergely Orosz. Der Einblick in seinen Arbeitsalltag ist bemerkenswert: Cherny schickt 20–30 PRs pro Tag, indem er 5 parallele Claude-Instanzen in separaten Terminal-Tabs betreibt. „Once there is a good plan, it will one-shot the implementation almost every time.“ Die tägliche Arbeit hat sich damit verändert – weg von konzentriertem Single-Thread-Coding, hin zu schnellem Context-Switching zwischen parallelen Agents.
Technisch interessant: Die „Agentic Search“ in Claude Code basiert schlicht auf glob und grep – und schlug alle aufwändigeren Ansätze wie lokale Vektor-Datenbanken oder rekursives Model-basiertes Indexing. Die Inspiration kam von Instagram-Engineers bei Meta, die genauso suchten, als Click-to-Definition im internen Editor kaputt war.
Aus seiner Meta-Zeit bringt Cherny den kausalen Nachweis mit, dass saubere Codebasen die Engineering-Produktivität im zweistelligen Prozentbereich verbessern – das gelte auch für AI-generierten Code. Seine Regel: „Always make sure that when you start a migration, you finish the migration.“
Im Claude-Code-Team sind PRDs tot. PRDs – Product Requirements Documents – sind die klassischen Spezifikationsdokumente, in denen Produktteams vor der Entwicklung Features detailliert beschreiben. Cherny und sein Team ersetzen diese durch Dutzende funktionierender Prototypen vor dem Shipping:
„There’s just no way we could have shipped this if we started with static mocks and Figma or if we started with a PRD.“
Claude Cowork, das neue Desktop-Tool für Nicht-Entwickler, entstand in nur 10 Tagen. Der Großteil der Arbeit steckte dabei nicht in Produktlogik, sondern in Safety: Klassifikatoren, gehärtete VM, OS-Level-Schutz gegen versehentliches Löschen.
Chernys historische Analogie zum Schluss: Software Engineers könnten die Schreiber des Mittelalters sein – als der Buchdruck kam, verloren sie ihre Jobs, aber viele wurden Autoren, und der Markt für Geschriebenes wuchs weit über jede Vorstellung hinaus.
Maschinen produzieren Maschinen – ist echt teilweise verrückt, wie schnell es dann doch geht.
Building Claude Code with Boris Cherny
Drohnenangriffe treffen AWS-Rechenzentren
Am 1. März 2026 wurden AWS-Rechenzentren in den UAE und Bahrain durch Drohnenangriffe im Rahmen des Iran-Konflikts physisch beschädigt. Reuters berichtete, dass Objekte ein Datacenter trafen, Funken und ein Feuer auslösten. AWS bestätigte später: In den UAE wurden zwei von drei Availability Zones (mec1-az2 und mec1-az3) direkt getroffen, in Bahrain verursachte ein Einschlag in unmittelbarer Nähe einer Einrichtung Infrastrukturschäden. Die Aussage von AWS dazu: „These strikes have caused structural damage, disrupted power delivery, and in some cases required fire suppression activities that resulted in additional water damage.“
Die Auswirkungen sind massiv: über 110 AWS-Services in der ME-CENTRAL-1-Region betroffen – 25 davon als „Disrupted“, 34 als „Degraded“. S3, DynamoDB, EC2, Lambda, RDS, die Management Console – praktisch alles (AWS Status Page zeigt es aktuell noch an, gibt es einen Deeplink, der bleibt?). S3 ist als regionaler Service ausgelegt, den Verlust einer einzelnen AZ zu überstehen – bei zwei gleichzeitig betroffenen Zonen stiegen die Fehlerraten drastisch. EC2-Launches wurden für die gesamte Region gedrosselt, die Recovery auf mindestens einen Tag geschätzt. Parallel zur physischen Wiederherstellung verfolgt AWS software-basierte Recovery-Pfade, die unabhängig vom Zustand der Gebäude funktionieren sollen.
AWS empfiehlt Kunden im Nahen Osten explizit, Disaster-Recovery-Pläne zu aktivieren, aus Remote-Backups in anderen Regionen wiederherzustellen und Traffic umzuleiten – empfohlen werden Regionen in den USA, Europa oder Asien-Pazifik. Eine ungewöhnlich direkte Aussage für einen Cloud-Provider, der normalerweise die Resilienz seiner eigenen Infrastruktur betont.
In Ausgabe #101 hatte ich nach dem Google-Cloud-Ausfall in Paris diskutiert, bei welchem Anbieter Availability Zones wirklich physisch getrennt sind – AWS garantiert das explizit. Gegen Drohnenangriffe auf zwei von drei AZs gleichzeitig hilft aber auch die beste physische Trennung innerhalb einer Region nicht.
Interessant an dem Ausfall, dass auch auf AWS basierende Provider wie beispielsweise Vercel Probleme hatten – da diese einfach nicht eingeplant hatten, dass eine ganze Region mal offline sein könnte. Das hat mich dann doch überrascht – sowas muss doch bei Game Days und einer Szenarienplanung irgendwo mal auf dem Backlog gelandet sein. Vermutlich ist es da auch einfach dann hängen geblieben.
Amazon cloud unit’s data centers in UAE, Bahrain damaged in drone strikes
Anzeige
DEVK Migrationsgeschichte: Von Opsgenie zu ilert
Die DEVK, eine der größten Versicherungen Deutschlands, berichtet über ihre Erfahrungen beim Wechsel von Opsgenie zu ilert.
ilert ist eine KI-basierte Plattform für Bereitschaftsmanagement, Incident Response und Statusseiten. Sie reduziert unnötige Unterbrechungen im gesamten Technologie-Stack und sorgt für strukturierte Abläufe im Incident Response Lebenszyklus. Als Stack-übergreifende Incident-Response-Ebene analysiert und löst die KI Incidents automatisch – Mitarbeiter werden nur dann benachrichtigt, wenn ihr Eingreifen wirklich erforderlich ist. Weltweit vertrauen Unternehmen wie REWE digital, Bertelsmann, Go Inspire, Lufthansa Systems und viele mehr auf ilert.
Nehme jetzt an unserem exklusiven Webinar „DEVK Migrationsgeschichte: Von Opsgenie zu ilert“ teil und erfahre mehr über:
- Das Incident-Management der DEVK: Einblicke in Umfang, Abläufe und Bedeutung
- Entscheidungsprozess: Warum die DEVK sich für ilert und gegen andere Lösungen entschieden hat
- Details zur Migration: Architektur, API, Objektzuordnung, Umsetzung von Alarmierungsregeln und gewonnene Erkenntnisse
- Feedback & Q&A: Erfahre mehr über die Erkenntnisse der DEVK nach der Migration und erhalte Antworten auf Deine Fragen direkt im Webinar.
Wenn Du vom Opsgenie EoL betroffen bist oder gerade Incident-Management-Lösungen evaluierst, bietet Dir dieses Webinar praktische Erkenntnisse und Tipps.
Melde Dich an und erhalte Einblicke aus erster Hand in den Ablauf der Migration bei der DEVK.
DEVK Migrationsgeschichte: Von Opsgenie zu ilert
OpenClaw Alternative nullclaw: AI-Assistant in 678 KB Zig
Das Open-Source-Projekt nullclaw sorgt für Aufsehen: Ein komplettes AI-Assistant-Framework in 100 % Zig, kompiliert zu einem 678 KB statischen Binary mit rund 1 MB RAM und unter 2 ms Startup. Kein Runtime, kein Garbage Collector, keine Abhängigkeiten außer libc – über 5.700 GitHub Stars in wenigen Wochen.
Der Benchmark-Vergleich gegen die etablierten Frameworks macht den Unterschied deutlich:
- OpenClaw (TypeScript): >1 GB RAM, >500s Startup, ~28 MB, braucht Mac-Mini-Class-Hardware – haha!
- NanoBot (Python): >100 MB RAM, >30s Startup, Script-basiert
- PicoClaw (Go): <10 MB RAM, <1s Startup, ~8 MB Binary
- ZeroClaw (Rust): <5 MB RAM, <10ms Startup, 3,4 MB Binary
- nullclaw (Zig): ~1 MB RAM, <8ms Startup, 678 KB, 3.230+ Tests, läuft auf $5-Hardware
Der Feature-Umfang ist für die Größe bemerkenswert: 23+ AI-Provider, 18 Chat-Kanäle (Telegram, Discord, Slack, WhatsApp, Signal, IRC, Nostr, Matrix), hybrides Memory mit SQLite (FTS5 + Vektor-Suche), Multi-Layer-Sandboxing, Hardware-Support für Arduino und Raspberry Pi, plus MCP, Subagents und Voice. Jedes Subsystem ist ein vtable-Interface – Provider, Channels, Tools und Memory lassen sich per Config austauschen, ohne Code anzufassen.
Ein paar Einschränkungen: Der Zig-Compiler ist auf die exakte Version 0.15.2 gepinnt, das Python-Ökosystem bietet nach wie vor den deutlich einfacheren Einstieg, und die eigentliche AI-Inferenz passiert weiterhin in der Cloud – nullclaw ist der Orchestrator, nicht das Modell. Für Edge-Computing und IoT-Szenarien sind die Zahlen trotzdem beeindruckend.
nullclaw – Fastest, smallest, and fully autonomous AI assistant infrastructure written in Zig
Niemand wird für einfache Lösungen befördert
Der Blogpost „Nobody Gets Promoted for Simplicity“ beschreibt ein Problem, das viele aus der Praxis kennen: Wer die einfachste Lösung baut, hat bei der nächsten Beförderung nichts zu erzählen – wer overengineert, liefert ein beeindruckendes Promotion Packet.
Das Beispiel ist einprägsam: Ingenieurin A löst ein Feature in 50 Zeilen Code, liefert in zwei Tagen und zieht weiter. Ingenieur B baut für ein ähnliches Feature eine Event-Driven Architecture mit Pub/Sub, Abstraktionslayer und Configuration Framework – braucht drei Wochen und erntet aufgeregte Emojis im Team-Chat. Bei der Beförderung schreibt sich B’s Arbeit praktisch von selbst: „Designed scalable event-driven architecture, introduced reusable abstraction layer.“ A’s Arbeit? „Implemented feature X.“ Drei Wörter. Ihre Lösung war besser, aber unsichtbar.
Das Problem beginnt nicht erst bei Promotions, sondern schon im Bewerbungsgespräch. Wer im System-Design-Interview eine einfache Lösung vorschlägt, wird so lange mit „What about scalability?“ bearbeitet, bis genug Boxen auf dem Whiteboard stehen. Die Lektion, die hängenbleibt: Einfach reicht nicht. In Design Reviews wiederholt sich das Muster – „Shouldn’t we future-proof this?“ führt zu Abstraktionen für Probleme, die vielleicht nie eintreten.
Der Autor unterscheidet klar zwischen berechtigter und unverdienter Komplexität. „We’re hitting database limits and need to shard“ ist etwas anderes als „We might hit limits in three years, so let’s shard now.“ Echte Seniorität bestehe nicht darin, mehr Tools und Patterns zu kennen, sondern zu wissen, wann man sie nicht einsetzt.
In Ausgabe #118 hatte ich den „Death by a Thousand Microservices“-Artikel vorgestellt, und in Ausgabe #142 die „Choose Boring Technology“-Bewegung – das Thema zieht sich wie ein roter Faden durch unsere Branche. Der Artikel liefert konkrete Vorschläge: Als Engineer die eigenen Entscheidungen gegen Komplexität dokumentieren, als Engineering Leader in Design Reviews nicht „Have we thought about scale?“ fragen, sondern „What’s the simplest version we could ship?“
Nobody Gets Promoted for Simplicity
Claude Code löscht Produktionsdatenbank
Alexey Grigorev, bekannt durch die DataTalks.Club-Community, beschreibt in einem schonungslos offenen Blogpost, wie sein Claude-Code-Agent die komplette Produktions-Infrastruktur der Kursplattform löschte – inklusive RDS-Datenbank mit 1,9 Millionen Zeilen aus 2,5 Jahren Kursbetrieb.
Die Verkettung: Grigorev wollte eine statische Website zu AWS migrieren und nutzte dafür ein bestehendes Terraform-Setup, das auch die Produktions-Infrastruktur verwaltete. Claude hatte davon abgeraten – Grigorev wollte aber $5–10/Monat sparen. Auf dem neuen Rechner fehlte das Terraform State File. Als Claude terraform plan ausführte, sah Terraform keine existierende Infrastruktur und wollte alles neu anlegen. Grigorev stoppte das apply, ließ dann aber Claude die entstandenen Duplikate aufräumen. Der Agent entschied sich für terraform destroy statt AWS CLI – und löschte mit dem alten, inzwischen entpackten State File nicht die Duplikate, sondern die komplette Produktionsumgebung: Datenbank, VPC, ECS-Cluster, Load Balancer, Bastion Host.
Schlimmer noch: Die automatischen RDS-Snapshots wurden mit gelöscht. Grigorev upgradete auf AWS Business Support (+10 % Cloud-Kosten) für schnellere Hilfe. AWS fand nach etwa 24 Stunden einen Snapshot, der im Console nicht sichtbar war, und stellte die Datenbank wieder her.
Seine Konsequenzen: Terraform State liegt jetzt auf S3, Deletion Protection ist auf AWS- und Terraform-Ebene aktiv, eine Lambda-Funktion testet jede Nacht die Wiederherstellung aus dem Backup, und Claude Code darf keine Terraform-Befehle mehr ausführen. Jeder Plan wird manuell geprüft, jede destruktive Aktion von ihm selbst ausgeführt.
In Ausgabe #59 hatte ich über Atlassians wochenlangen Ausfall berichtet, als ein fehlerhaftes Skript 400 Kunden-Sites löschte – das ist aber noch vor KI Einsatz gewesen, denke ich. Grigorevs Fall zeigt das gleiche Muster in der AI-Agent-Ära: terraform destroy mit falschem State und --auto-approve ist das neue fehlerhafte Löschskript – nur dass diesmal der Agent den Befehl absetzt.
Bald kommt „Zero Trust for Agents“ als neuer Trend 😉
How I Dropped Our Production Database and Now Pay 10% More for AWS
Anthropic setzt auf air-gapped ClickHouse für Observability
Anthropic, das Unternehmen hinter Claude, nutzt ClickHouse als zentrale Observability-Datenbank für die Entwicklung und den Betrieb seiner AI-Modelle. Maruth Goyal aus dem Anthropic-Team beschreibt, wie das bestehende Observability-System beim Nutzungsanstieg nach dem Launch von Claude 3.5 im Sommer 2024 an seine Grenzen stieß: „Your database catches fire. Queries start timing out. Engineers start getting frustrated. Money catches fire.“
Die Anforderungen waren anspruchsvoll: Echtzeit-Ingestion riesiger Datenmengen, schnelle analytische Abfragen über semi-strukturierte Daten – und das Ganze komplett innerhalb von Anthropics eigener, abgeschotteter Compute-Umgebung. Denn mit der Aktivierung von AI Safety Level 3 bei Claude Opus 4 überwacht Anthropic aggressiv jeglichen Datenabfluss aus seinen Clustern: „No data should leave Anthropic’s secure computing environment.“
Die Standard-Deployment-Optionen passten nicht. Open-Source-ClickHouse hätte zu viel operativen Aufwand bedeutet, ClickHouse Cloud lief nur auf der ClickHouse-Infrastruktur. Die Lösung: ein Hybrid-Deployment – die ClickHouse-Cloud-Architektur, aber komplett air-gapped innerhalb von Anthropics eigener Infrastruktur betrieben. Das Cluster läuft auf Kubernetes mit dem ClickHouse Operator, drei ZooKeeper-Replacements (je einer pro Availability Zone), horizontal skalierbaren Servern und Object Storage als Backend. Prometheus übernimmt das Monitoring, Vector die Ingestion.
Das Ergebnis: „I haven’t noticed the database running for a while“, sagte ein Engineer zu Goyal – genau das, was man von Infrastruktur hören möchte. Goyal betont zudem, dass ClickHouse eine wichtige Rolle bei der Entwicklung von Claude 4 spielte, weil das Training solcher Modelle konstante Echtzeit-Einblicke in Performance-Metriken erfordert.
In Ausgabe #192 und #194 hatten wir ClickStack und ClickHouses eigene Skalierung auf über 100 PB besprochen. Anthropics Case bestätigt den Trend: Für Observability bei diesen Datenmengen wird ClickHouse zunehmend zur Standardwahl – von Cloudflare über Uber bis hin zum Unternehmen hinter Claude.
How Anthropic is using ClickHouse to scale observability for the AI era
Bazel-Outage an Weihnachten: TLS-Zertifikate abgelaufen
Lorin Hochstein, dessen Blog „Surfing Complexity“ ich in Ausgabe #195 schon zum Thema Incident-Patterns zitiert hatte, nimmt sich in einem lesenswerten Beitrag ein Thema vor, das jeder Engineer kennt: abgelaufene TLS-Zertifikate.
Anlass war ein Vorfall beim Bazel-Team bei Google am zweiten Weihnachtstag 2025. Ein Zertifikat für bcr.bazel.build und releases.bazel.build lief ab und legte Build-Workflows weltweit lahm. Das Auto-Renewal-System war durch neue Subdomain-Ergänzungen blockiert worden, die Fehler-Benachrichtigungen funktionierten nicht – und die Team-Mitglieder, die sich dann darum kümmern mussten, hatten keinerlei Erfahrung mit dem Thema. Sie mussten erst Dokumentation lesen und Berechtigungen einholen, bevor sie überhaupt reagieren konnten.
Hochsteins Analyse geht über den einzelnen Vorfall hinaus. TLS-Zertifikate haben drei Eigenschaften, die sie besonders tückisch machen: Erstens sammelt man kaum operative Erfahrung mit ihnen, weil sie selten Probleme verursachen – und automatisiertes Renewal verstärkt diesen Effekt noch. Zweitens gibt es kein graduelles Versagen: In einer Minute funktioniert alles, in der nächsten schlägt jeder Request fehl. Drittens gibt es kein natürliches Signal an die Betreiber, dass ein Ablauf kurz bevorsteht – kein Staging, kein Canary, keine steigende Fehlerrate.
Oder in Hochsteins Worten: TLS-Zertifikate sind eine Technologie mit einem erwartbaren Failure-Mode (Ablauf), der den Blast Radius maximiert (100 % Hard Failure), ohne jegliches Feedback an die Betreiber. Und automatisiertes Renewal erhöht die Wahrscheinlichkeit, dass die Responder bei einem Ausfall keine Erfahrung mit dem manuellen Prozess haben.
Das passt gut zu seinem früheren Artikel über wiederkehrende Incident-Patterns: Abgelaufene Zertifikate wirken jedes Mal wie ein neues Problem, folgen aber dem immer gleichen „time-based behavior change“-Muster. Wer es ernst meint, monitort die Restlaufzeit seiner Zertifikate aktiv – ob per Prometheus, Icinga oder einem simplen Cronjob. Set-it-and-forget-it ist bei TLS-Zertifikaten keine Strategie, sondern ein Incident auf Termin.
The dangers of SSL certificates
Weg von Docker Hub mit Registry, Traefik und Watchtower
Entwickler Thomas Bandt beschreibt in einem Blogpost, wie er Docker Hub durch eine selbst gehostete Docker Registry ersetzt hat – und wie wenig Aufwand das tatsächlich bedeutet.
Das Setup besteht aus drei Komponenten: Die offizielle Docker Registry als Container mit htpasswd-Authentifizierung, Traefik für TLS-Terminierung mit Let’s Encrypt, und Watchtower für automatische Container-Updates. Watchtower überwacht laufende Container und aktualisiert sie automatisch, wenn ein neues Image in der Registry auftaucht. Deployments werden per einfachem HTTP-POST aus der CI/CD-Pipeline ausgelöst – build, push, trigger, fertig.
Die praktischen Fallstricke sind dabei lehrreicher als das Setup selbst. Watchtower erwartet die Registry-Credentials exakt unter /config.json im Container – nicht dort, wo man sie vermuten würde. Stimmt der Bearer-Token nicht, gibt Watchtower einen 401 zurück, aber curl meldet trotzdem Exit Code 0 – ohne -f Flag merkt die Pipeline nichts. Und die selbst gehostete Registry hat keine eingebaute Retention Policy: Jedes gepushte Image bleibt für immer, bis man selbst per API aufräumt und Garbage Collection anstößt.
Für Teams, die ohnehin eigene Server betreiben, ist das ein pragmatischer Ansatz: kein Docker-Hub-Account, keine Rate Limits, keine externe Abhängigkeit. Die gesamte Infrastruktur läuft auf einem einzelnen Server neben den Applikations-Containern – und die läuft dann auch, wenn DockerHub mal nicht geht, so wie neulich.
Self-Hosted Docker Registry: The 15-Minute Setup That Replaced Docker Hub
PostgreSQL-Indizes erklärt
Dalto Curvelano hat eine umfassende Einführung in PostgreSQL-Indizes geschrieben, die sich an Entwickler richtet, die zwar wissen, dass Indizes existieren, aber nicht genau verstehen, wie sie intern funktionieren und welche Trade-offs damit verbunden sind.
Der Artikel beginnt mit den Grundlagen: Wie PostgreSQL Daten auf der Festplatte in 8 KB großen Pages speichert, was ein Heap ist und wie die ctid (Current Tuple ID) als Zeiger auf die physische Position einer Zeile funktioniert. An einem praktischen Beispiel mit einer Million Zeilen demonstriert er den Unterschied: Ohne Index liest PostgreSQL alle 6.369 Pages und braucht 265 ms – mit BTree-Index sind es 4 Pages und 0,077 ms. Der Preis dafür: Der Index belegt mit 30 MB genauso viel Platz wie die Tabelle selbst.
Besonders nützlich ist die Übersicht der sechs Index-Typen, die PostgreSQL mitbringt. BTree ist der Default und einzige Typ für Primary/Unique Keys – er findet ein Element unter einer Million in 20 Vergleichen. Hash-Indizes sind deutlich kompakter bei langen Werten wie UUIDs oder URLs, unterstützen aber nur Gleichheitsabfragen. BRIN (Block Range Index) speichert nur Min/Max-Werte pro Seitenbereich und eignet sich für append-only Tabellen mit Zeitstempeln. GIN ist der richtige Typ für Suche in zusammengesetzten Daten wie JSONB, Arrays oder Volltext. GiST und SP-GiST sind Frameworks für geometrische Daten, IP-Ranges und ähnliches.
Darüber hinaus geht der Artikel auf fortgeschrittene Techniken ein: Partial Indexes, die nur eine Teilmenge der Zeilen indizieren und damit kleiner und schneller sind. Covering Indexes, die alle abgefragten Spalten enthalten und den Heap-Zugriff komplett vermeiden. Expression Indexes für Abfragen mit Funktionen wie LOWER(). Und das neue Skip Scan-Feature in PostgreSQL 18, das Multi-Column-Indizes auch nutzen kann, wenn die führende Spalte nicht im WHERE vorkommt.
Ein guter Überblick für alle, die über CREATE INDEX hinaus verstehen wollen, was unter der Haube passiert. In Ausgabe #190 hatten wir OpenAIs PostgreSQL-Setup besprochen, wo Table- und Index-Bloat als eines der Hauptprobleme genannt wurde – genau die Art von Verständnis, die dieser Artikel vermittelt, hilft dabei, solche Probleme zu vermeiden.
Introduction to PostgreSQL Indexes
Schmunzelecke
YAAB – Yet another Alien Breed ist ein Online Remake von Ben zum Amiga Klassiker – ich komm mit der Steuerung nicht ganz klar und finde es gar nicht mal so leicht – viel Spaß damit.
Ach und der Typ hier der liest noch nicht mein Newsletter – sonst wüsste er, dass man keine Mac Minis mehr für OpenClaw braucht.
💡 Link Tipps aus der Open Source Welt
gws – Eine CLI für alle Google Workspace APIs
gws ist eine einheitliche CLI für Google Workspace – Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin und mehr. Statt statischer Kommandos liest gws Googles Discovery Service zur Laufzeit und baut seine gesamte Kommandostruktur dynamisch. Neue API-Endpoints werden automatisch verfügbar.
Key Features:
- Dynamische API-Abdeckung: Alle Google Workspace APIs über eine CLI, automatisch aktuell durch Discovery Service
- Strukturierter Output: Alles ist JSON – ideal für Scripting und AI Agents
- AI Agent Integration: 100+ mitgelieferte Agent Skills, MCP Server für Claude Desktop/Gemini CLI/VS Code, Gemini CLI Extension
- Auth flexibel: OAuth (Desktop, Headless/CI, Multi-Account), Service Accounts, Token-Import, Credentials verschlüsselt im OS Keyring
- Pagination, Multipart Uploads, Dry-Run, Schema Introspection für jede Methode
- Model Armor: Optionale Response-Sanitization gegen Prompt Injection via Google Cloud
Geschrieben in Rust. Verfügbar via npm, Cargo, Nix oder als Binary. Kein offizielles Google-Produkt.
Extrem praktisch als universelle Schnittstelle zu Google Workspace – sowohl für manuelle Nutzung als auch als Tool-Backend für AI Agents. Der dynamische Discovery-Ansatz bedeutet, dass man nie auf CLI-Updates warten muss. Noch pre-v1.0, aber bereits sehr funktional.
https://github.com/googleworkspace/cli
pg_glimpse – Echtzeit PostgreSQL Monitoring im Terminal
pg_glimpse ist eine TUI für PostgreSQL-Monitoring: aktive Queries, Locks, Connections, Cache Performance, Replication Lag, Vacuum-Fortschritt und mehr – alles live im Terminal mit Sparkline-Graphen.
Key Features:
- Panels: Aktive Queries, Blocking Chains, Wait Events, Table Stats, Replication Lag, Vacuum Progress, Wraparound Risk, Index Stats, pg_stat_statements, WAL & I/O
- Live Graphen: Connections, Query-Zeiten, Cache Hit Ratio, TPS, Lock Count, WAL Rate als Sparklines
- Session Recording: Jede Session wird automatisch als JSONL aufgezeichnet – ideal für Incident Review und Post-Mortems. Replay mit variabler Geschwindigkeit (0.25x–8x)
- Bedienung: Fuzzy Filter, SQL Syntax Highlighting, Query Inspect, SQL in Clipboard kopieren, Zen Mode, Themes (Tokyo Night, Dracula, Nord, Solarized, Catppuccin)
- Verbindung: Connection Strings, URIs, Service Files, SSL/mTLS, Umgebungsvariablen – alles was PostgreSQL kann
Geschrieben in Rust mit ratatui. Verfügbar via Homebrew, Scoop oder Cargo.
Ein schlankes, schnelles PostgreSQL-Dashboard für den Terminal-Alltag. Das automatische Session Recording mit Replay ist ein hilfreiches Feature für Incident Investigation. Noch jung (v0.7.1, 73 Stars), aber funktional bereits echt umfangreich.
https://github.com/dlt/pg_glimpse
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: