4/12/2026 at 8:06:31 AM
> The enterprise mindset dictates that you need an out-of-process database server. But the truth is, a local SQLite file communicating over the C-interface or memory is orders of magnitude faster than making a TCP network hop to a remote Postgres server.I don't want to diss SQLite because it is awesome and more than adequate for many/most web apps but you can connect to Postgres (or any DB really) on localhost over a Unix domain socket and avoid nearly all of the overhead.
It's not much harder to use than SQLite, you get all of the Postgres features, it's easier to run reports or whatever on the live db from a different box, and much easier if it comes time to setup a read replica, HA, or run the DB on a different box from the app.
I don't think running Postgres on the same box as your app is the same class of optimistic over provisioning as setting up a kubernetes cluster.
by hackingonempty
4/12/2026 at 10:02:41 AM
Sqlite smokes postgres on the same machine even with domain sockets [1]. This is before you get into using multiple sqlite database.What features postgres offers over sqlite in the context of running on a single machine with a monolithic app? Application functions [2] means you can extend it however you need with the same language you use to build your application. It also has a much better backup and replication story thanks to litestream [3].
- [1] https://andersmurphy.com/2025/12/02/100000-tps-over-a-billio...
- [2] https://sqlite.org/appfunc.html
- [3] https://litestream.io/
The main problem with sqlite is the defaults are not great and you should really use it with separate read and write connections where the application manages the write queue rather than letting sqlite handle it.
by andersmurphy
4/12/2026 at 10:18:42 AM
> Sqlite smokes postgres on the same machine even with domain sockets [1].SQLite on the same machine is akin to calling fwrite. That's fine. This is also a system constraint as it forces a one-database-per-instance design, with no data shared across nodes. This is fine if you're putting together a site for your neighborhood's mom and pop shop, but once you need to handle a request baseline beyond a few hundreds TPS and you need to serve traffic beyond your local region then you have no alternative other than to have more than one instance of your service running in parallel. You can continue to shoehorn your one-database-per-service pattern onto the design, but you're now compelled to find "clever" strategies to sync state across nodes.
Those who know better to not do "clever" simply slap a Postgres node and call it a day.
by locknitpicker
4/12/2026 at 10:38:45 AM
I wonder what percentage of services run on the Internet exceed a few hundred transactions per second.by rpdillon
4/12/2026 at 8:41:34 AM
Looks like the overhead is not insignificant: Running 100,000 `SELECT 1` queries:
PostgreSQL (localhost): 2.77 seconds
SQLite (in-memory): 0.07 seconds
by eurleif
4/12/2026 at 8:57:29 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.by piker
4/12/2026 at 10:23:11 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.Exactly. Back in the real world,anyone who is faced with that sort of usecase will simply add memory cache and not bother with the persistence layer.
by locknitpicker
4/12/2026 at 8:53:21 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.by bob1029
4/12/2026 at 9:50:44 AM
Most important is that that local SQLite gets proper backups, so a restore goes without issuesby madduci
4/12/2026 at 9:42:47 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?by iLoveOncall
4/12/2026 at 9:46:17 AM
Because it doesn't make a difference, because `SELECT 1` doesn't need to touch the database: Running 100,000 `SELECT 1` queries:
PostgreSQL (localhost): 2.71 seconds
SQLite (in-memory): 0.07 seconds
SQLite (tempfile): 0.07 seconds
by eurleif
4/12/2026 at 10:04:32 AM
Why are you doing meaningless microbenchmarks?by oldsecondhand
4/12/2026 at 10:24:43 AM
> Because it doesn't make a difference, because `SELECT 1` doesn't need to touch the database:I hope you understand that your claim boils down to stating that SQLite is faster at doing nothing at all, which is a silly case to make.
by locknitpicker
4/12/2026 at 10:28:34 AM
The original claim being discussed is about the overhead of an in-process database vs. a database server in a separate process, not about whether SQLite or PostgreSQL have a faster database engine.by eurleif
4/12/2026 at 10:10:06 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.
by locknitpicker
4/12/2026 at 9:54:16 AM
Would be nice to see PGLite[1] compared tooby vixalien
4/12/2026 at 10:02:26 AM
What a useful "my hello-world script is faster than your hello-world script" example.by Izmaki
4/12/2026 at 10:28:16 AM
Thats just swapping another enterprise focused concern into the mix. Your database connection latency is absolutely not a concerning part of your system.by weego
4/12/2026 at 8:27:00 AM
> It's not much harder to use than SQLite, you get all of the Postgres features, it's easier to run reports or whatever on the live db from a different box, and much easier if it comes time to setup a read replica, HA, or run the DB on a different box from the app.Isn't this idea to spend a bit more effort and overhead to get YAGNI features exactly what TFA argues against?
by jampekka
4/12/2026 at 9:21:58 AM
I have used SQLite with extensions in extreme throughput scenarios. We’re talking running through it millions of documents per second in order to do disambiguation. I won’t say this wouldn’t have been possible with a remote server, but it would have been a significant technical challenge. Instead we packed up the database on S3, and each instance got a fresh copy and hammered away at the task. SQLite is the time tested alternative for when you need performance, not featuresby usernametaken29
4/12/2026 at 9:28:19 AM
I've been doing that for decades.. People seem to simply not know about unix architecture.What I like about sqlite is that it's simply one file
by jbverschoor
4/12/2026 at 9:04:42 AM
Author's own 'auth' project works with sqlite and postgres.by dizhn
4/12/2026 at 10:15:57 AM
IIRC TCP/IP through localhost actually benchmarked faster than Unix sockets because it was optimized harder. Might've been fixed now. Unix sockets gives you the advantage of authentication based on the user ID of who's connecting.My experience with sqlite for server-based apps has been that as your app grows, you almost always eventually need something bigger than sqlite and need to migrate anyway. For a server-based app, where minimizing deployment complexity isn't an extremely important concern, and with mixed reads and writes, you might as well use Postgres or MariaDB from the start.
by direwolf20
4/12/2026 at 8:32:59 AM
I mean, you’re not wrong about the facts, but it’s also pretty trivial to migrate the data from SQLite into a separate Postgres server later, if it turns out you do need those features after all. But most of the time, you don’t.by Jolter
4/12/2026 at 9:01:22 AM
I bet that takes more time than the 5 extra minutes you take to setup Postgres in the same box upfront.by pdhborges