Docs / Build your stack

Valkey or Redis

Valkey and Redis are in-memory key-value stores, used as a cache, for sessions, for rate limits and as a fast job queue. In TractorStack they are optional. Many setups will never need one, and the design doesn’t add one by default.

When it is worth adding

Add Valkey or Redis when at least one of these is true:

• An application you run already requires it. Many off-the-shelf products do.
• You need a cache in front of slow queries or external calls, and you have measured that the database is the slow part.
• Job volume is high enough that a PostgreSQL queue table is causing lock contention or bloat.
• You need pub/sub or short-lived counters with very low latency.

If none of these apply, leave it out. One fewer service means one fewer thing to patch, monitor and back up.

Why PostgreSQL can be the queue

At small and medium scale a plain table works well as a job queue. Workers pick jobs with SELECT ... FOR UPDATE SKIP LOCKED, which lets many workers take different rows without blocking each other. Jobs are then covered by the same backups, transactions and access controls as the rest of your data, and a job can be queued in the same transaction as the change that caused it. See PostgreSQL.

Valkey or Redis: the licence question

In 2024 Redis changed its licence from BSD to a choice of source-available licences. In response, Valkey was forked from the last BSD-licensed release and is now run under the Linux Foundation with a BSD licence. Later, Redis 8 added the AGPL as a further option. That means both are now usable under some open-source licence, but the terms differ, and what fits depends on how you run and distribute your software.

The TractorStack design defaults to Valkey because its licence is the simplest for an on-premise platform that customers keep. Redis remains an option where an application needs a Redis-only feature or a vendor requires it. We are not giving legal advice here: check the current licence terms with whoever handles that in your organization.

Role in each stage

• Stages 1 and 2: if used, a single instance in Compose or on the data host, on a private network only. In design
• Stage 3: stays next to the other data services on a VM, or runs in the cluster when it is only a disposable cache. Planned
• Stage 4: in the cluster, managed through a chart or operator. Exploring

Planned configuration

A planned example of the optional service in Compose. Illustrative only.

# Planned example only: compose/valkey.yaml
services:
  valkey:
    image: registry.example.internal/valkey:8.0.2
    command: ["valkey-server", "/run/secrets/valkey.conf"]
    secrets: [valkey.conf]   # holds requirepass and memory limits
    profiles: [cache]
    networks: [data]
    restart: unless-stopped

Using a Compose profile means the service only starts when you ask for it.

What stays yours

• The decision to run it at all, and which of the two
• Its password and network placement

Limits and caveats

• Treat it as a cache, not a system of record. Persistence options exist, but the design keeps durable data in PostgreSQL.
• Never expose it outside the private data network.
• Memory sizing matters. A full instance evicts keys or rejects writes, depending on settings.
• The exact flags in the example above are illustrative; check them against the version you deploy.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com