En el mundo de la infraestructura, el caché suele ser ese engranaje silencioso que decide si una web “vuela” o se arrastra, si una API aguanta un pico de tráfico o se rompe, y si una plataforma escala con eficiencia o a base de añadir servidores. En ese terreno dominado por nombres muy asentados —Memcached, Redis (y su ecosistema), o alternativas más recientes— ha empezado a ganar notoriedad Pogocache, un proyecto de software de caché que se presenta con una obsesión clara: latencia baja y eficiencia de CPU, incluso a medida que se incrementa el paralelismo.
La propuesta llega con un mensaje directo: “construido desde cero” para responder rápido, gastar menos ciclos por operación y, por extensión, reducir coste operativo y consumo energético. En tiempos donde cada milisegundo importa y el coste por petición se mira con lupa, esa promesa es exactamente el tipo de afirmación que despierta interés… y también escepticismo.
Un caché que “habla” varios protocolos sin cambiar de herramienta
Uno de los rasgos diferenciales de Pogocache no es solo su rendimiento, sino su forma de integrarse. En lugar de obligar a adoptar un único protocolo o cliente, declara compatibilidad con Memcache, RESP (Valkey/Redis), HTTP y hasta el wire protocol de Postgres, lo que permite conectarse con herramientas tan comunes como curl, redis-cli/valkey-cli o psql.
Este enfoque, más allá del rendimiento, apunta a un objetivo práctico: bajar la fricción. Si un equipo ya tiene clientes y librerías desplegados para Redis/Memcached, o si quiere tirar de HTTP para casos sencillos (por ejemplo, almacenar y leer claves sin depender de un SDK), la barrera de entrada se reduce.
No es casual que, cuando la comunidad técnica comenta el proyecto, destaque precisamente esa “poliglotía” de interfaces. El ingeniero y divulgador Simon Willison ha subrayado que lo más llamativo no es solo la velocidad, sino la interfaz de servidor que emula Redis y Memcached y además ofrece HTTP y Postgres.
La promesa de rendimiento: 3,08 millones de QPS en sus propias pruebas
Pogocache también ha querido jugar la carta de los números. En los benchmarks que publica el proyecto, se compara frente a Memcache, Redis, Valkey, Dragonfly o Garnet. En una de las tablas destacadas, se muestra a Pogocache alcanzando 3,08 millones de peticiones por segundo (QPS) en una prueba con 8 hilos sobre una instancia AWS c8g.8xlarge, por delante de Memcache (2,60 M) y del resto de alternativas listadas.
Ahora bien, incluso dentro del propio ecosistema del proyecto se insiste en la metodología: el repositorio de benchmarks indica que las pruebas se ejecutan con memtier_benchmark, conexiones locales (pipes), persistencia desactivada, y múltiples pasadas (31 ejecuciones por benchmark, usando la mediana para graficar). También describe el reparto de CPU entre el proceso del caché y el generador de carga, algo clave a la hora de interpretar resultados.
En otras palabras: hay números, sí, pero conviene leerlos como lo que son —pruebas controladas— y no como una garantía universal de superioridad en producción.
Qué hay debajo del capó: “shards”, hashing y un modelo pensado para escalar
En el apartado técnico, Pogocache describe una arquitectura basada en un hashmap fragmentado (sharded), con un número de shards que puede ser alto (a menudo 4.096), y con Robin Hood hashing para la tabla interna. A nivel de concurrencia, cada shard se protege con un spinlock ligero durante la operación.
En la parte de red, el diseño se apoya en colas de eventos (epoll/kqueue) por hilo y, cuando está disponible en Linux, contempla el uso de io_uring para optimizaciones de lectura/escritura por lotes. En expiración y presión de memoria, menciona políticas como la expiración por TTL y la expulsión cuando falta memoria, además de “sweeps” periódicos para liberar entradas caducadas.
Este tipo de decisiones —sharding agresivo, estructuras compactas, modelo de I/O por eventos— encaja con un objetivo clásico: reducir latencia y maximizar throughput, sin disparar el coste por operación.
Servidor o librería embebida: dos caminos para el mismo caché
Otro punto poco habitual en este segmento es el modo “embebido”. Pogocache incluye un fichero autocontenido (pogocache.c) que puede compilarse dentro de un proyecto en C para acceder al caché sin pasar por red, con el argumento de lograr rendimiento “en bruto”. En su documentación se habla de cifras superiores a 100 millones de operaciones por segundo en ese modo, una afirmación que, de nuevo, se presenta como orientativa y dependiente de escenario.
En el modo servidor, en cambio, el valor está en la compatibilidad: poder pincharlo donde hoy vive Redis/Memcached (o convive con ellos) y medir.
Seguridad y operación: TLS y autenticación, con enfoque pragmático
En seguridad, Pogocache contempla TLS/HTTPS y un password/token de autenticación opcional. La configuración se plantea mediante flags de arranque (certificados, claves, puerto TLS, etc.), y el control de acceso se integra en las peticiones según el protocolo usado.
Para administradores de sistemas, esto marca un mínimo razonable: cifrado en tránsito y un mecanismo simple de autenticación para entornos donde no se quiere exponer un caché “abierto”.
Licencia: de debates iniciales a un MIT más permisivo
Un detalle que no es menor en adopción empresarial: la licencia. El repositorio oficial muestra actualmente licencia MIT.
En 2025, algunos artículos que cubrieron su lanzamiento hablaban de licencias más restrictivas, algo que en proyectos de infraestructura puede frenar despliegues en ciertas compañías; la situación actual, al menos en el repositorio, es más permisiva.
Por qué importa (aunque no lo use nadie mañana)
Más allá del “¿es más rápido que Redis?”, Pogocache pone sobre la mesa una idea interesante: un caché puede ganar relevancia no solo por rendimiento, sino por ergonomía, ofreciendo múltiples interfaces y simplificando integraciones.
Aun así, el mercado del caché es un territorio duro: los incumbentes están hiperprobados, tienen ecosistemas maduros y miles de historias de guerra en producción. La pregunta real no es si Pogocache puede ser el más rápido en un gráfico, sino si puede sostener estabilidad, tooling, observabilidad y casos reales con el paso del tiempo. En foros ya hay usuarios explorándolo como alternativa en escenarios concretos (por ejemplo, configuraciones que hoy dependen de Redis), señal de que curiosidad, desde luego, no le falta.
Preguntas frecuentes
¿Para qué casos de uso tiene sentido un caché como Pogocache frente a Redis o Memcached?
Puede encajar cuando se busca latencia muy baja y una integración flexible (HTTP, RESP o Memcache), especialmente si el patrón es principalmente clave-valor simple y se quiere evaluar eficiencia de CPU.
¿Pogocache sirve como reemplazo directo de Redis en aplicaciones que usan colas, streams o scripts?
No está planteado como un “Redis completo”. Su foco es el caché key-value y la compatibilidad de protocolos, pero conviene revisar el set de comandos soportados y validar si tu aplicación depende de funcionalidades avanzadas.
¿Qué significa que soporte el protocolo de Postgres para un sistema de caché?
Permite interactuar con el caché usando clientes y herramientas del ecosistema Postgres (como psql), aprovechando un canal conocido para operaciones tipo SET/GET/DEL, sin necesidad de un cliente específico.
¿Cómo interpretar los benchmarks de Pogocache sin caer en conclusiones precipitadas?
Como una referencia útil, pero limitada: influyen la máquina, la configuración, el patrón de carga, la red y el cliente. Lo más sensato es probarlo en un entorno parecido al propio y medir latencia, consumo de CPU y comportamiento bajo picos.
