2 ms·
The key point is more "an average computer & just sqlite can handle a lot of traffic", and not "if you're handling a lot of traffic, sqlite is probably fine".
by rgoulter 3y ago
The key point is more "an average computer & just sqlite can handle a lot of traffic", and not "if you're handling a lot of traffic, sqlite is probably fine".
Whereas, if you don't have much traffic, you're probably better off going with a simple solution (sqlite on an average computer) than prioritising scalability.
- iudqnolq 3y agoRight, and I'm trying to figure out an intuition for what a lot of traffic is. My current intuition said 100M bookings per day has a decent chance of being a lot for sqlite and even postgres depending on how it's distributed, so you'd want to get more specific in your reasoning
- rgoulter 3y ago> My current intuition said 100M bookings per day has a decent chance of being a lot for sqlite and even postgres depending on how it's distributed If you don't know the distribution of requests, assuming a constant rate simplifies calculations; and can be interpreted as "what if the traffic gets as high as this". sqlite can handle 50k inserts per second. -- Sure, if you need more than 50k inserts in a second, then you can't use sqlite. But, the rate of 50k/second sustained for a day would be half the world's population booking a hotel every day. (Since "seconds in a day" is much smaller than "half the world's population": that the rate for one day is staggeringly high indicates that that rate for one second is also staggeringly high).