Pogocache [1] verarbeitet über drei Millionen Anfragen pro Sekunde, während Memcached unter gleichen Bedingungen lediglich rund zweieinhalb Millionen schafft. Gleichzeitig belastet Pogocache den Prozessor deutlich weniger und benötigt nur rund halb so viele Prozessorzyklen wie Memcached, was die Auslastung des Servers reduziert und letztendlich Energie und somit Geld spart. Und auch die übrigen technischen Features klingen verlockend: Pogocache verhält sich nach außen wie Memcached, Valkey und Redis und beherrscht darüber hinaus das PostgreSQL-Wire-Protokoll. Entsprechende Clients reden folglich ohne Anpassungen direkt mit der Datenbank und es ist Admins daher leicht möglich, die Konkurrenten durch die flinkere DB zu ersetzen. Alternativ oder ergänzend kommuniziert Pogocache über seine eigene REST-Schnittstelle.

Entwickler sind sogar in der Lage, die Datenbank-Engine in Anwendungen einzubauen. Die Anfragen gehen dann direkt an Pogocache und müssen nicht zuvor zeitraubend den Netzwerkstack durchlaufen. Auf diese Weise sollen über 100 Millionen Operationen pro Sekunde möglich sein. Nützlich ist das unter anderem bei Microservices, die so jeweils ihren eigenen schnellen Zwischenspeicher erhalten.

Hinter Pogocache steht Entwickler Josh Baker, der unter anderem für ein Redis-kompatibles Server-Framework verantwortlich zeichnet und seit mehreren Jahren mit Tile38 eine quelloffene In-Me- mory-Datenbank für Geodaten vorantreibt. Trotz seiner Expertise sollten IT-Verantwortliche Pogocache nicht blind einsetzen: Zwar galt bereits die im Juli veröffentlichte erste Version als stabil und für produktive Umgebungen geeignet, aufgrund ihres noch jungen Alters fehlen jedoch Langzeiterfahrungen. Und es gibt noch ein paar Haken.

Die In-Memory-Datenbank versteht sich vor allem als Caching-Software, die beispielsweise einen Suchindex vorhält. Pogocache schert sich daher nicht darum, wer gerade Daten abruft und schreibt. Den Zugriff schützen Anwender mit nur einem Passwort – wohlgemerkt: einem einzigen. Dieses müssen die Clients dann bei jeder Anfrage mitschicken. Gezielt einem Client (vorübergehend) den Zugriff zu entziehen, ist nicht so leicht möglich. Die Kommunikation verschlüsselt die Datenbank immerhin auf Wunsch per TLS. Reichen die genannten Sicherheitsmaßnahmen nicht aus, müssen Sie explizit eine Firewall beziehungsweise eine Identity-Management-Software vorschalten. Ebenfalls fehlt derzeit ein Failover-Mechanismus, der etwa bei einem Absturz der Datenbank auf eine funktionierende Kopie umschaltet. Eine entsprechende Funktion steht jedoch bei Josh Baker auf der Agenda.

Auch die Zusammenarbeit mit Memcached-, Redis- und Valkey-Clients funktioniert nicht ganz reibungslos. So kennt Pogocache nur das "Basic Text Protocol" [2] von Memcached sowie einige ausgewählte Befehle des von Valkey und Redis genutzten "Redis Serialization Protocol" (RESP) [3]. Immerhin kommen nach und nach weitere Befehle hinzu, beispielsweise in Pogocache 1.2 "MONITOR". Die Onlinedokumentation liefert eine Liste der aktuell unterstützten Kommandos [4], die übrigens auch PostgreSQL-Clients verwenden müssen.

Die durchaus beeindruckenden Geschwindigkeitsunterschiede zwischen Pogocache und der Konkurrenz lassen sich mit dem Memtier-Benchmark ermitteln [5]. Dabei handelt es sich um einen synthetischen Benchmark, der die Datenbank nicht mit realen Anwendungsfällen untersucht. Die auf der Pogocache-Website veröffentlichten Ergebnisse entstanden zudem in einer auf hohe Geschwindigkeiten getrimmten Testumgebung, die in der Amazon-Cloud auf Systemen der Klasse "c8g.8xlarge" lief.

Wir waren deshalb neugierig, ob sich Pogocache auch in anderen Umgebungen deutlich von Memcached absetzen kann. Um das herauszufinden, haben wir den Memtier-Benchmark auf Pogocache 1.2 und Memcached 1.6.37 losgelassen. Auf einem rund zweieinhalb Jahre alten Intel-Rechner standen beiden Probanden 32 GByte Speicher und zwölf Kerne zur Verfügung und als Betriebssystem diente Ubuntu. Pogocache und Memcached nutzten ihre Standardkonfiguration, arbeiteten aber jeweils mit zwölf Threads.

Nach acht Benchmark-Durchläufen gewann Pogocache – allerdings nur knapp: Während die neue In-Memory-Datenbank im Schnitt 119.890 Schreiboperationen pro Sekunde durchführte, kam Memcached auf 116.223. Ähnliche Abstände gab es bei den Leseoperationen sowie bei weiteren Messungen auf einem zweiten System. Die Geschwindigkeit beeinflussten dabei hauptsächlich die gleichzeitigen Anfragen: Je mehr Threads des Benchmarks auf die DBs feuerten, desto mehr konnte sich Pogocache von seinem Kontrahenten absetzen. Der tatsächliche Vorteil von Pogocache hängt folglich vom konkreten Anwendungsfall, der Infrastruktur und der Konfiguration aller beteiligten Komponenten ab.

Pogocache läuft offiziell nur unter Linux und macOS. Der kompakte und relativ portable Quellcode sollte sich dennoch auf vielen unixoiden Systemen übersetzen lassen. Pogocache steht unter der GNU Affero Public License v3, die einen kostenfreien Einsatz auch in Unternehmen gestattet. Parallel offeriert Josh Baker über die Firma Polypoint Labs [6] eine kommerzielle Enterprise-Edition mit Support. Obendrein soll ein Clouddienst folgen, der Pogocache automatisch skaliert und Backups erstellt. Zum Redaktionsschluss war allerdings lediglich eine Warteliste dafür online.

Pogocache selbst kommt als kompaktes Programm, das in Version 1.2 gerade einmal 13 MByte auf die Waage bringt. Am schnellsten starten Sie die Datenbank über einen vorgefertigten Docker-Container. Dem gewährt der folgende Befehl der Einfachheit halber vollen Zugriff auf den Netzwerkstack des Hostsystems:

Aber auch der direkte Start der Datenbank als Bare-Metal-Betrieb erfordert unter Linux nur drei Handgriffe: Laden Sie sich von der GitHub-Seite des Projekts [7] das passende Archiv für Ihr System herunter und entpacken Sie es – eine Installation ist nicht notwendig. Obacht: Die Archive mit "aarch64" und "amd64" im Namen sind für Systeme mit Musl-Bibliothek gedacht. Um den Quellcode selbst zu übersetzen, genügt ein C-Compiler und der Aufruf des make-Befehls baut dann Pogocache. In jedem Fall starten Sie die Datenbank via:

Die Parameter lassen die In-Memory-Datenbank auf Localhost an Port 9401 lauschen. Das sind gleichzeitig die Vorgaben, wenn Sie beide Parameter weglassen. Möchten Sie mit Pogocache über einen Unix-Socket sprechen, geben Sie diesen hinter "-s" an.

Pogocache arbeitet als Key-Value-Store. Jeden Informationsschnipsel wie beispielsweise "308 Kelvin" merkt sich die Datenbank folglich unter einem Schlüsselwort wie "max_temp".

Ob das reibungslos funktioniert, testen Sie schnell mit dem Tool "Curl":

Die Befehle speichern den Wert "308 Kelvin" unter dem Schlüssel "max_temp", rufen diesen ab und löschen den Eintrag wieder. Die Kontaktaufnahme erfolgt dabei über das REST-Protokoll. Das wiederum manipuliert die Daten über PUT-, GET- und DELETE-Methoden, die Endpunkte entsprechen den Keys. Mit einem an die URL angehängten Query-String "?nx" speichert Pogocache die Daten nur, wenn der Schlüssel noch nicht existiert. Mit "?xx" landen die Informationen hingegen nur dann im Cache, wenn sie dort explizit schon existieren.

Sollen sich alle Clients mit einem Passwort ausweisen müssen, notieren Sie es beim Start von Pogocache hinter "--auth". Um zusätzlich die Kommunikation via TLS zu verschlüsseln, muss folgender Bandwurm her:

Dabei schaltet "-p 0" zunächst die unverschlüsselten Verbindungen ab. In der Datei "ca.crt" erwartet Pogocache das Zertifikat einer Certificate Authority (CA), das von ihr signierte Zertifikat für den Server muss in der Datei "pogocache.crt" liegen und der zugehörige Private Key in "pogocache.key".

Vom Client hängt ab, wie Sie das Passwort übergeben und die TLS-Verbindung erzwingen. Unter dem Curl-Befehl verraten Sie das Passwort in einem entsprechenden Header, die Komponenten für die HTTPS-Kommunikation in Parametern:

Das Passwort können Sie alternativ auch in einem Query-String an die URL heften. Sie ändern also den gerade gezeigten Befehl am Ende dergestalt ab: "-X GET https://localhost:9401/max_temp?auth=geheim".

Alternativ zu Curl richten Sie beliebige Memcached-, Redis- und Valkey-Clients auf Pogocache ein, den Valkey-Client beispielsweise via valkey-cli -p 9401. PostgreSQL-Clients verwenden ebenfalls die REST-Kommandos und Pogocache liefert dabei standardmäßig Texte zurück. Sofern Sie Bilder oder andere binäre Daten im Cache speichern, schalten Sie vor deren Ausgabe mit "::bytea" auf den Binärmodus um. Analog führt "::text" wieder zur reinen Textausgabe. Beide Direktiven betreffen nur die Kommunikation mit PostgreSQL-Clients.

Nach dem gezeigten Prinzip lässt sich Pogocache auch aus Skriptsprachen ansprechen und so in eigene Workflows und Anwendungen einbinden. Das folgende Beispiel nutzen Sie für einen Client in Python, der Redis-py nutzt:

Wenn Sie sehr viele Daten jonglieren, kann der Hauptspeicher volllaufen und dabei das komplette System in die Knie zwingen. Pogocache nimmt deshalb standardmäßig höchstens 80 Prozent des Speichers in Beschlag. Diesen Wert passen Sie beim Start der Datenbank über den Parameter "--maxmemory" an. Sollte der Speichervorrat einmal erschöpft sein, schmeißt die DB eigenmächtig Inhalte über Bord. Welche Daten gehen müssen, bestimmt der 2-Random-Algorithmus. Wenn Sie wichtige Informationen einlagern möchten, sollten Sie Pogocache dieses Verhalten mit "--evict no" austreiben.

Davon unabhängig können Sie Schlüssel-Wert-Paaren eine Lebenszeit (Time To Live, TTL) mit auf den Weg geben. In folgendem Beispiel verbleibt "308 Kelvin" nur 30 Sekunden in der Datenbank:

Pogocache räumt in regelmäßigen Abständen die Datenbank auf. Erst bei einer solchen Aufräumaktion kehrt die Datenbank-Engine die abgelaufenen Informationen aus der Datenbank – "308 Kelvin" könnte folglich noch länger als die vorgegebenen 30 Sekunden im Speicher verbleiben.

Beim Start von Pogocache können Sie über ein paar Stellschrauben das Laufzeitverhalten beeinflussen und so die Datenbank an Ihre Gegebenheiten anpassen. Mit dem Parameter "--maxconns" geben Sie zunächst die maximale Anzahl an Verbindungen vor.

Alle anfallenden Arbeiten erledigen mehrere parallel laufende Threads. Wie viele Pogocache davon startet, hängt maßgeblich von den verfügbaren Prozessorkernen ab. Auf eine ganz bestimmte Thread-Anzahl festnageln lässt sich die Datenbank über den Parameter "--threads".

Sämtliche Key-Value-Paare merkt sich Pogocache in einer Hashmap. Diese Datenstruktur zerhackt die Software in mehrere sogenannte Shards (auch als Buckets bezeichnet). Das hat den Vorteil, dass die Datenbank-Engine an mehreren Teilen der Hashmap parallel arbeiten kann und nicht langsam eine Anfrage nach der anderen abarbeiten muss. Die Anzahl der Shards legt Pogocache bei seinem Start fest, in unseren Tests waren dies häufig 4096. Einen anderen Wert geben Sie bei Bedarf über "--shards" vor.

Josh Baker entwickelte Pogocache von Grund auf in der Programmiersprache C. Letzteres verblüfft heutzutage ein wenig, sind doch moderne Alternativen wie Rust ähnlich schnell und obendrein noch weniger anfällig für Speicherfehler. C hat allerdings den Vorteil, dass sich die Datenbank-Engine recht unkompliziert in alle Programmiersprachen mit einer C-Schnittstelle integrieren lässt. Seit der Version 1.2 bietet sich zudem die Wahl zwischen drei Speicherverwaltern, die Hauptspeicher reservieren. Standardmäßig kommt das etwas clevere, maßgeblich von Microsoft entwickelte Mimalloc zum Einsatz. Alternativ steht Jemalloc bereit, das allerdings bereits seit Juni 2025 nicht mehr weiterentwickelt wird – diesen Speicherallokator sollten Sie daher nur mit einer guten Begründung einsetzen. Als dritte Möglichkeit lässt sich der Standardallokator nutzen. Mit dem Parameter "--allocator" schalten Sie beim Start von Pogocache auf "jemalloc" oder den "stock"-Allokator um.

Das Gaspedal drückt Pogocache zwar erst in passenden Umgebungen durch, dennoch macht die kleine, schlanke und schnelle In-Memory-Datenbank den etablierten Platzhirschen Konkurrenz. Obendrein spricht sie mit bestehenden Memcached-, Redis- und PostgreSQL-Clients – vorausgesetzt, der eingeschränkte Befehlsumfang steht nicht im Weg. Wer eine unkomplizierte Caching-Software sucht, sollte daher Pogocache durchaus in seine Auswahl einbeziehen, dabei aber das noch junge Alter im Hinterkopf behalten.