4 ms·

It feels bad to make a database choice which isn't capable of supporting lots of writes. Lots of things start small but get big unexpectedly, and if you choose

It feels bad to make a database choice which isn't capable of supporting lots of writes. Lots of things start small but get big unexpectedly, and if you choose sqlite then now you have to rearchitect things.

shimonamit 4y ago
Note the difference between "lots of writes" and "lots of concurrent writes". "Lots of writes" in succession without heavy concurrency support is just fine for desktop/mobile apps. It is not okay for busy webapps.
- why_only_15 4y ago
  Oh hmm what do you mean by concurrent here? Several writes in succession to the same place or writes that other users need to be able to read quickly?
boomlinde 4y ago
> Lots of things start small but get big unexpectedly, and if you choose sqlite then now you have to rearchitect things. Lots of things predictably don't. It seems like bad engineering to operate as though everything will. Especially in appliances/"IoT" and other embedded use cases, that line of thinking can drive production costs up a lot.
- why_only_15 4y ago
  The majority of new things people build fail (say 95%), but it's still worth building for the success case because essentially all of the value comes in the success case. It increases cost on average but it means your website doesn't go down under load the second it's successful. This is only true to an extent of course -- don't build your startup like it's Google. But to a certain degree it's worthwhile architecting for some scale before you have it. In the context of embedded things of course you should use something like SQLite as opposed to postgres, because there aren't going to suddenly be millions of people using your CO2 monitor (for example). But for web stuff you can plausibly have user counts that span 6 or 7 orders of magnitude, so you want to be prepared for that.
nl 4y ago
"Many concurrent writes" is challenging to many parts of most architectures, not just databases. For example it means your caching strategy has to be more complicated than with most read-heavy apps.

shimonamit 4y ago

Note the difference between "lots of writes" and "lots of concurrent writes". "Lots of writes" in succession without heavy concurrency support is just fine for desktop/mobile apps. It is not okay for busy webapps.

why_only_15 4y ago
Oh hmm what do you mean by concurrent here? Several writes in succession to the same place or writes that other users need to be able to read quickly?

boomlinde 4y ago

> Lots of things start small but get big unexpectedly, and if you choose sqlite then now you have to rearchitect things. Lots of things predictably don't. It seems like bad engineering to operate as though everything will. Especially in appliances/"IoT" and other embedded use cases, that line of thinking can drive production costs up a lot.

why_only_15 4y ago
The majority of new things people build fail (say 95%), but it's still worth building for the success case because essentially all of the value comes in the success case. It increases cost on average but it means your website doesn't go down under load the second it's successful. This is only true to an extent of course -- don't build your startup like it's Google. But to a certain degree it's worthwhile architecting for some scale before you have it. In the context of embedded things of course you should use something like SQLite as opposed to postgres, because there aren't going to suddenly be millions of people using your CO2 monitor (for example). But for web stuff you can plausibly have user counts that span 6 or 7 orders of magnitude, so you want to be prepared for that.

nl 4y ago

"Many concurrent writes" is challenging to many parts of most architectures, not just databases. For example it means your caching strategy has to be more complicated than with most read-heavy apps.