Previous versions of our flagship software, Syncplify Server!, did use MongoDB to store their configuration and metadata. Over the years, though, we had to accept that MongoDB is not always reliable, especially on Windows, when certain circumstances arise. This becomes painfully obvious when an unclean shutdown of the operating system occurs, and MongoDB fails to start when the machine reboots, until you manually clean up its lock file and/or repair its data files. It’s also not uncommon enough to find MongoDB suddenly unable to accept client connections for no apparent reason.

This was becoming more than just an annoyance. It was starting to affect our customers. So, mainly but not only for this reason, we embarked in the gigantic endeavor of developing our own backend DB.

First of all, the name. SyngoDB is not named after MongoDB, it’s actually the composition-abbreviation of three concepts: “Syn” for Syncplify, “go” because it’s written in Go, and “DB” because (drum-roll) it’s a DB.

So, what are the similarities and the differences between MongoDB and SyngoDB?

Let’s start with the similarities, because there are very few: both of them are schema-less, document-oriented, NoSQL databases. And that’s pretty much all they have in common.

The differences on the other hand, well, where do we even start? We’ll cover just a few of the most significant ones.

First and foremost, SyngoDB doesn’t have any of the powerful data manipulation and analytics functions that are a core value of MongoDB. Nor does it have MongoDB’s massive horizontal multi-node (replica-set) scalability. That wasn’t the goal in the first place.

SyngoDB, essentially and by design, had to achieve only three goals:

We’re happy to report that SyngoDB has met, and even exceeded, our expectations. All of the design goals were achieved, and it’s now the backbone of our flagship product Syncplify Server!