Database choices

Twitter and most other apps/services in this kind of business, are using highly-distributed NoSQL because ACID is not really a requirement here. Is there any reason Mastodon started and continues on PostgreSQL? Can anyone point me to the thread or readme about how Gargron decided to design around a non-distributable DB? I believe it offers no special features, slower response times and hurts creating multi-server instances.

I don’t know why #PostgreSQL has been chosen, but that does not have to be a bad choice. npm is moving its services towards a PostgreSQL-based backend.

Very odd, since the autoscaling, elastic world of cloud computing is moving away from strict ACID to more distributed solutions that *SQL servers. RDBMS have their unique features but they also put heavy restrictions/penalties on scaling, and I don’t think Mastodon is really in need of any of those special features. If it was based on a NoSQL K/V store of some sort (Casandra is one example, but there are many others) one could very easily create an instance that is spread across dozens of servers, or rather a dynamic number of servers as needs come and go, and the backend would be a cluster of machines that can grow and shrink automatically, which is not an option with pgSQL.

As for NPM, I don’t know the product well at all, I have no idea what they were not getting out of CouchDB, so I can’t comment.


(I moved this to a new topic since it’s not about 1.4.1 but about Mastodon choices in general. -@noelle)

is this causing problems for anyone right now or is it more of a general future concern?

1 Like