From 87a7dba6ba353dbf7fd24a5f005c2d2cd6d36b82 Mon Sep 17 00:00:00 2001 From: counterweight Date: Sat, 25 Jul 2026 11:11:07 +0200 Subject: [PATCH] intersting stuff --- interesting/making-postgres-listen-notify-scale.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 interesting/making-postgres-listen-notify-scale.md diff --git a/interesting/making-postgres-listen-notify-scale.md b/interesting/making-postgres-listen-notify-scale.md new file mode 100644 index 0000000..705f043 --- /dev/null +++ b/interesting/making-postgres-listen-notify-scale.md @@ -0,0 +1,14 @@ +# Making Postgres LISTEN/NOTIFY scale + +https://www.dbos.dev/blog/postgres-listen-notify-scalability + +This blogpost by dbos dunks on this other one (https://www.recall.ai/blog/postgres-listen-notify-does-not-scale) by recall.ai where they state that Postgres' LISTEN/NOTIFY does not scale. + +The original thesis is that using LISTEN/NOTIFY kills the write throughput of the database it is working on. This is because it holds a LOCK on the entire database. They spotted the peculiarity because, even though their instance queries were all blowing up, resource usages on the metal was going down. Locks explain that. + +Then the guys at dbos came in and said: well, that's true, but you can work around that easy peasy. They gave an example from their own systems. The approach is: +- Make the NOTIFY a simple pinger, not a data sender. +- Buffer notifications +- To cover for the case where there is a crash, buffer is lost and there is no NOTIFY, make the consumers also poll here in there. + +To be honest, dbos points are not bad, but fucking hell aren't they way more complicated.