> ## Documentation Index
> Fetch the complete documentation index at: https://sequinstream.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance

> Explore how Sequin out‑performs every Debezium deployment mode by up to 6.8× in throughput and 4.7× in latency. See why Sequin is the fastest Postgres CDC tool available.

Sequin delivers **industry‑leading** change‑data‑capture (CDC) performance, sustaining **50k ops/s (or up to 40 MB/s)** at a **55 ms** average end‑to‑end latency. That makes Sequin the fastest Postgres CDC solution available today.

<Frame>
  <img src="https://mintcdn.com/sequinstream/drUA755uMUeIaCSH/images/performance/sequin-throughput-and-latency.png?fit=max&auto=format&n=drUA755uMUeIaCSH&q=85&s=a95709f15717cc2650e53d81a5e62ec2" alt="Sequin throughput and latency" width="600" height="371" data-path="images/performance/sequin-throughput-and-latency.png" />
</Frame>

This performance is achieved with Sequin streaming changes from a single Postgres replication slot to Kafka. If configured with multiple replication slots, Sequin can stream low latency change-data-capture from very high throughput Postgres databases without falling behind.

In the sections below, we document how Sequin performs on different instance sizes. We also compare Sequin to different Debezium runtimes (Debezium has [several runtimes](https://blog.sequinstream.com/the-debezium-trio-comparing-kafka-connect-server-and-engine-run-times/).)

# Sequin performance

## Single‑slot peak throughput & latency

Sequin streams from a single Postgres replication slot to Kafka at:

* **50k ops/s** or **40 MB/s** (whichever comes first), sustained
* **55ms** average latency
* **253ms** 99th‑percentile latency

If you need more headroom, you can enable additional slots; Sequin scales linearly without falling behind.

## Sequin on different instance sizes

Here's a sampling of throughput Sequin can handle on different instance types:

| AWS Graviton EC2  | vCPU / GiB | Avg row size | Sustained throughput | Bandwidth      |
| ----------------- | ---------- | ------------ | -------------------- | -------------- |
| c8g.4xlarge       | 16 / 32    | 100B         | **60k ops/s**        | **5.53 MB/s**  |
| c8g.4xlarge       | 16 / 32    | 200B         | **58k ops/s**        | **10.64 MB/s** |
| c8g.4xlarge       | 16 / 32    | 400B         | **52k ops/s**        | **19.92 MB/s** |
| c8g.4xlarge       | 16 / 32    | 1.6kb        | **23k ops/s**        | **36.06 MB/s** |
| c8g.2xlarge       | 8 / 16     | 200B         | **34k ops/s**        | **6.32 MB/s**  |
| c8g.xlarge        | 4 / 8      | 200B         | **20k ops/s**        | **3.81 MB/s**  |

# Debezium on MSK Connect (AWS)

**Best if:** you already run Amazon MSK and want a managed Kafka Connect runtime.

The highest throughput we were able to consistently achieve with Debezium deployed on AWS MSK Connect was 6k ops/sec.

| Metric                    | 8 MCUs (max available on AWS MSK Connect) |
| ------------------------- | ----------------------------------------- |
| *Sustained throughput*    | **6k ops/s**                              |
| *Average latency*         | **≈ 258ms**                               |
| *99th‑percentile latency* | **≈ 499ms**                               |

At this throughput, Sequin in a comparable setup has a latency that is significantly lower:

<Frame>
  <img src="https://mintcdn.com/sequinstream/drUA755uMUeIaCSH/images/performance/sequin-vs-debezium-latency.png?fit=max&auto=format&n=drUA755uMUeIaCSH&q=85&s=b0af3c51211b06ef7990ea8c83d0b63f" alt="Sequin vs Debezium latency" width="1490" height="918" data-path="images/performance/sequin-vs-debezium-latency.png" />
</Frame>

### Scaling limits

* **8 MCUs** (8 vCPU / 32 GiB RAM) is the *hard* ceiling MSK Connect exposes for a single connector.
* The connector is single‑threaded for snapshotting and heavily synchronized during streaming, so adding more MCUs has diminishing returns past \~4 MCUs.

# Debezium Server (stand‑alone)

**Best if:** you need a minimal footprint and do **not** want to run full Kafka Connect.

| Hardware             | Row size | Debezium Server             | Sequin                     |
| -------------------- | -------- | --------------------------- | -------------------------- |
| **16 vCPU / 32 GiB** | 200 B    | **20k ops/s** (4 MB/s)      | **58k ops/s** (10.64 MB/s) |
| **16 vCPU / 32 GiB** | 400 B    | **20.3k ops/s** (7.73 MB/s) | **52k ops/s** (19.92 MB/s) |
| **8 vCPU / 16 GiB**  | 100 B    | **20k ops/s** (2 MB/s)      | **30k ops/s** (3 MB/s)     |
| **4 vCPU / 8 GiB**   | 100 B    | **20k ops/s** (2 MB/s)      | **29k ops/s** (2.9 MB/s)   |

# Debezium on Confluent Cloud

*(Coming soon)*

<Note>
  Comparative benchmarks coming soon. [Upvote the issue](https://github.com/sequinstream/sequin/issues/1857) if you want to see them.
</Note>

# Debezium on self‑hosted Kafka Connect

*(Coming soon)*

<Note>
  Comparative benchmarks coming soon. [Upvote the issue](https://github.com/sequinstream/sequin/issues/1857) if you want to see them.
</Note>

## Benchmark methodology

<Info>
  All of our benchmarks are open source and available on [GitHub](https://github.com/sequinstream/sequin-vs-debezium-benchmark).
</Info>

Our benchmarks are conducted in a production-like environment. Sequin and Debezium are compared head-to-head capturing changes from [AWS RDS](https://aws.amazon.com/rds/) and delivering to [AWS MSK Kafka](https://aws.amazon.com/msk/).

Load is applied to a single Postgres table using [`workload_generator.py`](https://github.com/sequinstream/sequin-vs-debezium-benchmark/blob/main/workload_generator.py) deployed to a dedicated EC2 instance.

Throughput and end-to-end latency are measured with a [Kafka consumer](https://github.com/sequinstream/sequin-vs-debezium-benchmark/blob/main/cdc_stats.py) deployed to a separate EC2 instance. The stats are calculated as:

* **Throughput**: the number of records delivered to Kafka per second.
* **Latency**: the time between a change occuring in Postgres (`updated_at` timestamp) and it's delivery to AWS MSK Kafka (Kafka `creation` timestamp).

### Workload

`workload_generator.py` applies a mixed workload of `INSERT`, `UPDATE`, and `DELETE` operations to the `benchmark_records` table.

<Frame>
  <img src="https://mintcdn.com/sequinstream/drUA755uMUeIaCSH/images/performance/workload-generation.png?fit=max&auto=format&n=drUA755uMUeIaCSH&q=85&s=3bafd568574f1eca00e48231748f702c" alt="Workload generation" width="1842" height="744" data-path="images/performance/workload-generation.png" />
</Frame>

The `benchmark_records` Postgres table has the following schema:

```
                                           Table "public.benchmark_records"
     Column      |            Type             | Collation | Nullable |                    Default
-----------------+-----------------------------+-----------+----------+-----------------------------------------------
 id              | integer                     |           | not null | nextval('benchmark_records_id_seq'::regclass)
 string_field    | text                        |           |          |
 numeric_field   | numeric                     |           |          |
 timestamp_field | timestamp with time zone    |           |          |
 json_field      | jsonb                       |           |          |
 inserted_at     | timestamp without time zone |           |          | now()
 updated_at      | timestamp without time zone |           |          | now()
```

### Stats collection

Similarly, the `cdc_stats.py` script is deployed to a separate EC2 instance and reads from AWS MSK Kafka. Stats are bucketed and saved to a CSV file for analysis.

<Frame>
  <img src="https://mintcdn.com/sequinstream/BsnEA8B24cYdMBsV/images/performance/cdc-stats.png?fit=max&auto=format&n=BsnEA8B24cYdMBsV&q=85&s=81649141578f1057257acc4ce4b3aad6" alt="Stats collection" width="1996" height="940" data-path="images/performance/cdc-stats.png" />
</Frame>

### Infrastructure

Sequin, Debezium, and the rest of the infrastructure are deployed to AWS in the following configuration:

* AWS RDS Postgres `db.m5.8xlarge` instance (32 vCPUs, 128GB RAM)
* AWS MSK Kafka provisioned with 4 brokers
* AWS EC2 instances with Sequin running in Docker.

***

## Summary

| Tool / Deployment | Sustained throughput | Avg latency | 99p latency |   |
| ----------------- | -------------------- | ----------- | ----------- | - |
| **Sequin**        | **>50 k ops / s**    | **55 ms**   | **253 ms**  |   |
| Debezium · MSK    | 6 k ops / s          | 258 ms      | 499 ms      |   |
| Debezium · Server | 23 k ops / s         | 210 ms      | 440 ms      |   |
| Fivetran          | 5+ minutes           | -           | -           | - |
| Airbyte           | 1+ hours             | -           | -           | - |

<small>† Numbers vary by row size; see Section 2 for details.</small>

Sequin sustains **6 × – 8 ×** more throughput than Debezium’s on MSK, and over **2x** the throughput of Debezium Server.

***

## Next steps

Ready to see Sequin's performance for yourself?

<CardGroup cols={2}>
  <Card title="What is Sequin?" icon="elephant" href="/introduction">
    Learn about Sequin's architecture and how it works.
  </Card>

  <Card title="Quickstart with Kafka" icon="bolt" href="/quickstart/kafka">
    Get started with Sequin CDC and Kafka in minutes.
  </Card>

  <Card title="Compare CDC Tools" icon="scale-balanced" href="/compare">
    See how Sequin stacks up against other CDC solutions.
  </Card>

  <Card title="Deploy to Production" icon="rocket" href="/how-to/deploy-to-production">
    Learn how to deploy Sequin in your production environment.
  </Card>
</CardGroup>