logoalt Hacker News

eurleiftoday at 8:41 AM8 repliesview on HN

Looks like the overhead is not insignificant:

    Running 100,000 `SELECT 1` queries:
    PostgreSQL (localhost): 2.77 seconds
    SQLite (in-memory): 0.07 seconds
(https://gist.github.com/leifkb/1ad16a741fd061216f074aedf1eca...)

Replies

pikertoday at 8:57 AM

I love them both too but that might not be the best metric unless you’re planning to run lots of little read queries. If you’re doing CRUD, simulating that workflow may favor Postgres given the transactional read/write work that needs to take place across multiple concurrent connections.

show 1 reply
bob1029today at 8:53 AM

This is mostly about thread communication. With SQLite you can guarantee no context switching. Postgres running on the same box gets you close but not all the way. It's still in a different process.

show 1 reply
madducitoday at 9:50 AM

Most important is that that local SQLite gets proper backups, so a restore goes without issues

show 1 reply
locknitpickertoday at 10:10 AM

A total performance delta of <3s on ~300k transactions is indeed the definition of irrelevant.

Also:

> PostgreSQL (localhost): (. .) SQLite (in-memory):

This is a rather silly example. What do you expect to happen to your data when your node restarts?

Your example makes as much sense as comparing Valkey with Postgres and proceed to proclaim that the performance difference is not insignificant.

vixalientoday at 9:54 AM

Would be nice to see PGLite[1] compared too

1: https://pglite.dev/

iLoveOncalltoday at 9:42 AM

Why are you comparing PostgreSQL to an in-memory SQLite instead of a file-based one? Wow, memory is faster than disk, who would have thought?

show 1 reply
stavrostoday at 10:45 AM

It is insignificant if you're doing 100k queries per day, and you gain a lot for your 3 extra seconds a day.

Izmakitoday at 10:02 AM

What a useful "my hello-world script is faster than your hello-world script" example.