10/10/2026 · Redis, Database, คู่มือ

What is Redis, and how does it make your site faster?

Redis speeds a site up in three ways: cache, sessions and job queues. When you need it, how to add it on BrewInTH, prompts to copy and what to watch out for.

The site your AI built works nicely while a handful of people use it. Then you share it in a group chat, everyone opens it at once, the home page crawls, product pages hang, and the submit button makes people wait several seconds while the app sends an email. You ask the AI how to speed it up, and it says: "use Redis".

What is Redis, how is it different from the database you already have, and do you really need it? This article explains it without deep technical detail, shows how to add Redis to a project on BrewInTH, and gives you prompts that make the AI use it for the right job.

In short
⚡ Redis is an in-memory store, very fast to read and write; it helps your main database, it does not replace it
⚡ Three main jobs: a cache for slow results, sessions for sign-in state, a job queue for slow work in the background
⚡ On BrewInTH each project can have one, it does not count against the package's database quota, and REDIS_URL is set for the app
⚡ Redis is not backed up: anything you cannot lose belongs in the main database
⚡ For a job queue, have the AI create a "never evict" Redis from the start

What is Redis?

Think of a café. The main database (PostgreSQL or MySQL) is the ledger in the back office: complete, correct, permanent — but you have to walk over and open it every time. Redis is the whiteboard by the counter: the things people ask about most are written there for an instant answer, wiped and rewritten all day.

Redis keeps data in memory (RAM) rather than on disk, so it answers very quickly, but it holds less and is not designed to be the home of important data. Its job is to save repeated work for your main database and your app.

Three ways Redis makes a site faster

Three jobs of Redis: a cache remembers slow results for a while, such as the home page's product list; sessions keep sign-in state that every request sees the same way; a job queue moves slow work like emails or image resizing to the background so users do not wait

1. Cache: remember slow answers

A home page that fetches the 20 best sellers, counts reviews and works out promotional prices may take a few hundred milliseconds per visit. Open it 1,000 times and the database does the same work 1,000 times.

A cache computes it once and keeps the result in Redis with a lifetime (TTL), say 60 seconds. Everyone who opens the page during that minute gets the answer from Redis at once; when it expires, it is computed again. What people see can lag reality by at most that lifetime, so caches suit data that need not be exact to the second.

2. Sessions: sign-in state

An app that keeps sessions in its own memory signs everyone out whenever a new version is released or the app restarts. Sessions in Redis live apart from the app and are still quick to read on every request.

3. Job queues: don't make users wait

Sending a confirmation email, resizing a picture, building a PDF, calling an outside API — each takes seconds. Done inside the request, the user sits and waits. With a queue the app writes the job to Redis and answers straight away; a background worker picks the job up. Popular libraries: BullMQ (Node.js), Celery or rq (Python), Sidekiq (Ruby).

Does your site need Redis?

Usually not yet. A small site with a few hundred visits a day is easy work for the main database. Adding Redis too early gives you one more thing to look after and nothing in return.

Start thinking about Redis when

the same page is opened again and again, and each time is heavy to compute
users are signed out every time you release a new version
some button makes people wait because the app does slow work in the same request
you need rate limits, e.g. at most 5 failed sign-ins in 10 minutes

Before adding Redis, have the AI find the real cause. Often a page is slow because a query lacks an index or fetches more than it needs; fixing that helps more and adds nothing to maintain.

The home page of this site gets slow when many people visit. Find the cause first:
check the queries the home page runs, missing indexes, fetching more than needed, queries inside loops.
Fix those, then tell me whether we still need Redis as a cache, and why.

Adding Redis on BrewInTH

Three ways to add Redis on BrewInTH: tick Also add Redis when creating a project, pick Redis on the Databases tab of an existing project and press Create database, or let an AI agent or Upload and go live create it when the code uses Redis. REDIS_URL, REDIS_HOST, REDIS_PORT and REDIS_PASSWORD are put in App settings

When creating a project, tick Also add Redis (cache / queue / sessions) to this project under the database field.

For an existing project, open its Databases tab, choose Redis (cache / queue) under Database engine and press Create database.

Let the AI do it: a coding agent working with a link and token can create Redis itself, and Upload & go live (BETA) creates it automatically when it sees the code uses Redis, for instance through ioredis, redis or bullmq.

Once it is ready, REDIS_URL, REDIS_HOST, REDIS_PORT and REDIS_PASSWORD appear in the project's App settings tab. The app just reads them; you never copy a password by hand.

Rules worth knowing

One Redis per project, the whole instance belongs to that project — no key prefixes needed to avoid other projects
It does not count against the package's database quota; the Free package can add one next to its single main database
Reachable from inside the project only: the deployed app and commands on the Commands tab. The console's database browser does not work with Redis
Not backed up — the Backups add-on does not cover Redis either, because the app can rebuild its contents

Cache or queue: decided at creation

Two Redis modes: cache mode (the default) evicts keys with a lifetime first when memory is full, right for caches and sessions; queue mode never evicts and refuses writes when full, required by BullMQ, Celery, Sidekiq and rq. The mode is chosen at creation through the AI or Upload and go live

Each project's Redis has limited memory, so it needs a rule for when it is full. BrewInTH has two.

Cache mode (the default): when full, keys that have a lifetime are evicted first. Right for caches and sessions. The important part: give every key a lifetime, or keys without one pile up until nothing more can be written.
Queue mode (never evict): nothing is ever removed, so jobs never silently vanish. Queue libraries such as BullMQ, Celery, rq and Sidekiq need this.

Redis created from the console is cache mode. For a job queue, have your AI agent create the Redis with the "never evict" policy (noeviction); Upload & go live picks it by itself when it finds a queue library in the code. A Redis that already exists is not switched later.

Prompts that make the AI use Redis well

Cache the pages people open most

Add a Redis cache to the home page and the product list. Connect with REDIS_URL.
- Every key must have a TTL: 60 seconds for the home page, 300 for the product list
- When a product is edited in the admin, delete the related cache entries at once
- If Redis cannot be reached, keep the site working by reading the database directly, not an error
- Never store data we cannot lose in Redis

A queue for emails

Move the order-confirmation email to the background with a job queue on Redis (REDIS_URL).
- Create the project's Redis with noeviction if it does not exist yet
- The user gets an answer right away; the email job goes to the queue and retries 3 times on failure
- Run the worker in the same process as the web app (started with it) and log failed jobs
- Keep the "sent or not" status in the main database, not in Redis

The worker starts with the web app in one process because each project on BrewInTH runs one start command.

FAQ

Can Redis replace the main database?

It should not. Redis on BrewInTH is not backed up, and cache mode evicts keys when full. Members, orders, anything you cannot lose: keep them in the main database.

Does adding Redis cost extra?

It does not count against the package's database quota and has no separate price. Each project can have one.

Can I look at Redis data from the console?

The console's database browser works with PostgreSQL, MySQL and MariaDB only. To peek inside, have the AI write a small script and run it on the Commands tab, or add a statistics page to the app's admin.

Will Redis always make my site faster?

No. If the cause is a query without an index or pictures that are far too large, Redis will not help. Let the AI find the cause first with the prompt above.

What happens when Redis is full?

Cache mode: keys with a lifetime are evicted first; the site keeps working but recomputes more often. Queue mode: writes fail until queued jobs are processed. Have the AI check that the worker is running and that finished jobs are removed from the queue.

Summary

Redis is your site's counter whiteboard: it remembers what people ask for most, holds sign-in state and takes slow work into the background. On BrewInTH every project can add one without touching its quota. Pick the right mode, give every cache key a lifetime, keep important data in the main database — and if your small site is not slow, there is no hurry.

Start your first project for free →