4 ms·
> In the case of SQLite there isn’t much to configure, but PostgreSQL does have some tuning levers to play with. Indeed. If we don't bother to benchmark our ab
by bob1029 3y ago
> In the case of SQLite there isn’t much to configure, but PostgreSQL does have some tuning levers to play with.
Indeed. If we don't bother to benchmark our ability to insert or modify records, there isn't much tuning that is relevant.
SQLite with appropriate configuration for WAL, et. al. can run circles around hosted SQL providers for many classes of non-queries. SQLite directly on top of NVMe storage is a monster.
- rstuart4133 3y agoI think we can assume on his Macbook it was SQLite running on NVMe, and even so SQLite was out monstered by PostgreSQL by a large margin according to his figures. It would be interesting to know why. I would have thought for single queries the IPC overhead would put PostgreSQL at a disadvantage. Apparently not. In fact a lot of things are puzzling. I would have expected PostgreSQL to win when there are lots of independent queries because it can aggressive caching, whereas SQLite has to assume lots of independent process are having their way the the database. Again that didn't happen - the rate speed dropped as the query rate increased was similar for both.
- foofie 3y ago> SQLite with appropriate configuration for WAL, et. al. can run circles around hosted SQL providers for many classes of non-queries. SQLite directly on top of NVMe storage is a monster. Are there any benchmarks that put hard numbers on these observations? I expect sqlite to outperform postgres for the fact alone that it doesn't need to make a network call to touch the db, but it would be important to know what these observations actually mean in the real world.