Autopublish memory overhead and state tracking limits

DDP State Management with Autopublish

Meteor'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?