Seriously people just layer shit with NATS for pubsub after persist and make sure there's a proper way to place a 'on restart recoonect' thing.
Postgres LISTEN/NOTIFY does not scale
71–80 of 328 posts
Re: Postgres LISTEN/NOTIFY does not scale
#72Earlier quoted context omitted.
that, and keeping your business logic in the database makes everything more opaque!
> that, and keeping your business logic in the database makes everything more opaque! Opaque to who? If there's a piece of business logic that says "After this table's record is updated, you MUST update this other table", what advantages are there to putting that logic in the application? When (not if) some other application updates that record you are going to have a broken database. Some things are business constra…
I think the dream is that business requirements are contained to one artifact and everything else responds to that driver. In an ideal world, it would be great to have databases care only about persistence and be able to swap them out based on persistence needs only. But you're right, in the real world the database is much better at enforcing constraints than applications.
Re: Postgres LISTEN/NOTIFY does not scale
#73Rls and triggers dont scale either
Yeah, I'm going to remove triggers in next deploy of a POS system since they are adding 10-50ms to each insert. Becomes a problem if you are inserting 40 items to order_items table.
Hmm, imho, triggers do scale, they are just slow. But as you add more connections, partitionss, and CPUs, the slowness per operation remains constant.
Re: Postgres LISTEN/NOTIFY does not scale
#74Am I supposed to be able to tell from these graphs that one was faster than the other? Because I sure can't.
What were the TPS numbers? What was the workload like? How big is the difference in %?
Re: Postgres LISTEN/NOTIFY does not scale
#75Earlier quoted context omitted.
Yeah, I'm going to remove triggers in next deploy of a POS system since they are adding 10-50ms to each insert. Becomes a problem if you are inserting 40 items to order_items table.
How do you handle trigger logic that compares old/new without having a round trip back to the application?
Do it in a stored procedure not a trigger. Triggers have their place but a stored procedure is almost always better. Triggers can surprise you.
Re: Postgres LISTEN/NOTIFY does not scale
#76Honestly this article is ridiculous. Most people do not have tens of thousands of concurrent writers. And most applications out there are read heavy, not write. Which means you probably have read replicas distributing loads.
Use LISTEN/NOTIFY. You will get a lot of utility out of it before you’re anywhere close to these problems.
Re: Postgres LISTEN/NOTIFY does not scale
#77Earlier quoted context omitted.
Very very few applications use mnsesia. There’s absolutely no way I would recommend it over Postgres.
I have heard the mnesia is very unreliable, which is a damn shame. I wonder if that is fixable, or just inherent to its design.
My understanding is that mnesia is sort of a relic. Really hard to work with and lots of edge / failure cases.
I'm not sure if it should be salvaged?
Re: Postgres LISTEN/NOTIFY does not scale
#78LISTEN/NOTIFY isn’t just a lock-free trigger. It can jeopardize concurrency under load. Features that seem harmless at small scale can break everything at large scale.
It's true and folk should also choose the right tool at their scale and monitor it. There are plenty of cases where LISTEN/NOTIFY is the right choice.
However, in 2025 I'd pick Redis or MQTT for this kind of role. I'm typically in multi-lamg environments. Is there something better?
Re: Postgres LISTEN/NOTIFY does not scale
#79Earlier quoted context omitted.
How did you resolve this? Did you consider listening to the WAL?
We have Postgres based pubsub, but encourage people to use a distributed Erlang based notifier instead whenever possible. Another important change was removing insert triggers, partially for the exact reasons mentioned in this post.
> Another important change was removing insert triggers, partially for the exact reasons mentioned in this post.
What did you replace them with instead?
Re: Postgres LISTEN/NOTIFY does not scale
#80Earlier quoted context omitted.
How do you handle trigger logic that compares old/new without having a round trip back to the application?
Do it in a stored procedure not a trigger. Triggers have their place but a stored procedure is almost always better. Triggers can surprise you.
I don't follow how you would do that in a stored procedure outside of a trigger.