3 ms·

There are many use cases where scaling a traditional centralized SQL database is problematic, that can be addressed by something like this. We have one: we run

There are many use cases where scaling a traditional centralized SQL database is problematic, that can be addressed by something like this. We have one: we run thousands of VMs at a time, all accessing the same "database". Since we already have a good amount of horizontally-scaled compute, having to maintain a separate database cluster, or large vertically-scaled database instance, to match our peak load requirements is problematic in terms of one or more of cost, complexity, and performance. In particular, horizontally-scaled distributed databases tend not to scale up and down efficiently, because of the complexity and time involved in joining the cluster, so the cost benefits of horizontal scaling of compute are lost. An approach like this can fit well in cases like these.

eterevsky 3y ago
I can't see how this could for a readonly database, but how would you resolve collisions on writes and don't make them super slow in the process?
- antonvs 3y ago
  Right, it certainly wouldn’t work for a big multi-tenant db. But the right data organization can make it work. In our case, the data is organized such that there’s usually only one client at a time that would need to write to a given db file. Think for example of a folder per user, each containing a db file and various other files for that user. What we’re doing is actually even more granular than that - we have a folder for each object that a user could be working on at a given time.