3 ms·
Administering an RDBMS server is only part of the problem. It's also mentioned quite clearly there that by having data locality (just disk I/O) you get massive
by yawaramin 3y ago
Administering an RDBMS server is only part of the problem. It's also mentioned quite clearly there that by having data locality (just disk I/O) you get massive efficiency gains in queries and effectively don't have to worry about the N+1 query problem. Queries run in the order of microseconds, not milliseconds because of network latency.
- winrid 3y agoA DB server won't have to go to disk for every query, sqlite almost always will, or at least reach out from user space to virtual memory, which is still slower than reading from a buffer table. So ya, in process is faster for trivial stuff. But it's not faster when doing heavier workloads that benefit from things being in memory or having a better query planner.
- simonw 3y agoI don't think that's true? SQLite uses in-memory caching just like MySQL and PostgreSQL do.
- winrid 3y agoyeah my bad it does have a page cache: https://www.sqlite.org/arch.html https://www.sqlite.org/arch.html The more you know :) The query planner is still not nearly as good as PG's, but it's okay for simple applications. I have actually used sqlite "at scale"... I'm still not sure people know that system (30k+qps dumping data into kafka) is running on sqlite on an EBS volume lol. But in this case it's just streaming stuff from disk, so pretty much any DB would have worked.