Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

Post by Polizeiposaune » Thu, Apr 23, 2026, 6:25 PM UTC

vlovich123 wrote: post #20

slashdev wrote: post #16

Earlier quoted context omitted.

That’s ignoring the other costs of syscalls like evicting your stuff from the CPU caches. But I agree with the conclusion, system calls are still pretty fast compared to a lot of other things.

Small correction on ambiguous wording - syscalls do not evict all your stuff from CPU caches. It just has to page in whatever is needed for kernel code/data accessed by the call, but that’s no different from if it was done in process as a normal function call.

Post by russellthehippo » Thu, Apr 23, 2026, 8:03 PM UTC

JoelJacobson wrote: post #27

Shameless plug: In the upcoming release of PostgreSQL 19, LISTEN/NOTIFY has been optimized to scale much better with selective signaling, i.e. when lots of backends are listening on different channels, patch: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

Post by russellthehippo » Thu, Apr 23, 2026, 8:05 PM UTC

tuo-lei wrote: post #17

atomic commit with the business data is the selling point over separate IPC. external message passing always has the 'notification sent but transaction rolled back' problem and that gets messy. one thing i'm curious about: WAL checkpoint. when SQLite truncates WAL back to zero, does the stat() polling handle that correctly? feels like there's a window where events could get lost.

Post by russellthehippo » Thu, Apr 23, 2026, 8:13 PM UTC

andersmurphy wrote: post #8

russellthehippo wrote: post #2

Hey HN, I built this. Honker adds cross-process NOTIFY/LISTEN to SQLite. You get push-style event delivery with single-digit millisecond latency without a damon/broker, using your existing SQLite file. A lot of pretty high-traffic applications are just Framework+SQLite+Litestream on a VPS now, so I wanted to bring a sixer to the "just use SQLite" party. SQLite doesn't run a server like Postgres, so the trick is movin…

Is the main use case for this for languages that only have access to process based concurrency? Struggling to see why you would otherwise need this in java/go/clojure/C# your sqlite has a single writer, so you can notify all threads that care about inserts/updates/changes as your application manages the single writer (with a language level concurrent queue) so you know when it's writing and what it has just written.…

Post by russellthehippo » Thu, Apr 23, 2026, 8:16 PM UTC

vlovich123 wrote: post #19

WJW wrote: post #14

Earlier quoted context omitted.

"Syscalls are slow" is only mostly true. They are slower than not having to cross the userspace OS barrier at all, but they're not "slow" like cross-ocean network calls can be. For example, non-VDSO syscalls in linux are about 250 nanoseconds (see for example https://arkanis.de/weblog/2017-01-05-measurements-of-system-... ), VDSO syscalls are roughly 10x faster. Slower than userspace function calls for sure, but more…

Filesystem stuff tends to be slower than average syscalls because of all the locks and complicated traversals needed. If this is using stat instead of fstat then it’s also going through the VFS layer - repeated calls likely go through the cache fast path for path resolution but accessing the stat structure. There’s also hidden costs in that number like atomic accesses that need to acquire cache line locks that are go…