Compare Sequin

Sequin brings new capabilities to Postgres. You can use Sequin as a more advanced replacement for native Postgres tools like triggers or LISTEN/NOTIFY. And you can use Sequin to leverage your Postgres database in new ways, replacing other systems like Kafka.

​

Postgres triggers

Postgres triggers are database functions that execute in response to certain database events. Postgres triggers must be written in PL/pgSQL, a special procedural language for Postgres. And they are limited to simple operations like inserting, updating, and deleting rows.

Sequin sends changes over HTTP. Like Postgres triggers, Sequin guarantees exactly-once processing. But the HTTP interface means you can you can handle changes in your application code. Just like other advanced queuing systems, Sequin lets you fan out changes to multiple services or applications. And you can write business logic in the programming language of your choice (no PL/pgSQL!)

​

LISTEN/NOTIFY

Postgres’ LISTEN/NOTIFY is a pub/sub system. When changes happen in your database, you can send notifications to a channel in Postgres. Other processes can listen for notifications on that channel and react to changes.

LISTEN/NOTIFY offers at-most-once delivery. If a consumer is not subscribed when a notification is sent, or a consumer fails to process a notification, the notification is lost. So LISTEN/NOTIFY is limited to simple use cases.

Sequin sends changes over HTTP with exactly-once processing. This gives you a much more robust system to build on top of.

​

Kafka

Apache Kafka is a distributed event streaming platform. Kafka is designed for very high throughput and horizontal scalability.

You can use Sequin to turn a Postgres table into something that behaves like a Kafka topic. You can create new consumers that process messages in order, starting at any offset in the table you specify. Because all your data lives at rest in Postgres, the data model is easy to understand and work with.

Sequin’s consumer pattern is simpler than Kafka’s. Kafka uses partitions and offsets for concurrency, whereas Sequin uses a message queue pattern similar to SQS. This means concurrency is flexible and you can scale workers up and down without making any configuration changes.

While Kafka may be necessary for very high throughput use cases (logs or metrics, millions of messages per second), Postgres and Sequin are able to handle a lot of use cases with a lot less complexity (even modest Postgres instances can handle tens of thousands of messages per second).

​

Debezium

Debezium is an open-source platform for change data capture (CDC), often used with Apache Kafka, a distributed event streaming platform.

Sequin provides the CDC capabilities of Debezium with a durable message stream like Kafka, except with fewer moving parts and none of the operational overhead. You don’t need to be a Kafka expert, learn Zookeeper, endlessly configure Debezium, or figure out the Java runtime.

​

Amazon SQS

Amazon Simple Queue Service (SQS) is a message queuing service. It offers exactly-once processing over an HTTP interface.

Sequin’s HTTP pull interface is a lot like SQS’s HTTP pull interface. Except, Sequin isn’t really a queue; it’s better thought of as a stream. Because Sequin is streaming your Postgres tables, messages aren’t deleted after they’re processed. This means you get more advanced capability, like rewind and replay.

​

PGMQ

PGMQ is a Postgres extension that provides a durable message queue with a SQL interface that mimics SQS methods. It offers exactly-once processing like SQS, but runs entirely in Postgres.

Unlike PGMQ, Sequin is a stream not a queue. PGMQ owns a table you publish messages to, and when you process the messages they are deleted. By contrast, Sequin turns your existing tables into a stream. They’re useful for different use cases.