Yeah... I had similar feelings about it... I'm planning on just running a single node stack via docker-compose for my use, with daily rsync for backup. Should

Yeah... I had similar feelings about it... I'm planning on just running a single node stack via docker-compose for my use, with daily rsync for backup. Should be more than enough for the handful of users I'm likely to have. I'd probably break attachments into object storage first, ahead of touching the rest of the MongoDB. If you do that, read replication for mdb should be relatively easy, or possibly just rely on their hosted/managed option. If you're in AWS, they have that as well. I get the feeling though, had to recover a borked cluster about a decade ago when Azure was going up/down for a few hours and the oplogs were hopelessly out of sync... Fortunately, they were just read replicas, not sharded, so was faster in the end (after trying other options) to just break and re-build the two replica nodes. No idea how I would have handled things depending on the scenario if it was sharded. When I've used Mongo, I'll push the record update into a queue, that then gets stored in object storage. Worst case would be importing everything in to the collections from object storage. Mongo definitely isn't the first thing I reach for at all since then, and I'd rather use pg or cockroachdb myself.