# Yb voyager issues **URL:** \ **Category:** General\ **Created:** [July 23, 2026, 10:23am UTC](https://forum.yugabyte.com/t/yb-voyager-issues/5074 "2026-07-23T10:23:30Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![bunty.b](https://avatars.discourse-cdn.com/v4/letter/b/4af34b/32.png) [@bunty.b](https://forum.yugabyte.com/u/bunty.b)\ **Post date:** [July 23, 2026, 10:23am UTC](https://forum.yugabyte.com/t/yb-voyager-issues/5074/1 "2026-07-23T10:23:30Z")
Hi All, We are in the process of migrating mysql to Yugabyte but we have come up with below 3 limitations: - Voyager does not natively support automated migration of MySQL binary data types such as **BLOB, TINYBLOB, MEDIUMBLOB, and LONGBLOB**. - Data type mismatches were observed in **UNION** queries. - **AUTO\_INCREMENT** sequence migration for primary keys is not currently supported Is there is any workaround as it is blocking our migration. Thanks ---
**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\ **Post date:** [July 23, 2026, 11:21am UTC](https://forum.yugabyte.com/t/yb-voyager-issues/5074/2 "2026-07-23T11:21:30Z")
Hello @bunty.b Can you tell me your workflow please? > [@bunty.b](#): > > - Voyager does not natively support automated migration of MySQL binary data types such as **BLOB, TINYBLOB, MEDIUMBLOB, and LONGBLOB**. See [Data type mapping from MySQL to YugabyteDB | YugabyteDB Docs](https://docs.yugabyte.com/stable/yugabyte-voyager/reference/datatype-mapping-mysql/) (data is ignored) Question: what is the maximum column value for these across all rows? > [@bunty.b](#): > > - Data type mismatches were observed in **UNION** queries. I think you’re hitting this: [MySQL source database | YugabyteDB Docs](https://docs.yugabyte.com/stable/yugabyte-voyager/known-issues/mysql/#datatype-mismatch-in-objects-causing-issues) ? Can you add more details? > [@bunty.b](#): > > - **AUTO\_INCREMENT** sequence migration for primary keys is not currently supported This should be supported I believe? Can you add more details? See [Steps to perform offline migration of your database using YugabyteDB Voyager | YugabyteDB Docs](https://docs.yugabyte.com/stable/yugabyte-voyager/migrate/migrate-steps/#export-data) > In MySQL, auto-increment column is migrated to YugabyteDB as a normal column with a sequence attached to it. ---
**Author:** ![Jim\_Knicely](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/jim_knicely/32/668_2.png) [@Jim\_Knicely](https://forum.yugabyte.com/u/Jim_Knicely)\ **Post date:** [July 23, 2026, 12:21pm UTC](https://forum.yugabyte.com/t/yb-voyager-issues/5074/3 "2026-07-23T12:21:24Z")
For the UNION ALL issues… This will fail in Postgres and YugabyteDB: ```auto yugabyte=# **SELECT 1 UNION SELECT 'A';** ERROR: invalid input syntax for integer: "A" LINE 1: SELECT 1 UNION SELECT 'A'; ^ ``` But unlike YugabyteDB (which inherits PostgreSQL’s strict type system), MySQL is much more permissive with implicit type conversion (type coercion). When you combine an integer and a string using `UNION` in MySQL, it automatically resolves the conflict by converting the integer `1` into a string so both values can live happily in the same result column. If you run that exact query in MySQL, here is what happens: ```auto mysql> SELECT 1 UNION SELECT 'A'; +---+ | 1 | +---+ | 1 | | A | +---+ 2 rows in set (0.00 sec) ``` ### The Difference in a Nutshell - **MySQL:** Prioritizes flexibility. It looks at `1` and `'A'`, decides that a string data type (like `VARCHAR`) can hold both, converts the `1` to `'1'`, and returns the result. - **YugabyteDB / PostgreSQL:** Prioritizes type safety. It uses the data type of the first `SELECT` statement (`integer`) to determine the column type. When it hits `'A'` in the second statement, it tries to cast `'A'` to an integer, fails, and throws the error you saw. If you want to make this query work in YugabyteDB, you just have to be explicit about the type conversion: ```auto SELECT CAST(1 AS TEXT) UNION SELECT 'A'; -- Or using the PostgreSQL shorthand: SELECT 1::text UNION SELECT 'A'; ``` ---
**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\ **Post date:** [July 24, 2026, 8:15am UTC](https://forum.yugabyte.com/t/yb-voyager-issues/5074/4 "2026-07-24T08:15:35Z")
> [@dorian\_yugabyte](#): > > Question: what is the maximum column value for these across all rows? The `ENABLE_BLOB_EXPORT` directive in the ora2pg conf file can be enabled (i.e., set to 1) to have Voyager export BLOB data from MySQL. The ora2pg conf file should be located here: /etc/yb-voyager/base-ora2pg.conf However, note that there is a there is an RPC message size restriction in YugabyteDB of about ~200 MB. If a row size (including the BLOB columns) exceeds 200 MB, you won’t be able to use the export BLOB feature.