Kategorie: Erklärer

  • Wenn Bausteine gemeinsam denken: Sakana AI und die kollektive Intelligenz der physischen Welt

    Wenn Bausteine gemeinsam denken: Sakana AI und die kollektive Intelligenz der physischen Welt

    Wie wissen einzelne Teile, was das Ganze ist?

    Du stehst in einem Raum voller Menschen. Jeder sieht nur die direkt neben sich. Niemand hat einen Überblick. Trotzdem wissen alle nach einer Weile, ob sie Teil einer Hochzeit, einer Protestkundgebung oder eines Konzerts sind. Sie tauschen lokale Informationen aus – Blicke, Gesten, Worte – und daraus entsteht ein gemeinsames Bild. Genau dieses Prinzip verfolgt Sakana AI in einer neuen Arbeit, die in Nature Communications erschienen ist. Statt Menschen verwendet sie kleine, einfache Bausteine – smarte Ziegelsteine, die sich durch lokale Kommunikation zu einer kollektiven Intelligenz zusammenschließen.

    Die Forscher nennen das System „Smart Cellular Bricks“. Jeder Brick besteht aus einem Würfel aus Leiterplatten mit Mikrocontroller, LED und sechs elektrischen Kontakten an den Seiten. Kein Baustein weiß, wo er sich befindet oder welche Form das Ganze hat. Er kommuniziert nur mit den unmittelbar benachbarten Steinen. Und dennoch erkennt die Ansammlung nach einigen Minuten, ob sie einen Flugzeugflügel, eine Gitarre, ein Boot oder einen Tisch darstellt. In der Praxis liegt die Genauigkeit bei nahezu 100 Prozent.

    Wie die Steine lernen: Neuronale Zelluläre Automaten

    Zelluläre Automaten funktionieren wie ein Schachbrett, bei dem jede Zelle ihren Zustand nach festen Regeln ändert – abhängig von den Nachbarzellen. Bei klassischen zellulären Automaten sind diese Regeln von Menschen erstellt. Bei neuronalen zellulären Automaten (NCA) werden sie von einem kleinen neuronalen Netz gelernt. Jeder Brick hat einen internen Zustand, der als Kurzzeitgedächtnis dient. Ein tiefes neuronales Netz aus 3D‑Faltungsschichten entscheidet, wie sich dieser Zustand von Schritt zu Schritt ändert. Das Netz wurde mit Tausenden von Beispielshapes trainiert, so dass es typische Strukturmerkmale einer Klasse abstrahieren kann – etwa dass ein Tisch eine große Platte und vier Beine hat, während ein Stuhl eine Rückenlehne besitzt.

    Die Steine kopieren nicht einfach eine perfekte Vorlage. Sie lernen, ganze Klassen von Formen zu unterscheiden. Ein Tisch mit fünf statt vier Beinen wird immer noch als Tisch erkannt. Ein Boot mit verschobener Brücke ebenso. Das System toleriert Variationen – ein Schritt von starrer Formerkennung zu flexiblem, biologischem Verhalten.

    Robustheit bei Ausfällen: Wie die Kolonie Fehler toleriert

    In Experimenten wurden bis zu 15 Prozent der Module deaktiviert. Die meisten Formen wurden trotzdem richtig erkannt. Ein Flugzeug verlor kaum an Genauigkeit. Anders eine Gitarre: Wenn ein Stein genau am Hals ausfällt, reißt die Kommunikation zwischen den beiden Hälften ab – das System scheitert. Das erinnert an biologische Systeme, die anfällig für bestimmte Engpässe sind. Solange die Netzstruktur nicht zerrissen wurde, zeigten die Bausteine bemerkenswerte Resilienz.

    Die Forscher testeten auch, ob die Steine Schäden bei Nachbarn erkennen können. Dafür trainierten sie das neuronale Netz zusätzlich, für jede der sechs Richtungen vorherzusagen, ob der dortige Stein defekt ist. Die Genauigkeit lag bei 94,8 Prozent, ohne dass die Formerkennung litt. Noch eindrucksvoller: Ausgehend von einem kleinen Keim aus wenigen Steinen können die Bausteine eine beschädigte Figur Schritt für Schritt nachwachsen lassen, indem sie neue Module in die Richtung anfordern, aus der sie ein Signal erhalten. Kein zentraler Plan – nur lokale Entscheidungen, die sich zur Wiederherstellung der gesamten Struktur aufschaukeln.

    Morphogen-ähnliche Muster: Die interne Kommunikation der Steine

    Die verborgenen Zustände des neuronalen Netzes ähneln der Embryonalentwicklung. In den ersten Zyklen entstehen Gradienten, die an biologische Morphogene erinnern – Substanzen, die Konzentrationsgradienten bilden und Zellen mitteilen, wo vorne und hinten ist. Auch die KI‑Bausteine erzeugen solche Muster: links‑rechts‑Gradienten, radiale Ausbreitungssignale und eine Kopf‑Schwanz‑Achse. Bei einem Stuhl beginnen viele Zellen mit der Vermutung „Tisch“. Dann breitet sich von der Rückenlehne ein Signal aus, das alle umstimmt. Dieses Ergebnis stammt von Milliarden gelernten Parametern, die genau diese Kommunikationsstrategien hervorgebracht haben.

    Die Forscher haben nur die Lernregel definiert. Das Netz hat selbstständig eine Art chemischer Kommunikation erfunden, die in der Natur seit Millionen von Jahren existiert.

    Von der Simulation in die Praxis

    Die Experimente fanden mit fast 200 physischen Bausteinen und in Simulationen mit bis zu 18.000 Blöcken statt. Das Verfahren skaliert gut. In Gittern von 64x64x64 Zellen mit komplexen Hohlformen wie einem Fisch oder einem Haus erkennt die Kolonie die Form zuverlässig – vorausgesetzt, das neuronale Netz hat genügend Kapazität. Dieser Zusammenhang ist berechenbar: Mit wachsender Auflösung und Komplexität steigt der Bedarf an Modellkapazität, die Performance bleibt stabil.

    Solche modularen, kollektiven Systeme könnten als intelligente Materialien oder rekonfigurierbare Roboter eingesetzt werden. Eine Brücke, die selbst erkennt, wo ein Stück fehlt, und das durch Anziehen neuer Module repariert. Ein Roboterarm, der sich aus Bausteinen zusammensetzt und ein Formgedächtnis hat. Oder eine Ansammlung winziger Sensoren, die ohne zentrale Steuerung die Umgebung kartieren.

    Dezentrale Intelligenz für physische Systeme

    Diese Arbeit zeigt, wie biologische Prinzipien in störungsanfälliger Hardware umgesetzt werden können. Intelligenz muss nicht in einem Superhirn sitzen. Sie kann aus dem Zusammenspiel vieler einfacher Teile entstehen. Das System beweist die Machbarkeit von lokaler, dezentraler und robuster kollektiver Intelligenz. Der Weg zu einer physischen Schwarmintelligenz ist noch weit, aber die Richtung stimmt: lokal, dezentral, robust. Und ein Haufen einfacher Würfel weiß plötzlich, dass er ein Flugzeug ist.

    Quelle: sakana.ai

  • Wie Microsoft KI-Agenten im Enterprise-Maßstab ausliefert

    Wie Microsoft KI-Agenten im Enterprise-Maßstab ausliefert

    Vom Chatbot zum handelnden Agenten

    Ein Chatbot beantwortet Fragen. Ein Agent führt Aktionen aus: Reise buchen, E-Mail schreiben, Ticket anlegen, Datenbankabfrage starten. Aus einem Gespräch wird eine Handlung. Falsche Handlungen wiegen schwerer als falsche Antworten. Microsofts KI-Agenten werden von über 80.000 Unternehmen genutzt; der Microsoft 365 Copilot hat mehr als 20 Millionen aktive Nutzer. Marco Casalaina, VP of Products bei Microsoft Core AI, berichtet aus den eingesetzten Systemen. Seine Erkenntnis: Wer einen Prototyp für produktionsreif hält, irrt.

    Der Wandel ist grundlegend. „Wir verlassen die Phase der reinen Fragebeantwortung“, sagt Casalaina. „2026 nutzen mehr Kunden Sprache als Frontend; das Chatbot-Zeitalter endet.“ Bisher tippte der Nutzer, der Bot antwortete. Jetzt handelt der Agent: Er bucht Meetings, führt Analysen durch, sendet E-Mails, legt Tickets an. Der Nutzer kann per Sprache interagieren. Mit „Voice Live“ wird ein Text-Agent ohne Neuentwicklung zum Sprachagenten.

    Warum der Prototyp in der Produktion scheitert

    Ein Agent lässt sich mit einem guten Sprachmodell an einem Nachmittag zusammenbauen. Der erste Prototyp überzeugt im Test. Die Testprompts laufen, die Demo gelingt, nach einer Woche steht die Pilotversion. Probleme zeigen sich erst mit echten Nutzern. Sie stellen unvorhergesehene Fragen. Dokumente veralten. Neue Randfälle erscheinen, die nicht im Testdatensatz waren. Ein Modell-Update ändert das Verhalten des Agenten subtil – unbemerkt, bis ein Kunde sich beschwert. Ohne Identitätskontrollen läuft der Agent als Systemkonto. Bei Fehlern fehlt die Prüfspur. Ohne Schutzmechanismen äußert er selbstbewusst Falsches. Ohne Beobachtbarkeit bleibt unklar, ob die Qualität steigt oder fällt. Im Prototyp zeigt sich keines dieser Probleme; in der Produktion treten alle auf.

    „Das Harness ist genauso wichtig wie das Modell“, sagt Casalaina. Harness bezeichnet die gesamte Infrastruktur um das Modell: Laufzeit, Werkzeuge, Kontextabruf, Identität, Absicherungen, Evaluatoren, Bereitstellungspipeline. Modelle ändern sich häufig; Datenbank-Updates sind meist einfacher. Jedes Modell hat eigene Eigenschaften, auf die das Harness reagieren muss. Als Anthropic Claude Opus 4.8 erschien, justierte das GitHub Copilot CLI Team sein Harness nach und führte Evaluierungen erneut durch, bevor sie das Modell auslieferten.

    Die fünf Schichten des Produktions-Harness

    Ein Produktionsagent besteht aus mehr als einem Sprachmodell. Microsoft nennt fünf Schichten, die zusammenspielen müssen.

    1. Die Inferenzschicht: Die unterste Schicht ist die einheitliche Schnittstelle zum Modellzugriff. Modelle bleiben austauschbar. Foundry unterstützt zahlreiche Modelle (OpenAI, Anthropic, xAI, DeepSeek, Microsofts MAI-Familie). Verschiedene Agenten benötigen verschiedene Modelle, und das passende Modell wechselt oft.

    2. Die Agentenlaufzeit (Agent Runtime): Die Laufzeitumgebung macht aus dem Modell einen Agenten. Sie steuert Orchestrierung, Werkzeugaufrufe, Gesprächszustand. Nicht jeder Schritt braucht das LLM; ein guter Agent schickt nur logisch anspruchsvolle Aufgaben an das Modell und erledigt andere wie Datenbanksuchen mit normalem Code. Framework-Neutralität ist wichtig: Ein Agent sollte zwischen Frameworks (z.B. LangChain, LangGraph, CrewAI) portierbar sein, ohne das Harness neu zu schreiben. Foundry unterstützt den Austausch.

    3. Observability und Governance: In der Produktion braucht die Organisation eine einheitliche Sicht auf alle Agenten. Dazu gehören Gesundheitsmetriken, Token-Verbrauch, Latenz, Drift-Erkennung und Projektübersichten für das Plattform-Team. Ohne diese Schicht bleiben Regressionen unsichtbar, Kosten steigen. Foundrys Control Plane liefert eine projektübergreifende Flottenübersicht und leitet Telemetriedaten an Azure Monitor und Application Insights weiter – die gleiche Pipeline wie für Infrastruktur-Alarme.

    4. Identitätsschicht: Wenn Agenten Aktionen ausführen, brauchen sie eigene Identitäten, Rollen und Prüfspuren. Ein fehlerhafter Agent sollte durch dieselben Zugriffskontrollen begrenzt werden wie ein fehlerhafter Mitarbeiter. Die Branche erweitert vorhandene Enterprise-Identitätssysteme um Agenten als neue Prinzipal-Klasse. Foundry erweitert Microsofts Entra zu diesem Zweck.

    5. Kontextschicht (Context Layer): Die Kontextschicht stellt sicher, dass der Agent richtig antwortet. Ohne guten Kontext halluziniert er – er antwortet selbstbewusst, aber falsch, weil er nicht erkennt, was er nicht weiß. Casalaina nennt die Bereitstellung des richtigen Kontexts eine der schwierigsten Aufgaben.

    Zwei Engineering-Ideen aus Foundry

    Erstens: Retrieval-as-a-Subagent. Der Kontextabruf wird als Unteragent modelliert, der Daten dynamisch abruft und aufbereitet, statt auf einer statischen Wissensdatenbank zu basieren. Das ermöglicht feinere Steuerung und Fehlerbehandlung.

    Zweitens: Agenten einen eigenen Platz zum Handeln geben. Mit einer Identität kann der Agent lesen und schreiben – Dokumente in SharePoint, Datensätze in Dynamics, E-Mails in Outlook. Microsoft hat die Agent-Identität in Entra etabliert, sodass der Agent als Akteur mit definierten Rechten und Prüfspur handelt.

    Evaluierung und kontinuierliche Verbesserung

    Microsoft bewertet Produktionsagenten mit ergebnisbasierten Kennzahlen nach einem Bewertungsraster (Rubric). Die Evaluierung läuft automatisiert: Der Agent bearbeitet einen Datensatz typischer Aufgaben, die Ergebnisse werden gegen eine vordefinierte Matrix gemessen. Die Messwerte fließen in eine automatische Verbesserungsschleife, in der das Harness selbstständig Anpassungen vornimmt – etwa die Gewichtung von Kontextquellen oder die Reihenfolge der Tool-Aufrufe. Der Prozess läuft kontinuierlich – Dokumente aktualisieren sich, neue Modelle erscheinen. Einmalige Evaluierung genügt nicht.

    Was das für andere Teams bedeutet

    Diese Lektionen lassen sich auf jedes Unternehmen übertragen: Erstens: Unterschätze die Komplexität des Modellumfelds nicht. Der Prototyp ist einfach, die Produktion schwer. Zweitens: Baue einen modularen Harness, der Modelle und Frameworks austauschbar hält. Drittens: Gib deinen Agenten eine Identität – sonst sind sie weder sicher noch prüfbar. Viertens: Investiere von Anfang an in Beobachtbarkeit und Evaluierung, nicht erst nach einem Vorfall.

    Quelle: blog.bytebytego.com

  • Open-Weight-Modelle dominieren 29 % des AI-Gateway-Traffics – Preise stabilisieren sich

    Open-Weight-Modelle dominieren 29 % des AI-Gateway-Traffics – Preise stabilisieren sich

    Laut Vercels AI-Gateway-Index vom Juli 2026 machten Open-Weight-Modelle 29 % des Gateway-Traffics aus – fast ein Drittel aller Produktions-KI-Anfragen läuft inzwischen über frei verfügbare Modelle wie Llama und Mistral. Gleichzeitig stiegen die Preise für Closed-Weight-Frontier-Modelle im Juni um 12 %, während günstigere Modelle den Rückgang ausglichen. Das Ergebnis: Der durchschnittliche Preis pro Token blieb stabil. Investitionen in KI wachsen weiter, doch Unternehmen werden strategischer im Modell-Mix.

    Quelle: Vercel AI Gateway

  • Algolia und MCP: Wie Sie in wenigen Minuten einen KI-fähigen MCP-Server für Ihre Suchindizes erstellen

    Algolia und MCP: Wie Sie in wenigen Minuten einen KI-fähigen MCP-Server für Ihre Suchindizes erstellen

    Sie betreiben eine technische Dokumentation, einen Blog oder einen E‑Commerce-Katalog mit Algolia als Such‑Backend. Ihre Daten sind sauber indexiert, die Suche funktioniert zuverlässig – aber immer dann, wenn ein KI‑Agent oder ein Sprachmodell auf diese Informationen zugreifen soll, müssen Sie eine separate Schnittstelle bauen, API‑Keys verwalten und Abfragen anpassen. Bislang war das so. Algolia hat vor Kurzem eine Funktion veröffentlicht, die diesen Aufwand reduziert: Sie verwandeln Ihren bestehenden Suchindex in einen vollwertigen MCP‑Server.

    Der Autor dieses Erfahrungsberichts, langjähriger Algolia‑Nutzer und Betreiber eines Blogs, stieß zufällig auf diese Möglichkeit. Er sprach mit Chuck Meyer, Developer Relations bei Algolia, über genau diesen Wunsch – und erfuhr, dass die Funktion bereits existiert. Folgt eine nüchterne Betrachtung, wie einfach die Einrichtung ist und welche konkreten Anwendungsfälle sich daraus ergeben.

    Was ist Algolia?

    Algolia ist eine Such‑as‑a‑Service‑Plattform. Sie erstellen einen oder mehrere Indizes, die die durchsuchbaren Inhalte repräsentieren: Text (Blogartikel, Dokumentation) oder Produktdaten (E‑Commerce). Über APIs, SDKs oder Plugins befüllen und aktualisieren Sie diesen Index, sobald sich Ihre lokalen Daten ändern. Das System ist schnell und lässt sich durch Einstellungen (Relevance‑Tuning, Facetten, Synonyme) an Ihre Anforderungen anpassen. Für einen einfachen Blog reichen oft wenige Zeilen JavaScript, um eine vollwertige Suche zu integrieren. Algolia ist der Motor, der Ihre Inhalte millisekundenschnell findbar macht.

    Was ist MCP und warum ist es nützlich?

    MCP steht für Model Context Protocol – ein Protokoll, das es KI‑Agenten (wie Claude, Cursor oder Google Gemini) ermöglicht, auf externe Werkzeuge und Datenquellen zuzugreifen. Wenn Sie einen MCP‑Server bereitstellen, kann ein Sprachmodell diesen Server ansprechen, um bestimmte Aktionen auszuführen: Suchen, APIs aufrufen, Daten zurückgeben. Der Server kümmert sich um Authentifizierung, Logik und die Formatierung der Antworten. Für eine Dokumentationsseite bedeutet das: Ein Nutzer kann in seinem AI‑Chat frei formulierte Fragen zu den Inhalten stellen, und der Agent ruft über den MCP‑Server die relevanten Suchergebnisse ab. Sie müssen keine komplexe Middleware schreiben.

    Der Autor nennt das Beispiel des Webflow‑MCP‑Servers, den er vor seiner Zeit bei Webflow kannte: Ein Agent konnte damit Webflow‑API‑Aufrufe tätigen, etwa „Welche Sites habe ich?“ und die Antworten in natürlicher Sprache zurückgeben. Dieses Prinzip lässt sich auf Algolia‑Indizes übertragen.

    Die Einrichtung: Fünf Minuten oder weniger

    Der Weg zum eigenen MCP‑Server ist kurz. Sie loggen sich in Ihr Algolia‑Dashboard ein und wählen die Anwendung aus, die einen oder mehrere Indizes enthält. Im Navigationsmenü klicken Sie auf „Generate AI“. Im Untermenü erscheint „MCP Servers / Public“. Dort finden Sie einen Button „Create Public MCP Server“.

    Nun wählen Sie die Indizes aus, die der Server verwenden soll, und vergeben einen Namen – der Autor vergab einen nichtssagenden Namen, aber das ist nebensächlich. Im nächsten Schritt legen Sie fest, welche Tools aktiviert werden sollen: Suche, Empfehlungen (sofern genutzt) und weitere. Der Autor aktivierte alle, weist aber darauf hin, nicht benötigte Tools zu deaktivieren, um Klarheit zu bewahren. Nach der Bestätigung erhalten Sie eine vollständige URL – die Adresse Ihres neuen MCP‑Servers. Fertig.

    Von dort folgen Sie dem gewohnten Prozess, um den MCP‑Server in Ihren AI‑Agenten zu integrieren. Der Autor testete es unter anderem in Cursor, indem er die URL in den Einstellungen für externe Tools hinzufügte. Keine zusätzliche Konfiguration, kein manuelles Mapping von API‑Endpunkten – der Server spricht sofort auf die vom Protokoll definierten Anfragen an.

    Externe Anwendung: Dokumentation für Ihre Nutzer

    Der erste große Anwendungsfall: Ihre öffentliche Dokumentation wird über den MCP‑Server für jeden KI‑Agenten nutzbar, der MCP unterstützt. Viele technische Produkte bieten das bereits an – auch Algolia selbst. Aber jetzt können Sie das Gleiche für Ihre eigenen Inhalte tun. Ein Entwickler, der in seinem Chat nach einer bestimmten Funktion sucht, bekommt präzise Antworten aus Ihrer Dokumentation, ohne die Website manuell durchsuchen zu müssen. Der Autor berichtet von einem Test mit dem Kommandozeilen‑Tool agy (basierend auf Googles Gemini): Die Frage „Suche in Rays MCP‑Server nach seiner Meinung zu React“ lieferte fast perfekt passende Ergebnisse – inklusive des erwarteten Kontexts.

    Interne Anwendung: Content‑Erstellung und Wissensmanagement

    Der zweite Use‑Case richtet sich an Content‑Creator, Redakteure und alle, die regelmäßig auf einen großen Bestand an bereits veröffentlichten Inhalten zurückgreifen müssen. Der Autor, selbst Betreiber eines Blogs, nutzt die Algolia‑Suche bereits, um schnell zu prüfen, ob er über ein Thema schon geschrieben hat. Mit dem MCP‑Server kann er darüber hinausgehende Fragen stellen: „Was empfehlen Sie für einen neuen Blogbeitrag basierend auf meinen bisherigen Artikeln?“ In einem Test mit Cursor schlug die Kombination aus Server und AI‑Agent tatsächlich den Beitrag vor, den er gerade schrieb – ein Zeichen dafür, dass die gelieferten Inhalte kontextuell relevant sind. Das eröffnet die Möglichkeit, bestehendes Wissen automatisiert in neue Inhalte einfließen zu lassen, Lücken zu identifizieren oder thematische Verknüpfungen herzustellen.

    Technische Details und Kosten

    Bemerkenswert ist, dass diese Funktion im Build‑Tier enthalten ist – dem kostenlosen Tarif von Algolia, der für viele kleinere und mittlere Projekte ausreicht. Der Autor betont, dass er die Grenzen des Free‑Tiers nie erreicht habe, obwohl er Algolia seit Jahren intensiv nutzt. Das spricht für ein großzügiges Kontingent. Die Einrichtung erfordert keinerlei zusätzliche Server‑Infrastruktur; der MCP‑Server wird vollständig von Algolia gehostet und über die generierte URL bereitgestellt. Alles, was Sie brauchen, ist ein Algolia‑Konto und ein Index mit Daten.

    Was das konkret bedeutet

    Die Integration von MCP‑Servern in Algolia zeigt, wie Plattformen ihre Leistungsfähigkeit öffnen, ohne den Nutzer mit Komplexität zu belasten. Statt einen eigenen Server aufzusetzen, Authentifizierungs‑Mechanismen zu implementieren und die MCP‑Spezifikation von Grund auf zu lernen, können Sie sich auf Ihre Inhalte konzentrieren. Die MCP‑Schnittstelle ist ein weiterer Kanal, über den Ihre Daten lebendig bleiben – nicht nur über die eigene Suchleiste, sondern auch über die Sprachmodelle, die Ihre Nutzer ohnehin verwenden.

    Der Autor resümiert, dass er die Funktion unterschätzt hatte – eine Fehleinschätzung, wie er zugibt. Für alle, die Algolia einsetzen und einen Schritt in Richtung KI‑gestützter Anwendungen gehen möchten, ist dieser MCP‑Server ein niedrigschwelliger Einstieg. Sie müssen kein Experte für maschinelles Lernen oder Server‑Architektur sein. Ein Klick, eine URL, und Ihr Index spricht mit der KI.

    Loggen Sie sich in Ihr Algolia‑Dashboard ein, suchen Sie den Menüpunkt „Generate AI“ und erstellen Sie Ihren ersten öffentlichen MCP‑Server. Dann integrieren Sie ihn in Cursor, Claude oder ein anderes Tool Ihrer Wahl. Die Anwendung, die sich daraus ergibt, mag je nach Kontext unterschiedlich sein – ob Sie Ihre Dokumentation für Endnutzer öffnen oder Ihr eigenes Redaktionssystem mit einer KI‑Unterstützung ausstatten. Die Grundlage ist in fünf Minuten gelegt.

    Quelle: raymondcamden.com

  • Die vier Reiter hinter tausenden Postgres-Ausfällen

    Die vier Reiter hinter tausenden Postgres-Ausfällen

    Du betreibst eine Webanwendung, alles läuft – bis die Datenbank nicht mehr reagiert. Kein SELECT, kein INSERT. Server hängt, Fehlerlogs laufen über. Wer eine PostgreSQL-Instanz betreut, kennt diese Momente. Sie haben oft vier Ursachen. Der Entwickler von pgrust, einer Neuimplementierung von Postgres in Rust, hat diese Problembereiche analysiert. Er beschreibt, warum sie zu Ausfällen führen – und wie sein Ansatz helfen könnte. Schauen wir uns die vier Punkte an.

    1. VACUUM und Transaction ID Wraparound – die stille Gefahr

    Wenn du in Postgres eine Zeile löschst, wird sie nicht sofort physisch entfernt. Postgres markiert sie als gelöscht – das ermöglicht Rollbacks. Die Bereinigung übernimmt ein Hintergrundprozess namens VACUUM. Er liest alle Daten und entfernt die markierten Zeilen. Das klingt harmlos, birgt aber zwei Risiken. Erstens: VACUUM frisst I/O. Es konkurriert mit deinen Abfragen um die Festplattenbandbreite. Stell dir vor, du liest ein Buch, während jemand neben dir Seiten herausreißt – so ähnlich fühlt es sich für die Datenbank an. Du musst VACUUM richtig einstellen: aggressiv genug, um mit gelöschten Zeilen Schritt zu halten, aber nicht so aggressiv, dass es Queries ausbremst. Eine knifflige Balance, besonders ohne dedizierten Datenbank-Admin.

    Das zweite Problem ist tückischer: Transaction ID Wraparound. Postgres vergibt pro Transaktion eine 32-Bit-ID – maximal vier Milliarden IDs. Sind alle verbraucht, müssen sie wiederverwendet werden. VACUUM markiert alte IDs, damit sie sicher recycelt werden. Hinkt VACUUM hinterher, schaltet Postgres die Datenbank komplett ab – sonst könnten Daten korrupt werden. Der Autor schätzt, dass dieser Mechanismus weltweit für tausende, wenn nicht zehntausende Ausfälle verantwortlich ist. pgrust plant zwei Lösungen: 64-Bit-Transaktions-IDs, die zwar Overhead pro Zeile bedeuten, aber den Wraparound praktisch auf unbestimmte Zeit verschieben. Außerdem wird eine Architektur ohne VACUUM diskutiert – ähnlich dem Undo-Log von Oracle. Der Ansatz ist vielversprechend, erfordert aber grundlegende Änderungen.

    2. Connection Limits und Query Parallelism – wenn die Türen zu bleiben

    Jede Postgres-Instanz hat eine Konfigurationsvariable für die maximale Anzahl gleichzeitiger Verbindungen. Wenn mehr Clients versuchen, sich zu verbinden, werden sie abgewiesen – die Datenbank ist nicht erreichbar. Simpel, aber die Falle lauert im Detail: Änderungen an diesem Grenzwert erfordern einen Neustart. Wer den Wert zu niedrig ansetzt, steht im Regen. Viele nutzen PgBouncer, einen Verbindungspooler, der das Problem mildert, aber nicht beseitigt. Warum ein Grenzwert? Der Grund liegt in der Prozess-Architektur von Postgres. Für jede neue Verbindung erzeugt Postgres einen Betriebssystem-Prozess. Prozesse sind teuer – sie brauchen CPU, Speicher und Zeit zum Starten. Das schränkt nicht nur die Parallelisierung zwischen Abfragen ein, sondern auch innerhalb einer einzelnen Abfrage. Denn wenn Postgres eine aufwendige Query parallel ausführen will, startet es ebenfalls mehrere Prozesse. Wegen der hohen Kosten tut es das nur bei wirklich langlaufenden Abfragen.

    Seit Jahren wird über eine Umstellung auf ein Thread-Modell diskutiert, aber die Änderung ist so tiefgreifend, dass kaum jemand sie wagt. pgrust wurde von Anfang an mit Threads konzipiert. Der Autor betont, dass die Prozess-Architektur der Sicherheit dient: Prozesse sind stärker isoliert als Threads. Ein Fehler in einem Prozess reißt die anderen nicht mit. pgrust setzt auf die Speichersicherheitsgarantien von Rust zur Compile-Zeit, sodass diese Isolation nicht nötig ist. Das verspricht schnellere Verbindungsaufnahmen und effizientere Parallelisierung – ohne lästige Grenzwerte und Umwege über PgBouncer.

    3. Bad Query Plans – wenn der Optimierer daneben liegt

    Postgres besitzt einen Planer für Abfragen. Er analysiert die SQL-Query, zieht Statistiken über die Tabellen heran und wählt aus Dutzenden Algorithmen den vermeintlich schnellsten aus. Meist funktioniert das gut. Wenn der Planer daneben liegt, dann richtig. Der Unterschied zwischen einem guten und einem schlechten Ausführungsplan kann den Faktor 60.000 ausmachen: eine Query, die normalerweise 10 Millisekunden braucht, läuft plötzlich 10 Minuten. Das ist bekannt. Noch ärgerlicher: Postgres bietet kaum Möglichkeiten, den Planer direkt zu lenken. Während andere Datenbanken wie MySQL Planner Hints unterstützen, mit denen du für einzelne Queries den Algorithmus vorgeben kannst, fehlt diese Funktion in Postgres komplett. Die einzige Stellschraube ist das globale Abschalten bestimmter Algorithmen – ein grobes Werkzeug.

    Der Autor von pgrust berichtet von einem früheren Arbeitgeber, bei dem sie in der gesamten Datenbank Nested-Loop-Joins deaktivieren mussten, weil Postgres sie ständig nutzte und alle Queries ausbremste. Grund war oft der Umgang mit JSON-Daten. Für pgrust schwebt dem Entwickler ein adaptiver Query Planer vor, der ständig die Ausführungszeiten überwacht. Wenn eine Query, die normalerweise 10ms braucht, plötzlich 10 Sekunden benötigt, soll pgrust automatisch erkennen, ob der Plan gewechselt hat oder die Statistiken veraltet sind, und ohne menschliches Eingreifen korrigieren. Klingt futuristisch, aber der Autor ist optimistisch, dass dies realisierbar ist – es fehlt nur die konkrete Umsetzung.

    4. JSON – scheinbarer Segen mit versteckten Fallstricken

    Postgres liebt und hasst JSON. Es ist nützlich, um unstrukturierte Daten zu speichern und flexibel abzufragen. Aber die Schattenseiten sind massiv. Das größte Problem: Postgres sammelt für JSON-Spalten keine vernünftigen Statistiken. Für normale Datentypen wie Integer oder Text erhebt es Histogramme, häufigste Werte und mehr. Bei JSON schätzt der Planer pauschal, dass ein Filter auf eine JSON-Eigenschaft nur 0,1 % der Zeilen trifft – ein fixer Wert, völlig unabhängig von den tatsächlichen Daten. Der tatsächliche Anteil kann bei 80 % oder bei 0,0001 % liegen. Diese Fehleinschätzung führt zu schlechten Abfrageplänen. Wer mit großen JSON-Spalten gearbeitet hat, kennt das Gefühl, wenn Abfragen plötzlich explodieren.

    Hinzu kommt, dass Postgres JSON nicht komprimiert. Werden in vielen Zeilen die gleichen Schlüssel und Werte verwendet, werden sie jedes Mal neu gespeichert. Das bläht die Datenbank auf. Der Autor von pgrust sieht zwei Ansatzpunkte: echte Statistiken für JSON-Spalten – das würde nach seiner Einschätzung 80 % der JSON-bedingten Probleme lindern. Es existieren bereits Patches, die in diese Richtung gehen; er möchte einen zur Serienreife bringen. Zweitens eine Wörterbuchkomprimierung (Dictionary Compression), um sich wiederholende JSON-Inhalte platzsparender abzulegen. Das könnte den Speicherverbrauch drastisch reduzieren und die I/O-Last verringern.

    Was bleibt – und was pgrust konkret bedeutet

    Die vier Punkte – VACUUM/Wraparound, Connection Limits, schlechte Query-Pläne und JSON – sind keine akademischen Probleme. Sie verursachen täglich Ausfälle in tausenden Unternehmen. Der Entwickler von pgrust hat sich vorgenommen, diese Schwachstellen mit einem technisch durchdachten Neuanfang zu adressieren. Der Fokus des Projekts liegt auf zwei Dingen: erstens Kompatibilität mit PostgreSQL – pgrust besteht bereits 96 % der offiziellen Regressionstests. Zweitens Stabilität und Fehlerbereinigung, damit die Datenbank ernsthaft eingesetzt werden kann. Erst danach sollen die architektonischen Verbesserungen kommen, beginnend mit den 64-Bit-Transaktions-IDs.

    Für dich als Betreiber einer Postgres-Installation bedeutet das: Solange pgrust nicht produktionsreif ist, solltest du die genannten Fallstricke aktiv managen. Überwache deine VACUUM-Aktivitäten, setze PgBouncer ein, um Connection Limits zu puffern, analysiere regelmäßig deine Abfragepläne und meide JSON, wo möglich, oder schaffe dir Monitoring für plötzliche Performance-Einbrüche. Die Arbeit an pgrust zeigt, dass die Probleme erkannt sind und Lösungen existieren.

    Quelle: malisper.me