We encountered a critical issue in production where database inserts for emojis or special characters started throwing query exceptions (e.g., Incorrect string value) due to database table collations defaulting to latin1 rather than full utf8mb4, despite ORM mappings assuming UTF-8 compliance.
The Issue
Prisma does not enforce character set changes natively in raw MySQL schemas unless database default parameters are correctly configured on initial migration. This caused character truncation and write failures on user-generated feedback routes.
The Solution
We scripted a safe, lock-free migration plan to alter database character sets and schemas live under load, ensuring zero application locking.
-- Alter Database Default Charset
ALTER DATABASE lawyered_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
-- Safe Lock-Free Alter Table script
ALTER TABLE Feedback CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Result
Successfully migrated all tables with zero lockouts, reducing DB write exception rates to 0% and enabling full character support.