Understanding Data Loss Warnings
No two engines have the same type system, so some conversions lose information by definition. The analysis step names each one before you migrate rather than after, and grades it by what the loss can do to your data. The grade is about consequence, not likelihood: a HIGH warning may never fire on your data, but if it does, values change.
Before you start
- A completed analysis run on the project.
- Enough knowledge of the data to say whether a range or precision limit is reachable in practice.
Steps
- 1
After analysis, check the 'Data Loss Analysis' table in the Schema tab
- 2
Risk levels: HIGH = potential data corruption, MEDIUM = precision/constraint loss, LOW = format change only
- 3
Common warnings: BIGINT→INT (truncation), ENUM→TEXT (constraint loss), DATETIME→TIMESTAMP (timezone handling)
- 4
Review each warning and decide if the mapping is acceptable for your use case
- 5
Use the Query Playground to spot-check critical data after migration
What goes wrong
MySQL TINYINT(1) is a boolean; TINYINT is not
Converting both to boolean corrupts ratings and counters, and converting both to an integer loses every flag's meaning. The distinction is made on the declared width, and it is worth checking on any table that stores a 0-5 score.
UNSIGNED columns need a wider target type
A target without unsigned integers has to widen the column, otherwise values above the signed maximum wrap or fail. Look for this on ID columns in older MySQL schemas.
ENUM to TEXT loses enforcement, not data
The values survive; the guarantee that only those values can be written does not. Where the target supports it, a CHECK constraint or a native enum type keeps the guarantee — but the application may still need to stop relying on the database to reject a bad value.