---
title: "Pogocache: el caché que habla Redis, Memcache y HTTP y apunta a la latencia mínima"
description: "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,..."
url: https://revistacloud.com/pogocache/
date: 2026-01-08
modified: 2026-01-08
author: "Antonio"
image: https://revistacloud.com/wp-content/uploads/2026/01/pogocache-systemadministration-net-scaled.jpg
categories: ["Guías y recursos"]
tags: ["caché", "memcache", "pogocache", "redis", "rendimiento"]
type: post
lang: es
---

# Pogocache: el caché que habla Redis, Memcache y HTTP y apunta a la latencia mínima

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](https://github.com/tidwall/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.

![pogocache graphs dark](https://revistacloud.com/wp-content/uploads/2026/01/pogocache-graphs-dark-1024x908.png)

¿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](https://administraciondesistemas.com/pogocache-el-nuevo-cache-todoterreno-que-promete-mas-velocidad-con-menos-cpu/)