Syncthing 2.0 (August 2025)

Here we go!

Specific note for our Debian/APT users: to provide a soft start, you won’t get an immediate auto upgrade to 2.0. It’s under a new component stable-v2 for now: https://apt.syncthing.net

27 Likes

Arch Linux updated to v2.0.0 today and so far it seems to work great.

I also updated my openSUSE Tumbleweed machine yesterday and since it works I created a submission for official Tumbleweed repos.

Syncthing Tray is also ready to be released with its built-in Syncthing updated to v2. However, I still want to do some further testing on Windows and Android before making a new release. The currently latest release also works with v1 and v2 so there’s no need to rush a new release.

I configured the Tumbleweed package and my Syncthing Tray builds with -tags libsqlite3 to use the SQLite3 library provided by the system or additional/separate packaging. I hope this is ok but so far I haven’t noticed any problems (also during my tests with RC releases).

3 Likes

There’ll be a 2.0.1 this afternoon or tomorrow to gather the couple of bugs that were reported so far, so if you’re shipping things with a built-in Syncthing you might want to use that one instead. (The most important fix probably the one where it fails on database paths with URL-special characters.)

2 Likes

First collection of bugfixes: Release v2.0.1 · syncthing/syncthing · GitHub

3 Likes

2.0.2 is Go 1.25 and build changes to Windows & macOS to use native user & name resolution again: Release v2.0.2 · syncthing/syncthing · GitHub

3 Likes

2 posts were merged into an existing topic: Syncthing Go build version

Further stability & compatibility fixes, especially around database migration: Release v2.0.3 · syncthing/syncthing · GitHub

5 Likes

3 posts were split to a new topic: Syncthing Go build version

Here’s the latest sprinkling of bugfixes, and a slightly faster database schema (migration on startup, though hopefully not quite as lengthy as the initial one): Release v2.0.4 · syncthing/syncthing · GitHub

5 Likes

A post was split to a new topic: Build log output

And a quick egg-on-my-face update because I made it incessantly vacuum, caught & fixed by @pixelspark: Release v2.0.5 · syncthing/syncthing · GitHub

7 Likes

I’m wondering why the VACUUM part seems to take so long and use so much resources for some users. On my devices, even the very weak ones (e.g. this one :zany_face:), the whole VACUUM process takes maybe 10-15 minutes maximum. On good hardware, it’s a matter of 1-2 minutes.

On my M1 Max, it took about 10 seconds for a database at ~2.3GB. I only noticed because any extra delay in starting an app is very noticeable and annoying when you are in a edit-build-test cycle in XCode.

A VACUUM basically rewrites the whole database, so it requires reading (and to some extent buffering) the (in my case) 2,3 GB, then writing it out in parallel. Then it does so using the journaling mechanism, so there is some additional overhead there as well.

We’re effectively doing the vacuum in-memory at the moment… :clown_face: Let’s keep the discussion in the other thread Syncthing DB Migration Errors? - #15 by calmh

1 Like

Fixes the excessive memory usage during migration: Release v2.0.6 · syncthing/syncthing · GitHub

4 Likes

Thanks a lot for fixing this so quickly! :clap:

Hopefully, this will allow those users perform the migration successfully.

3 Likes

2 posts were split to a new topic: Syncthing 2.0 memory usage

Further fixes and tweaks: Release v2.0.7 · syncthing/syncthing · GitHub

6 Likes

For those that don’t follow the development closely, this release is major, as it can reduce RAM usage drastically, especially for those with a large number of folders (like myself). :slight_smile:

3 Likes