I am ashamed to admit I've run into a case where SQlite was the wrong choice. I have a cluster of 20 Windows 7,8,10,11 machines spread across multiple sites th

I am ashamed to admit I've run into a case where SQlite was the wrong choice. I have a cluster of 20 Windows 7,8,10,11 machines spread across multiple sites that I wanted to run some log analytics. This was for some custom software running on all 20 machines which had a SQlite API. So I did the simplest and cheapest thing that would work. I setup sync.com folder on all machines (think dropbox/ onedrive) to write logs to the same log.db file across all machines. This worked great at first (I could analyze the db remotely). However you see the potential problem here... Logging was maybe a few writes an hour PER MACHINE but inevitably you start getting conflicts (since sync takes a 5-30 seconds to actually sync). Now I am faced with merging 20 conflicting log.db files. In theory I should have used a server based SQL database. Or perhaps I should have just lived with 20 different log.db files. In my defense there was only SQlite API so I would have had to write some middleware to transfer to another DB.