Redis como caché para queries lentas en Supabase

Si tu aplicación se siente lenta cada vez que consulta la base de datos, Redis en Supabase puede ser la solución. Aquí verás cómo funciona el caché con Redis, por qué acelera tus queries y cómo integrarlo en un proyecto Lovable para devolver datos casi al instante.

Qué es Redis y por qué acelera tu base de datos

Redis funciona como una base de datos para tu base de datos. En lugar de pedirle a Supabase que recorra tablas completas cada vez que necesitas un dato, Redis guarda esa información lista para servirla en milisegundos.

Piensa en Redis como una pizarra sobre tu escritorio con los puntos clave ya escritos. Si lo que buscas está ahí, lo lees al instante. Si no, vas a la base de datos, traes el dato y lo anotas en la pizarra para la próxima consulta. Eso es caching: una hoja de trucos que evita queries pesadas repetidas.

¿Qué es Redis en pocas palabras? Es una capa de caché en memoria que guarda resultados de consultas para devolverlos más rápido que una base de datos tradicional como PostgreSQL o Supabase.

Cómo funciona el flujo de caché entre Redis y Supabase

El patrón clave se llama cache-aside y sigue una lógica sencilla cuando un usuario pide un dato desde el frontend.

• El cliente hace una petición a una API route, por ejemplo GET /api/random-name.
• La API pregunta primero a Redis si ya tiene el resultado bajo una clave específica.
• Si hay cache hit, devuelve el dato al instante sin tocar la base de datos.
• Si hay cache miss, consulta la tabla en Supabase, retorna el dato y lo guarda en Redis con un tiempo de expiración (TTL).

En el ejemplo de la clase [01:50], el TTL se fija en 10 segundos bajo la clave demo:last:name, y la respuesta JSON incluye un campo source con valor DB o Redis para que sepas de dónde vino el dato.

¿Cuándo conviene usar Redis sobre Supabase directo? Cuando tienes datos que se leen muchas veces y cambian poco: nombres, listados, configuraciones o resultados de queries costosas.

Cómo implementar Redis en un proyecto Lovable con Supabase

Para montar el demo, el flujo en Lovable es directo y se apoya en Upstash Redis como proveedor del caché.

Qué prompt usar en Lovable

El prompt que se ejecuta en clase [01:20] pide tres cosas concretas:

• Crear una página demo con un client component llamado Redis Supabase Demo.
• Implementar un endpoint API Random Name que traiga una fila aleatoria de una tabla names en Supabase.
• Cachear el resultado en Upstash Redis durante 10 segundos y devolver { name, source }.

También se le pide a Lovable que genere las variables de entorno (.env) necesarias para conectar Upstash y Supabase.

Qué pasa la primera vez que llamas al endpoint

La primera petición tarda un poco más porque Redis está vacío y hay que ir a Supabase. A partir de la segunda llamada, la respuesta es prácticamente instantánea porque el dato ya vive en el caché [02:30]. Cuando expiran los 10 segundos del TTL, la siguiente petición vuelve a la base de datos y refresca el ciclo.

Cuándo aplicar caching en tu app

Redis no es para todo. Conviene cuando el costo de la query es alto frente a la frecuencia con que cambian los datos.

Algunos casos donde tiene sentido evaluar caché con Lovable en chat mode:

• Renombrar archivos o fotos que se consultan repetidamente.
• Servir miniaturas o metadatos de almacenamiento.
• Listados frecuentes que no cambian en tiempo real.
• Resultados de búsquedas o filtros que se repiten entre usuarios.

El consejo práctico es preguntarle a Lovable, antes de implementar, si Redis es buen fit para el caso concreto que quieres resolver. No todo necesita caché, y a veces una query bien indexada en Supabase basta.

Si ya probaste este patrón en tu app, cuéntame en los comentarios qué dato decidiste cachear y cuánto bajó tu tiempo de respuesta.