Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 95 posts

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

#21

Post by ncruces »

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…

Probably missing something, why is `stat(2)` better than: `PRAGMA data_version`?

https://sqlite.org/pragma.html#pragma_data_version

Or for a C API that's even better, `SQLITE_FCNTL_DATA_VERSION`:

https://sqlite.org/c3ref/c_fcntl_begin_atomic_write.html#sql...

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

#22

Post by psadri »

ncruces wrote: post #21
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…

Probably missing something, why is `stat(2)` better than: `PRAGMA data_version`? https://sqlite.org/pragma.html#pragma_data_version Or for a C API that's even better, `SQLITE_FCNTL_DATA_VERSION`: https://sqlite.org/c3ref/c_fcntl_begin_atomic_write.html#sql...

For one it seems to be deprecated.

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

#23

Post by ncruces »

psadri wrote: post #22
ncruces wrote: post #21

Earlier quoted context omitted.

Probably missing something, why is `stat(2)` better than: `PRAGMA data_version`? https://sqlite.org/pragma.html#pragma_data_version Or for a C API that's even better, `SQLITE_FCNTL_DATA_VERSION`: https://sqlite.org/c3ref/c_fcntl_begin_atomic_write.html#sql...

For one it seems to be deprecated.

It's not.

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

#25

Post by rich_sasha »

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…

Pretty cool! I have a half baked version of something similar :)

Can you use it also as a lightweight Kafka - persistent message stream? With semantics like, replay all messages (historical+real time) from some timestamp for some topics?

As with pub/sub, you can reproduce this with some polling etc but as you say, that's not optimal.

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

#27

Post by JoelJacobson »

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...

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

#29

Post by infogulch »

ncruces wrote: post #21
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…

Probably missing something, why is `stat(2)` better than: `PRAGMA data_version`? https://sqlite.org/pragma.html#pragma_data_version Or for a C API that's even better, `SQLITE_FCNTL_DATA_VERSION`: https://sqlite.org/c3ref/c_fcntl_begin_atomic_write.html#sql...

Yeah the C API seems like a perfect fit for this use-case:

> [SQLITE_FCNTL_DATA_VERSION] is the only mechanism to detect changes that happen either internally or externally and that are associated with a particular attached database.

Another user itt says the stat(2) approach takes less than 1 μs per call on their hardware.

I wonder how these approaches compare across compatibility & performance metrics.

Post reply on HN