PostgreSQL that speaks Redis.

For self-hosters

Are you a self-hoster? I’ve got news for you.

Many apps ship a compose file with Postgres and Redis for cache, sessions, or queues. Point Redis at PostRESP instead — one database to run, back up, and upgrade.

services:  postgres:    image: postgres:16    ports:      - "5432:5432"      - "6379:6379"   redis:    image: redis:7    ports:      - "6379:6379"   app:    image: your-app:latest    environment:      DATABASE_URL: postgres://…@postgres:5432/app      REDIS_URL: redis://redis:6379    depends_on:      - postgres      - redis

Honest bit: slower than Valkey on a microbenchmark. For a normal self-hosted app, you won’t notice. See benchmarks and verified apps (smoke-tested drop-ins — candidates welcome).

For small teams

Speak Redis now. Swap the endpoint later.

Don’t invent a SQL cache you’ll rewrite when you need Redis. Use a normal Redis client against PostRESP today — when traffic demands it, point the same client at Valkey or Redis.

1. 01

   Ship with Postgres + PostRESP

   One process. Standard Redis clients. No second service in your architecture diagram.

2. 02

   Keep the client code

   SET, GET, lists, TTL — the wire protocol is Redis. Your app doesn’t special-case Postgres.

3. 03

   Graduate when you must

   Outgrow the latency budget? Change the host. Same clients, same commands — not a rewrite of your cache layer.

Honest bit: if you’re already at Redis scale, keep Redis. If Redis is in the stack because the README said so — start here. Numbers on the benchmarks page.