Postgres & Redis

Choosing the datastore and the driver

Reach for Postgres when data is relational and must be durable and consistent: users, orders, ledgers — anything you’d run transactions over. Reach for Redis when you need speed and natural expiry: caches, sessions, rate-limiter counters, and lightweight job queues. They’re partners, not rivals — Postgres is the source of truth, Redis is the fast path in front of it.

Neither client is in the standard library:

# Postgres driver (works with database/sql, and has a richer native API)
go get github.com/jackc/pgx/v5

# Redis client
go get github.com/redis/go-redis/v9

Both manage their own connection pools internally, so you construct one client at startup and share it across goroutines:

// Postgres via pgx's native pool. The DSN here is a PLACEHOLDER —
// load real values from the environment, never hard-code credentials.
pgPool, err := pgxpool.New(ctx, "postgres://user:pass@localhost:5432/app?sslmode=disable")
if err != nil {
	log.Fatal(err)
}
defer pgPool.Close()

// Redis client (also a pool under the hood).
rdb := redis.NewClient(&redis.Options{
	Addr:     "localhost:6379", // placeholder
	Password: "",               // load from env in real apps
	DB:       0,
})
defer rdb.Close()

Cache-aside: Redis in front of Postgres

The most common pattern is cache-aside: the application checks the cache, falls back to the database on a miss, and populates the cache for next time.

graph LR
APP["request"] --> C{"in Redis?"}
C -->|hit| RET["return cached value"]
C -->|miss| DB[("read Postgres")]
DB --> SET["SET key with TTL"]
SET --> RET

func getUser(ctx context.Context, id string) (User, error) {
	key := "user:" + id

	// 1. Try the cache.
	if data, err := rdb.Get(ctx, key).Bytes(); err == nil {
		var u User
		if err := json.Unmarshal(data, &u); err == nil {
			return u, nil // cache HIT
		}
	} else if err != redis.Nil {
		return User{}, err // a real Redis error, not just "missing key"
	}

	// 2. Cache MISS: load from Postgres (the source of truth).
	var u User
	err := pgPool.QueryRow(ctx,
		"SELECT id, name FROM users WHERE id = $1", id).Scan(&u.ID, &u.Name)
	if err != nil {
		return User{}, err
	}

	// 3. Populate the cache with a TTL so it can't go stale forever.
	if data, err := json.Marshal(u); err == nil {
		rdb.Set(ctx, key, data, 5*time.Minute) // best-effort; ignore cache write errors
	}
	return u, nil
}

On a write, update Postgres first, then invalidate the cached key (rdb.Del(ctx, key)) so the next read repopulates from fresh data. The TTL is your backstop: even if an invalidation is missed, the entry expires.

See also

• database/sql — the generic layer pgx plugs into.
• SQL transactions — atomic multi-statement writes on Postgres.
• project layout & DI — inject the pg pool and redis client into your services.
• rate limiting — Redis counters as a distributed limiter.

Next: organizing all this into a project you can grow — Project Layout & Dependency Injection.

Related topics