Uso de Redis para acelerar consultas en Supabase

Learn how to speed up data access in Supabase using Redis as a fast cache. In a simple “name generator” demo, a random name is cached in Upstash Redis for 10 seconds, returning JSON with a clear source: DB or Redis. After the first request, responses feel instant. This practical flow builds confidence to cache frequent reads without heavy database queries.

Speeding up data with Redis in Supabase

Redis works like a “database for your database,” a quick-access layer in front of your main DB. Think of it as a whiteboard on your desk: if the info is already written there, you can read it immediately without querying the full database.

What is Redis caching and a cache miss?

• Caching: storing recent results so future requests are faster.
• “Whiteboard” analogy: quick lookups without heavy queries.
• Cache miss: when the value is not in Redis, so the app queries the database and then saves the result in Redis for next time.
• Short-lived cache: in the demo, the value lives for 10 seconds to keep data fresh.

How does the "random name" API route work?

• Front end clicks “get a random name.”
• The request hits an API route that first checks Redis for key "demo last name".
• If Redis has it, return JSON instantly with source "Redis".
• If not, query the Supabase table "names" for a random row.
• Save the result to Upstash Redis for 10 seconds.
• Return JSON: name and source, where source is "DB" or "Redis".

Why is the response instant after the first request?

• The first run fetches from the database.
• The result is cached in Redis with a 10-second window.
• Subsequent clicks within that window read from Redis, so the response is near-instant.

Building the demo with Lovable and Supabase

A new page called "name generator" hosts a simple client component labeled "Redis Supabase demo." The prompt asks Lovable to add a small demo: create an API route "get API random name," query the "names" table in Supabase, cache in Upstash Redis under key "demo last name" for 10 seconds, and return JSON with name and source. ENV keys are created to enable the integration. A small mermaid diagram explains the flow from front end to API, Redis, and database.

Which components and keywords should you know?

• Redis: fast in-memory store to cache results.
• Cache: saved answer for quick reuse.
• Cache miss: value not found in cache, so query the DB.
• Upstash Redis: managed Redis used here for caching.
• Supabase: the database where the "names" table lives.
• API route: endpoint that handles the request and response.
• JSON: response format with fields "name" and "source".
• Key: identifier in Redis, here "demo last name".
• TTL (10 seconds): time the value remains cached.
• Client component: UI part that triggers the API call.
• ENV keys: configuration variables required to connect services.

Where can you apply this pattern?

This pattern helps beyond random names. It supports frequent, repeatable reads where speed matters.

What practical cases benefit from caching in Supabase?

• Renaming files quickly after the first lookup.
• Renaming photos with repeated checks.
• Accessing stored photos without repeated heavy queries.
• Preparing for automation with Supabase cron jobs mentioned next.

Have a use case you want to speed up or a question about the flow? Share it and describe which parts you’d cache first.