Phoenix.PubSub adapter selection for low-traffic cost optimization

Question

Infrastructure Cost vs. Scalability
When deploying a low-traffic Phoenix application, minimizing operational overhead and monthly spend is a primary goal. The choice of Phoenix.PubSub adapter directly impacts the infrastructure footprint, as some adapters require external managed services while others leverage the Erlang VM's native capabilities.
Adapter Constraints
The default PG2/PG adapter utilizes Erlang process groups, allowing for a zero-cost PubSub implementation provided the nodes can maintain a full Erlang distribution mesh. Conversely, the Redis adapter removes the requirement for a distribution mesh and supports cross-cluster communication but introduces a managed service cost and an additional failure domain.
For a workload with minimal traffic, it is unclear whether the immediate cost savings of the native adapter outweigh the potential technical debt of migrating to Redis as the application scales to multiple nodes or separate clusters.

Does the native PG2/PG adapter provide sufficient reliability for low-traffic production environments without requiring an external broker?
  At what scale of node distribution does the overhead of maintaining an Erlang mesh exceed the cost and complexity of a managed Redis instance?

Tasadduq Burney · Answer

Answer
For a low‑traffic Phoenix deployment that remains within a single VPC or region, the built‑in Phoenix.PubSub.PG adapter is the recommended choice.
Confirmed facts

PG uses Erlang pg process groups and requires a fully connected Erlang distribution mesh.
PG adds no external service cost and introduces no extra failure domain beyond the VM network.
Redis removes the mesh requirement but adds a managed‑service cost and an additional failure domain.
Mesh connection overhead grows roughly O(N²); for clusters under roughly 10‑20 nodes the overhead is typically negligible compared to the cost of a managed Redis instance.

Likely explanation
When traffic is low and all nodes share a private network, the Erlang mesh stays small, so the CPU and memory cost of maintaining PG connections is minimal. The zero‑cost adapter therefore yields lower monthly spend than paying for a managed Redis instance. Only if you anticipate needing nodes across regions, providers, or behind firewalls that block direct Erlang connections does the trade‑off shift toward Redis.
Steps to verify PG suitability

Confirm config/prod.exs uses Phoenix.PubSub.PG (not the removed PG2).
On each node, run Node.list() in the production console; the list length should equal node_count - 1.
Monitor network latency and partition events (e.g., via :net_kernel.get_net_ticktime() or observability tools) to ensure the mesh stays connected.
If you observe frequent disconnections or plan to exceed ~20 nodes, re‑evaluate the need for Redis.

Missing diagnostic detail that could change the recommendation: What is the expected maximum number of Elixir nodes, and will they be deployed in the same VPC/region?

Phoenix.PubSub adapter selection for low-traffic cost optimization

Infrastructure Cost vs. Scalability

Adapter Constraints

1 answer

Answer

Confirmed facts

Likely explanation

Steps to verify PG suitability

Your perspective belongs here.

0 question comments