IME when SQLite is applicable (mostly the one writer limit), it usually runs circles around to server DBs, provided: - you have comparable CPU - you have enough cache memory, or free RAM for OS disk caching, to be in a comparable memory scenario - you do not have a virtualisation layer, especially compared against a server DB running on bare-metal, as that can make a huge difference in effective IOPS
Also the ability of SQLite to smoothly work with temporary tables can make a world of difference when faced with complex queries. That is not something that will show in 1:1 benchmarks, but when a complex query can be broken down into several simpler queries + temporary tables, well, you can save lots on both execution and debugging times. On Tue, Feb 16, 2016 at 3:02 PM, olivier vidal <vidal.olivier at mac.com> wrote: > > obviously it will never be perfect . We already know the benefits of each > database , including those of SQLITE . This is not because there is a > benchmark that people are not going to look at all the other features. But > in equal hardware, it gives a small indication of current performance, as > sqlite.org had done a long time ago. > > Simon Slavin a ?crit : > >> On what hardware ? Should the SQLite test be on a laptop because SQLite >> will run on a laptop ? Or should you test both on identical hardware even >> though they're unlikely to run on identical hardware ? Should you include >> the time taken to install and configure PostgreSQL in the times quoted >> because it takes no time to install or configure SQLite ? >> > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
