Write throughput handling

[Rohit Panwar]

Hi community,

Lets say i deploy a debezium connector for a tenant which has very high write throughput. Is it recommended to have multiple connectors for different tables of the tenant? Could there be a scenario in case of say an extreme spike in writes that my single connector starts falling behind?

[Chris Cranford]

Hi -

For MySQL and MariaDB, you'd likely see very negligible gains, if any. This is due to how the binlog client works by reading every binlog event regardless of whether its for a table that is or isn't in its include list. So adding multiple connectors for this type of database source won't add value, just overhead and extra management complexity of multiple connectors.

However, other connectors that push filter configurations to the database level (PG/Oracle/MongoDB) or that have ways to exclude and only read changes on a per-table basis (SQL Server/Db2), those connectors would most definitely see more benefit from such a model, but it's something we usually ask that you try and single connector first, measure it, and see what the gain ultimately is. You may find the gain remains negligible and doesn't justify the complexity or the overhead it may put on your database with multiple connectors.

-cc

On 9/4/25 6:30 AM, Rohit Panwar wrote:

Hi community,

Lets say i deploy a debezium connector for a tenant which has very high write throughput. Is it recommended to have multiple connectors for different tables of the tenant? Could there be a scenario in case of say an extreme spike in writes that my single connector starts falling behind? --
You received this message because you are subscribed to the Google Groups "debezium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debezium+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/debezium/34de9c6d-60ab-4d7d-9e9a-011b7b40432bn%40googlegroups.com.