NetBox and Redis: how much of the required backing-service footprint can a low-traffic deployment safely shrink?

I'm planning a NetBox deployment for a low-traffic internal workload and want to keep infrastructure cost minimal. Since NetBox is open-source, the real cost driver is its documented stack: the Django application plus one PostgreSQL database and one Redis instance. I'm trying to decide how far I can consolidate that footprint without breaking supported behavior.

My understanding is that Redis is a hard dependency, used both for caching and for the RQ background task queue (webhooks, reports, custom scripts), so it can't simply be dropped. That leaves consolidation as the main lever: running NetBox, PostgreSQL, and Redis on a single small host, reducing gunicorn worker counts and RQ worker processes, and keeping plugins disabled. But I haven't found documented guidance on where the practical floor is, or whether the interoperability boundary with Redis is strict.

Two points remain unresolved for me. First, managed PostgreSQL and Redis services dominate small-deployment cost, but self-hosting both on the same node removes redundancy — acceptable for a lab, questionable otherwise. Second, Redis-protocol-compatible alternatives (such as Valkey) are not in NetBox's documented support matrix, so substituting one to cut managed-service cost feels unverified and version-sensitive.

Is there any documented minimum or recommended footprint for a low-traffic NetBox instance, or is sizing purely empirical per dataset? Does NetBox officially support Redis-compatible alternatives at the caching/RQ boundary, or only Redis itself? And is co-locating all three components on one host considered a supported topology, or merely a tolerated one?