En el mundo de la infraestructura, las modas cambian, pero las necesidades suelen ser las mismas: menos latencia, menos CPU por petición y menos sorpresas en producción. En ese terreno —donde Redis, Memcached, Valkey o Dragonfly llevan años siendo nombres habituales— está ganando ruido Pogocache, un servidor de caché escrito en C que presume de estar optimizado “desde cero” para respuesta rápida y eficiencia de CPU, y que además juega una carta poco común: habla varios protocolos de golpe.

La propuesta es sencilla de entender: una única pieza de software que puede actuar como caché consumible con herramientas y librerías ya existentes, porque entiende Memcache, RESP (Valkey/Redis), HTTP y hasta el wire protocol de Postgres. Para equipos que quieren cambiar el motor sin reescribir medio stack, esta compatibilidad es casi el “feature” principal: se puede probar con redis-cli/valkey-cli, con curl, con psql o con clientes Memcached tradicionales.

Qué es exactamente Pogocache (y por qué no es “otro Redis más”)

Pogocache se presenta como un caché key-value pensado para ejecutarse como servicio (daemon), pero también con una opción poco habitual: modo embebido. En vez de exponer un puerto y hablar por red, puede compilarse dentro de tu propio software mediante un fichero autocontenido (pogocache.c), eliminando el coste del networking cuando lo que se busca es “pedal to the metal”.

A nivel de diseño, su enfoque gira alrededor de:

• Hashmap shardeado (muchos “shards” para repartir contención).
• Robin Hood hashing (para mejorar comportamiento de colisiones).
• Bloqueos ligeros por shard.
• Modelo de red por hilos con colas de eventos (epoll/kqueue) y optimizaciones como io_uring en Linux cuando está disponible.

Dicho de otro modo: está construido para que la operación típica (SET/GET/DEL) sea barata en CPU y estable en latencia, que es justo donde duele cuando un servicio empieza a escalar.

Comparativa de rendimiento: lo que dicen los benchmarks “en condiciones”

Aquí es importante ser honesto: no existe un “más rápido” universal. Todo depende de hardware, carga, tamaño de valores, pipelining, persistencia, red, etc. Pero Pogocache ha sabido posicionarse con números concretos y replicables.

En su comparativa pública (8 hilos en una instancia AWS c8g.8xlarge), Pogocache aparece con 3,08 M QPS, por delante de alternativas populares en ese escenario:

• Pogocache: 3,08 M QPS
• Memcache: 2,60 M QPS
• Garnet: 1,54 M QPS
• Redis: 1,51 M QPS
• Dragonfly: 1,41 M QPS
• Valkey: 1,33 M QPS

El matiz relevante es cómo se mide. En el repositorio de benchmarks asociado se detalla que las pruebas se ejecutan con memtier_benchmark, conexiones locales (pipes UNIX), persistencia desactivada, 31 ejecuciones por gráfico y mediana como valor representativo, además de percentiles de latencia (p50/p90/p99 y superiores) y ciclos de CPU medidos con perf. Es decir, no es un “pantallazo” sin metodología: hay contexto y repetición.

¿Significa eso que cualquiera verá exactamente ese +X%? No. Pero sí marca una tendencia: si tu cuello de botella es la latencia/CPU de la capa de caché, Pogocache merece al menos una prueba controlada.

Cómo instalar Pogocache

Opción 1: compilar desde código fuente

En sistemas tipo Linux/macOS (64 bits), el camino clásico es:

git clone https://github.com/tidwall/pogocache
cd pogocache
make

Eso genera el binario pogocache.

Opción 2: Docker

Para probar rápido sin ensuciar la máquina:

docker run --net=host pogocache/pogocache

(En entornos donde --net=host no encaja, habrá que mapear puertos manualmente.)

Cómo arrancarlo (y ajustar lo mínimo para producción)

El arranque por defecto levanta el servicio en 127.0.0.1:9401:

./pogocache

Para escuchar en otra IP:

./pogocache -h 0.0.0.0

Y algunos flags típicos que conviene conocer:

• --threads: número de hilos de I/O.
• --maxmemory: límite de memoria (por defecto, un porcentaje).
• --evict: si debe expulsar claves al alcanzar maxmemory.
• --auth: contraseña/token para requerir autenticación.
• TLS: --tlsport, --tlscert, --tlskey, --tlscacert.

Ejemplo con contraseña:

./pogocache --auth "MiPasswordLarga"

Cómo usarlo: 3 formas prácticas (HTTP, Redis/Valkey y Postgres)

1) HTTP con curl (PUT / GET / DELETE)

Guardar:

curl -X PUT -d "mi valor" http://localhost:9401/miclave

Leer:

curl http://localhost:9401/miclave

Borrar:

curl -X DELETE http://localhost:9401/miclave

TTL (en segundos) como query param:

curl -X PUT -d "valor con TTL" "http://localhost:9401/miclave?ttl=15"

2) RESP (Valkey/Redis) con valkey-cli o redis-cli

valkey-cli -p 9401
SET miclave valor
GET miclave
DEL miclave

Si activaste --auth:

valkey-cli -p 9401 -a "MiPasswordLarga"

3) “Modo Postgres” con psql (sí, como suena)

Conectar:

psql -h localhost -p 9401

Y operar:

SET miclave 'mi valor';
GET miclave;
DEL miclave;

Esto abre una puerta curiosa: usar librerías Postgres en lenguajes donde ya tienes tooling maduro, o incluso automatizar pruebas con psql sin instalar clientes Redis.

Cuándo tiene sentido (y cuándo no)

Pogocache encaja especialmente bien cuando:

• Se busca máxima velocidad en operaciones simples (GET/SET/DEL).
• Se quiere sustituir o complementar Redis/Memcached sin cambiar clientes.
• Se valora la opción embebida para quitar red de la ecuación.
• La prioridad es latencia baja + eficiencia CPU por encima de features complejos.

Y conviene ser prudente si:

• Se necesita un ecosistema enorme de módulos, scripts y patrones ya “estándar” del mundo Redis.
• Se requiere alta disponibilidad distribuida “out of the box” (Pogocache habla de roadmap y enfoque futuro, pero el punto fuerte hoy es el rendimiento por nodo y la simplicidad operativa).

Preguntas frecuentes

¿Pogocache puede sustituir a Redis en un proyecto existente?
En muchos casos, sí a nivel de cliente/protocolo, porque habla RESP (Valkey/Redis) y soporta comandos habituales (SET/GET/DEL/TTL/EXPIRE, etc.). La clave está en revisar si la aplicación usa características avanzadas específicas.

¿Qué ventaja real aporta que soporte HTTP y Postgres además de Redis/Memcache?
Reduce fricción: permite probar y operar con herramientas universales (curl) o integrarse con entornos donde ya existe tooling Postgres (psql, drivers), sin depender de clientes especializados.

¿Los benchmarks de QPS son “reales” o marketing?
Son números publicados con un repositorio de metodología y scripts, lo que les da trazabilidad. Aun así, siempre hay que validarlo con tu propio workload (tamaño de valores, concurrencia, red, persistencia, etc.).

¿Cómo se asegura Pogocache en producción?
Incluye autenticación por contraseña/token y soporte TLS/HTTPS mediante flags de arranque, además de poder limitar recursos (hilos, memoria, conexiones) y controlar políticas de expulsión.

Fuente: Administración de Sistemas