Multiple databases, single or multiple sync stores?

DEVONthink
1

I have more than 10 databases and all of them sync to syncstores on pCloud WebDAV (now testing Koofr WebDAV too).

Currently I divide the databases into like 4 groups and each of them sync to one syncstore. So on my PCloud WebDAV, I have 4 syncstores.

I wonder what’s the best practice for my case. Should I setup one syncstore corresponding to one database, or one syncstore to sync to all databases?

I had a feeling that during the syncing on iOS and Mac, it seems to me that it takes some time to switch to another syncstore, and that results in longer load time, more connection errors and more battery consumption.

Btw, I have -1005 connection errors and / or authentication errors every 1-2 minutes during syncing to pCloud WebDAV. Same error when I sync to Koofr WebDAV. Not sure if that’s related to my setup. I remember I didn’t have this error in the old days (Devonthink 2) when syncing to Box WebDAV.

2

Why?

3

Somehow some databases were supposed to be shared with different groups teammates.
I I created different logins for them to access pCloud.

But that’s no necessary anymore. That’s why I was asking if there’s any best practice or it doesn’t matter at all.

4

I’m using about eight databases, all with the same (local) WebDAV sync store. No problems so far.

1 Like
5

I guess you set up your own WebDAV?

6

Yes, I’m running a WebDAV server on a Synology NAS.

7

This is for you to answer. Unless you’re in a situation that requires conformity to how the data is organized, do what makes sense and is effective for you.

We blogged about this recently…

8

Oh thanks. That clears up my confusion.

I continue to read the related blog articles (DEVONtechnologies | Understanding DEVONthink's Sync) and read:

  • Remote sync locations have technical challenges posed by unstable networks, slow or unresponsive servers, or bandwidth/connection throttling. We suggest you use a remote sync option when it’s needed, not just because you have a cloud account.

@BLUEFROG
Is there any rule of thumb during your internal testing that qualifies as undesirable remote sync location? Like latency above or speed lower than certain values?
How should I assess a cloud location for a syncstore?

9

Again clarifying we suggest using a local sync on your network unless a remote option is needed, there is no specific metric other than anecdotal experience, i.e., how does it work for you.
For example, there are people who have had no issues with CloudKit; there are many who have.

10

One scenario might be where something goes wrong with a Cloud-based syncstore, and you may have to ‘clean it’ and reupload. This has happened from time to time for me. If all DBs would sit in a single syncstore, you’d spent more time waiting for your materials to upload, which could be immaterial or a huge pain depending on your upload time? I had some persistent trouble with one largish DB (40GB) which eventually I moved to its own syncstore so I could trouble shoot it without messing up the rest. That said, this problem eventually went away and at present, my 7 or so DBs all use the same (Dropbox) syncstore without a hitch.

I have no experience with WebDAV, but I’m sure others can help here. Good luck!