AWS Schema Conversion Tool Error 602

, ,

When migrating schemas to MySQL using the AWS Schema Conversion Tool (SCT), you may encounter the error:

“602: Converted tables might exceed the row-size limit in MySQL.”

This warning means that one or more tables being converted could exceed MySQL’s row-size limit. For the InnoDB storage engine (default in MySQL and Amazon Aurora MySQL), the maximum row length is 65,535 bytes. If your converted table design goes beyond this, MySQL will reject it.

Why This Happens

  • Large VARCHAR or TEXT columns
  • Too many columns in a single table
  • Wide columns that, when combined, exceed the 64KB limit
  • Non-optimized data types during schema conversion

Fixing the Issue

  1. Review and Optimize Column Data Types
  • Reduce overly large VARCHAR lengths. For example:
    • VARCHAR(1000) → VARCHAR(255) if values never exceed that length.
  • Replace TEXT with smaller types (TINYTEXT, MEDIUMTEXT) where possible.
  • Use integers (INT, SMALLINT, TINYINT) instead of BIGINT if values fit.
  1. Normalize the Table

If your schema has too many wide columns:

  • Split them into multiple related tables
  • Use foreign keys to maintain relationships
  • Store large blobs of data separately
  1. Drop Unnecessary Columns

Remove unused or redundant columns before migration to shrink the row size.

  1. Consider Storage Engine Options
  • InnoDB enforces the row-size limit but stores large TEXT/BLOB columns off-page (only a 20-byte pointer remains in the row).
  • If you only need full-text lookups, splitting those into reference tables may help.
  1. Change InnoDB Page Size (Advanced)

By default, InnoDB uses a 16KB page size. MySQL allows compilation with different page sizes (4KB, 8KB, 16KB, 32KB, 64KB).
⚠️ Important: This cannot be changed dynamically. You must recompile MySQL from source with a custom setting.

  • Download MySQL source
  • Modify the UNIV_PAGE_SIZE definition
  • Rebuild and reinstall MySQL
  • Re-import your schema and data

This approach is rarely used in practice because it complicates upgrades and maintenance, and is not supported on managed services like Amazon RDS or Aurora MySQL.

Best Practice in AWS Context

Since you’re working with AWS SCT and likely using Aurora MySQL or RDS, you cannot change InnoDB page size. Instead, the best fix is to:

  • Normalize your schema
  • Adjust column definitions
  • Split oversized tables

Takeaway

The 602 error in AWS SCT isn’t a hard failure—it’s a warning that your schema design may hit MySQL’s row-size limits. While increasing InnoDB page size is technically possible in self-managed MySQL builds, on AWS-managed databases the right solution is schema redesign and column optimization.

✅ Rule of thumb: If you’re migrating from Oracle, SQL Server, or DB2 into MySQL, review the largest tables carefully. Wide schemas that were fine in those engines may not fit in MySQL’s stricter row limits.