Can I effectively turn off sync gateway versioning by setting max versions to 1?

Mobile
1

If I don’t care about previous revisions of documents can I safely set the max number of revisions allowed by sync gateway to 1? I just want to use sync gateway for authorization and syncing data to my mobile clients. If a new update comes in I just want last-write-wins and I don’t care if any data is lost in the document or overwritten this way. I plan to do this on Sync gateway 2.7.x CE. Since couchbaselite 2.X has built in conflict handling and removal I want this to ideally mean we never have a conflict and we always just have a single version of each doc, and couchbaselite and sync gateway use very few resources when resolving conflicts.

Some background: I am looking to upgrade sync gateway 1.3.1 and couchbaselite 1.4.1 to versions 2.7.x. In the current versions we allow the default number of revisions (1000) and have a lot of issues with document conflicts. Some of our documents have thousands of conflicting revisions and it causes sync gateway to use up all CPU and RAM on the server it runs on and then slow to a crawl or crash. Most of the time it uses 10% CPU or less and not much RAM, then in busy periods it goes up to around 20% CPU, then if a single user with a lot of conflicts starts using our app it goes up to 100% CPU and will stay there until we restart it. As part of the upgrade we will do a clean migration where we remove all old metadata so there are no previous revisions in the docs when they get migrated to the DB hosting our new versions.

2

If you are on 2.x CE version of Sync Gateway and Couchbase Lite and you have allow_conflicts set to be false (which happens to be default) then you can set revs_limit to 1.

1 Like
3

Great, thanks! I’ll try it out when we’re ready to test couchbaselite 2.X and sync gateway 2.X and let you know how it goes.

4

@alexegli Could you share how this worked out for you?

I’m setting up cblite for a similar use case and trying to figure out best config. Thanks!

5

We ended up testing with the default setting of 20 versions and it worked well for us so we didn’t try having just 1 version. No matter what we did we found that conflicts were resolved well automatically. E.g. we had one test where we had three devices all writing 1000 versions of a doc in sequence at the same time without pulling the latest version in between writes and we had no issues and the doc ended up with only 20 versions in the sync metadata and no unresolved conflicts.

We decided 20 was fine for us since it’s small enough that it doesn’t bloat document sizes, the automatic conflict resolution works well, and we thought it reduces the likelihood of issues coming up where conflicting branches are longer than the number of allowed revisions.

6

That’s great to know, thanks so much for the followup!