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.