Hi everyone, We're evaluating strategies for handling schema evolution in Flink SQL jobs. We tested both: • Running the old and new jobs in parallel, and • A savepoint-based approach using versioned tables/views. Both approaches worked but introduced challenges such as operator state mapping, handling state for newly added operators, multiple sink tables, Kafka retention limitations, deployment complexity, and deadlocks during migration. I'm interested in knowing how others handle schema evolution in production. What approach or tooling do you use to evolve Flink SQL jobs with minimal downtime while preserving state and ensuring data consistency? Any help would be highly appreciated😀

I don't know how many people use it, but I highly love protobuf messages! Use it heavily with GRPC and it works GREAT in Flink too! Proto by-design allows for schema changes overtime with built-in backwards compatibility; as long as you follow correct change patterns. As it was built for data serialization over the network, it's perfect for Flink which is a serde framework. For what it's worth, attached our Kryo Serializer, and registered as

Configuration config = GlobalConfiguration.loadConfiguration();

// Protobuf records serialize via the Kryo ProtobufSerializer
config.set(PipelineOptions.SERIALIZATION_CONFIG, List.of(
        String.format(KRYO_DEFAULT, Message.class.getName(), ProtobufSerializer.class.getName())));

P.S. would love if Flink supports proto built-in

I am using Flink Iceberg and it supports schema evolution. I am using schema registry to keep the versions of the schema

@Siddhesh Kalgaonkar is your source kafka with avro messages ?