Autopublish memory overhead and state tracking limits

Question

DDP State Management with AutopublishMeteor's Distributed Data Protocol (DDP) manages real-time synchronization by tracking which documents are pushed to each client session. When using the autopublish package, the server automatically synchronizes all database collections to every connected client without manual subscription definitions.Because the server maintains the subscription state in memory, there is a direct relationship between the volume of data in the collections, the number of active client sessions, and the total server memory consumption. This creates a scaling constraint where the lack of granular filtering in autopublish may lead to significant memory pressure as the dataset grows.What are the specific memory overhead limits per connected client when autopublish is active?At what threshold of document count or concurrent sessions does the server-side state tracking typically trigger performance degradation?

Tasadduq Burney · Answer

Answer firstNo official per-client memory limit or universal document/session threshold is published for autopublish. The overhead is workload-dependent and grows with the number of active clients multiplied by the volume and size of published documents. There is no fixed cap in Meteor; degradation occurs when server RSS, oplog tailing CPU, and per-client DDP queues saturate.
Confirmed facts

The autopublish package automatically publishes all fields of all Mongo collections to every connected client with no limits, filters or pagination.
Each client subscription creates a server-side observer and per-client DDP state. The server tracks which documents were sent to that client and maintains diffs for reactive updates.
Autopublish is deprecated and removed in modern Meteor releases. Behavior and removal steps are version-sensitive.

Likely explanation
Memory overhead scales with active clients × published document volume × average document size, plus oplog tailing and per-client cache overhead. This leads to rapid RSS growth and risk of OOM under moderate load.
State tracking limits typically appear as increased CPU for oplog tailing, growing DDP message queues, client Minimongo memory bloat, and latency spikes when large collections change. The exact point of degradation changes with client count, collection size and document churn rate.
Steps needed for this case

Verify current setup. Check installed packages and Meteor version:
meteor list | grep autopublish
cat .meteor/release

Do not remove autopublish without replacement. Removing it without equivalent publications will break client data access.
Replace broad publishing with explicit publications using limits, field whitelists and pagination, and replace broad subscriptions with targeted ones per view.
Monitor before and after:

Server RSS and DDP subscription count under load
Per-subscription document counts
Client Minimongo size

One missing diagnostic that changes the recommendation: current Meteor release and approximate total documents published per client plus typical concurrent sessions. With that, the replacement publications can be sized safely.

Autopublish memory overhead and state tracking limits

DDP State Management with Autopublish

1 answer

Answer first

Confirmed facts

Likely explanation

Steps needed for this case

Your perspective belongs here.

1 question comment

Why Autopublish Inflates Memory

Practical Measurement