Introduction

PostgreSQL that speaks Redis — storage and RESP co-located in one process.

Install the extensions, preload the gateway host, and Redis clients talk RESP to Postgres — storage and protocol in one process. The same gateway core can also run as a standalone service next to Postgres when you need that deployment shape.

# Preferred: everything inside PostgreSQL
redis-cli :6379 → BGWorker (pg_redis_gw_host) → redis.* SQL → Postgres

# Also supported: gateway as an external service
redis-cli :6379 → redis_gateway → same redis.* SQL → Postgres

# Memory mode (max throughput / weak guarantees): in-gateway map + optional snapshots
redis-cli :6379 → gateway HashMap ⇢ periodic/shutdown flush → unlogged redis.* tables

Product goal: CREATE EXTENSION (+ preload) and you’re speaking Redis — no separate app tier required for the common case.

Components

Path	Role
`pg_redis/`	SQL extension (`CREATE EXTENSION pg_redis` → schema `redis`)
`pg_redis_gw_host/`	pgrx BGWorker — RESP inside Postgres (primary)
`pg_redis_gw/`	Shared Rust core + standalone `redis_gateway` binary
`docker/` + `docker-compose.yml`	Postgres 16 + both extensions, RESP on `:6379`
`compat/`	Vendored Valkey TCL suite + allowlist

Tooling: mise for Rust / redis-cli / Node + bun (docs), Docker or Podman for Postgres.

Next steps

Quickstart

Install via Docker or Postgres extensions, then talk Redis on :6379.

Architecture

How the SQL extension, BGWorker host, and shared gateway core fit together.

Storage modes

Choose unlogged, logged, or memory mode for your durability trade-offs.

Contributing

Implement Redis commands the pg_redis way — SQL first, then wire binding.