Postgres LISTEN/NOTIFY does not scale

Post by Lio » Fri, Jul 11, 2025, 7:20 AM UTC

panzi wrote: post #129

fathomdeez wrote: post #125

Earlier quoted context omitted.

This kind of issue always comes up when people put business logic inside the database. Databases are for data. The data goes in and the data goes out, but the data does not get to decide what happens next based on itself. That's what application code is for.

So what are your thoughts on constraints then? Foreign keys? Should that only be handled by the application, like Rails does (or did, haven't used in a long time).

Post by 1a527dd5 » Fri, Jul 11, 2025, 7:29 AM UTC

shivasaxena wrote: post #22

Out of curiosity: Would appreciate if others can share what other things like AccessExclusiveLock should postgres users beware of? What I already know - Unique indexes slow inserts since db has to acquire a full table lock - Case statements in Where break query planner/optimizer and require full table scans - Read only postgres functions should be marked as `STABLE PARALLEL SAFE`

Post by oulipo » Fri, Jul 11, 2025, 7:53 AM UTC

kristianc wrote: post #84

callamdelaney wrote: post #69

My kneejerk reaction to the headline is ‘why would it?’. It’s unsurprising to me that an AI company appears to have chosen exactly the wrong tool for the job.

Sounds like a deliberate attempt to avoid spinning up Redis, Kafka, or an outbox system early on.. and then underestimated how quickly their scale would make it blow up. Story as old as time.

Post by ehansdais » Fri, Jul 11, 2025, 8:06 AM UTC

tsimionescu wrote: post #155

fathomdeez wrote: post #125

Earlier quoted context omitted.

This kind of issue always comes up when people put business logic inside the database. Databases are for data. The data goes in and the data goes out, but the data does not get to decide what happens next based on itself. That's what application code is for.

The way you model data and store it in your database is fundamentally a part of your business logic. The same data can be modeled in many different ways, with different trade-offs for different use cases. Especially if you have a large amount of data, you can't just work with it as is, you need to know how you will use it and model it in a way that makes the common operations fast enough. As your application evolves,…

Post by Cthulhu_ » Fri, Jul 11, 2025, 8:19 AM UTC

fathomdeez wrote: post #125

osigurdson wrote: post #110

I like this article. Lots of comments are stating that they are "using it wrong" and I'm sure they are. However, it does help to contrast the much more common, "use Postgres for everything" type sentiment. It is pretty hard to use Postgres wrong for relational things in the sense that everyone knows about indexes and so on. But using something like L/N comes with a separate learning curve anyway - evidenced in this c…

This kind of issue always comes up when people put business logic inside the database. Databases are for data. The data goes in and the data goes out, but the data does not get to decide what happens next based on itself. That's what application code is for.