Change Streams

New in version 3.6.

Change streams allow applications to access real-time data changes without the complexity and risk of tailing the oplog. Applications can use change streams to subscribe to all data changes on a collection and immediately react to them.

You can only open a change stream against a replica set or a sharded cluster with replica set shards. For development environments, a single-member replica set or shard replica set is sufficient to utilize change streams.

Change streams can benefit architectures with reliant business systems, informing downstream systems once data changes are durable. For example, change streams can save time for developers when implementing Extract, Transform, and Load (ETL) services, cross-platform synchronization, collaboration functionality, and notification services.

See Change Stream Examples for examples of opening and configuring change streams.

Change streams only notify on data changes that have persisted to a majority of data-bearing members in the replica set. This ensures notifications are triggered only by majority-committed changes that are durable in failure scenarios.

For example, consider a 3-member replica set with a change stream cursor opened against the primary. If a client issues an insert operation, the change stream only notifies the application of the data change once that insert has persisted to a majority of data-bearing members.

For deployments enforcing Authentication and authorization, applications can only open change streams against collections they have read access to.

Change streams are resumable, as long as the cluster still has enough history in the oplog or each shard replica set’s oplog to locate the last operation that the application received. See Resume a Change Stream for documentation and examples on resuming change streams.