Sizing Redis, queue, and Postgres resources for self-hosted data planes

Last updated: October 12, 2026

Overview

Self-hosted LangGraph/LangSmith data planes let you size Redis, queue worker, and Postgres resources per deployment through the control-plane deployment API. This article covers how each resource is sized, a validation gap that can make a resource PATCH look successful when it isn't, and the current limits on setting defaults across deployments.

Redis sizing and listener version dependency

Redis CPU and memory are set per deployment with redis_cpu, redis_cpu_limit, and redis_memory_mb. What values are actually accepted and applied depends on the listener version running in your data plane, not just on what the control plane validates.

Older listener versions hardcode the Redis container's CPU request/limit to 1, regardless of what you PATCH, and enforce a memory floor of 2048Mi (rejecting anything lower, capping at 16384Mi). Current listener versions render redis_cpu/redis_cpu_limit from the PATCH correctly, and accept redis_memory_mb from 512Mi up to 16384Mi, in 128Mi increments.

Because the control plane validates PATCH input against its own current rules rather than the specific listener version installed in your data plane, a value the control plane accepts (200 OK, revision shown as deployed) can still be silently ignored or later rejected by an older listener at deploy time. In practice this shows up as either:

The PATCH succeeds but spec.redis.resources on the rendered deployment is unchanged and the Redis pod is never recreated, or
The revision later fails with a memory-range validation error (e.g. a minimum-value error) even though the PATCH itself returned 200.

Very old listener versions also reject fractional CPU values outright for Redis/queue fields (integer-only validation), producing the same accepted-then-failed pattern. A bad stored resource value can poison every subsequent revision of that deployment, including unrelated image redeploys, until it's corrected.

Keep listener and operator versions current to avoid this gap. Upgrading to a listener version that implements full Redis CPU/memory rendering and the lowered memory floor resolves both the "override not applied" and "memory floor too high" issues. After upgrading, PATCH each affected deployment with a full resource spec: existing deployments don't automatically restart or re-render their resources just because the listener/operator was upgraded. The resource spec is replaced wholesale on PATCH, not merged field by field, so always send the complete spec.

Queue worker CPU autoscaling

The queue worker's CPU-based autoscaling trigger always targets a fixed percentage (50%) of the configured CPU limit, not the CPU request. If you lower only the CPU request in a PATCH and leave the limit unset, the limit defaults to 2x whatever request you set, so the effective scaling target still moves with the limit, not the number you intended to tune.

To get a predictable scaling target, set both queue_cpu and queue_cpu_limit explicitly on every PATCH rather than relying on the default multiplier. Running the queue worker without a CPU limit, so that autoscaling tracks request-based utilization instead, is not currently supported in any shipped self-hosted release.

Postgres sizing

Postgres resources are sized independently of Redis and queue settings, using dedicated CPU/memory request and limit fields in the deployment's resource spec (db_cpu, db_cpu_limit, db_memory_mb, db_memory_limit_mb). As with queue CPU, the limit defaults to 2x the request when the limit is omitted. These fields only take effect for control-plane-provisioned Postgres; they're ignored if the deployment uses a customer-managed/external Postgres instance.

No org or workspace-level resource defaults

There's currently no way to set default resource sizing once at the org or workspace level. Every deployment's resource spec (Redis, queue, Postgres) must be set individually per deployment. If you need consistent sizing across many deployments, standardize a shared deployment-creation configuration or template and apply it each time you create a deployment.

As an alternative to control-plane-managed Redis or Postgres, you can point a deployment at a customer-managed Redis or Postgres instance using the corresponding custom-URI environment variables (for Redis and Postgres respectively). This moves resource sizing outside the deployment resource spec entirely. Multiple deployments can share the same underlying instance as long as each uses a separate database (Postgres) or a separate database number (Redis); sharing the same Redis database across deployments is not supported.