Redis oplog vs MongoDB change streams

help
1

I have been following Meteor for years, and I always had my reservations about MongoDB oplog tailing.

As I understand it, with the release of Meteor 3.5, oplog tailing has been replaced by change streams.

I have always thought Meteor would benefit from moving oplog tailing to Redis, and after seeing the redis-oplog package, I assumed the Meteor team would see the benefit in using Redis for change tracking and maybe integrate redis-oplog officially to Meteor. (Although I understand the caveats of having limited resources, I have the same bottleneck with the projects I’m managing.)

So my first question is, does the move to MongoDB change streams break the easy integration with redis-oplog?

I also read somewhere that redis-oplog was abandoned, but since I am not using Meteor every day (I really wish I could), I am really curious how much data users of Meteor are managing in their applications, and the resource amount they employ. (I know you can’t exactly quantify the phrase “how much data”, but it should give me some idea about resource requirements.)

1 Like
2

This is a good question. I would assume the underlying functionality of redis-oplog doesn’t automatically work with how Meteor and change streams works. And that enabling change streams deprecates the need for redis-oplog. But I wouldn’t mind some official Meteor team insight on this.

We are currently running our production app on Meteor 3.3.2 using the original cultofcoders:redis-oplog@3.0.1 So it is still running good in production.