The important nuance here is that with SQLite you can achieve similar numbers even if each of the 1000 queries is dependent on prior results.
SELECT 1 is hardly representative of a real world situation wherein you need to logically serialize each transition of business state.
Re:Siren Call of SQLite on the Server
by jbverschoor on Tuesday February 18, 2025 @03:32PM
(#43094695)
0.08 seconds for a few bytes, which are fully cached, yet it barely can reach 12500 requests per second.
Your computer is a multicore 2-4GHz machine
Re:Siren Call of SQLite on the Server
by HumanOstrich on Tuesday February 18, 2025 @05:00PM
(#43095667)
"Just use Postgres" is as useless as any other "Just use X".
You're trying to compare using SQLite which is stored in a file on the system... with using Postgres in a container via kubernetes on the same VM? What happens when you need to move that Postgres container somewhere else? How do you scale it? If you don't, then you're just using a solution orders of magnitude more complicated than SQLite to get the same functionality and locality as SQLite.
People are comparing sqlite to RDS or whatever which completely biases the comparison. We have small apps running in containers talking to Postgres in a container via kubernetes networking on the same VM.
Benchmark.bm{ |x| x.report{ 1000.times{ ActiveRecord::Base.connection.execute("select 1") }}}
0.08 seconds for 1000 DB queries is not causing network latency problems for any real world app. Just use Postgres unless you really have good reasons not to.