# How INTEGER and INT Produced Different Schemas in Debezium

DevFeed: [How INTEGER and INT Produced Different Schemas in Debezium](<https://devfeed.tech/articles/how-integer-and-int-produced-different-schemas-in-debezium-20086.md>)

Original publisher: [Read original article](<https://lambda.blinkit.com/how-integer-and-int-produced-different-schemas-in-debezium-9c98e8a80aa2?source=rss----42df4a1e8725---4>)

Author: Prathit Malik

Published: 2026-09-02T07:02:02Z

Content type: article

Language: en

Sources: [Grofers](<https://devfeed.tech/sources/grofers.md>)

Topics: [MySQL](<https://devfeed.tech/topics/mysql.md>), [migration](<https://devfeed.tech/topics/migration.md>), [Streaming](<https://devfeed.tech/topics/streaming.md>), [Kafka](<https://devfeed.tech/topics/kafka.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [big-data](<https://devfeed.tech/tags/big-data.md>), [blinkit](<https://devfeed.tech/tags/blinkit.md>), [change](<https://devfeed.tech/tags/change.md>), [database](<https://devfeed.tech/tags/database.md>), [debezium](<https://devfeed.tech/tags/debezium.md>), [jdbc](<https://devfeed.tech/tags/jdbc.md>), [kafka](<https://devfeed.tech/tags/kafka.md>), [migration](<https://devfeed.tech/tags/migration.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [schema](<https://devfeed.tech/tags/schema.md>), [sql](<https://devfeed.tech/tags/sql.md>), [streaming](<https://devfeed.tech/tags/streaming.md>)

## AI overview

This article investigates a Debezium CDC pipeline failure caused by MySQL INT and INTEGER synonyms being treated as different types. The resulting schema mismatch produced an Integer where a downstream consumer expected a Long, causing a ClassCastException on every batch. It explains how streaming and snapshot schema handling differ and how routine migrations exposed the problem.

## Source excerpt

A Debezium investigation: how MySQL synonyms INT and INTEGER were treated as different types. One of our CDC pipelines started failing with a ClassCastException on every batch. java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.Long The pipeline was producing an Integer, but the downstream consumer expected a Long. Every run failed in the same way, which pointed us toward a schema mismatch rather than an issue with individual records. Background: how CDC works To see why a mismatch like that can hide for years, it helps to know how CDC actually works. Most companies replicate their transactional database (MySQL, Postgres, something similar) into a separate data lake for analytics, rather than querying the source directly, and Change Data Capture (CDC) is what keeps that copy in sync: it tails the database's transaction log and replays every insert, update, and delete downstream. Debezium is the most widely used open-source CDC tool for MySQL, and it builds a table's schema in one of two ways that are supposed to agree but do not always. Streaming mode: the first time it sees a CREATE TABLE or ALTER TABLE in the binlog, it parses the raw SQL text and writes the result to its own internal Kafka topic, database.history.kafka.topic. Every restart after that rebuilds the in-memory schema by replaying that topic, not by re-reading the binlog. Snapshot mode: reads the table definition fresh through MySQL's JDBC metadata interface, which normalizes types, every time it runs. Schema Registry sits downstream of both: each connector writes whatever schema it built into the registry, but neither connector reads its own schema back from it. Keep that in mind; it matters later. The trigger: a routine migration With that in mind, here's what actually happened to us. Rewind two years: one of our upstream service teams added a few columns to a source table as part of a standard schema change. ALTER TABLE <source_table> ADD COLUMN length double NU