Комментарии 10
Пардон, но все это же было в MS SQL 2008 как минимум. То есть 14 лет назад. Я не к тому, что тема прям избитая, скорее нет, а просто все это уже давно было. И в оракле кстати тоже — в другом виде.
И емайл можно использовать, как очередь сообщений, и чат. Вопрос в производительности. Кто-то пробовал сравнивать производительность PostgreSQL c ActiveMQ, Kafka и пр? Мне реально интересно.
из того что видел по производительности, Postgres это ~ 1000rps, ActiveMQ/RabbitMQ ~20000rps, Kafka уже миллионы. Но это всё разные решения с разными подходами, плюсами и минусами. Postgres/другая_SQL_DB могут быть полезны в плане работы в одной транзакции: изменение применяется и создаётся событие, либо всё откатывается - это сильно проще в реализации для каких то кейсов, но нужно понимать, достаточен ли rps
Postgres не подходит для очередей, но как message broker - можно.
Только не знаю зачем, когда есть Nats и Jetstream.
Перед использованием listen/notify внимательно прочитать что про этот механизм обещает сама база: https://github.com/postgres/postgres/blob/REL_15_STABLE/src/backend/commands/async.c#L16
Чтобы потом не было неожиданностью, что все нотификации, к примеру, принципиально не crash-safe.
При реализации очередей на реляционной БД можно упереться в особенности реализации хранения данных на диске. В PostgreSQL начнутся пляски вокруг MVCC, table bloat, autovacuum. В Facebook Ordered Queueing Service построили на MySQL.
Ещё можно было бы упомянуть вариант реализации очереди через SELECT ... FOR UPDATE ... SKIP LOCKED.
Использование Postgres в качестве очереди сообщений