Compatibility and pitfalls when migrating from TiDB to Aurora MySQL
Both speak the MySQL protocol, but the internals differ. Proceeding on the assumption that "MySQL-compatible means it moves" is how performance and locking problems arrive after go-live.
This page is for teams considering a move from TiDB, a distributed database, to Amazon Aurora MySQL, a MySQL-compatible cloud database. GIIP has migrated an approximately 3 TB TiDB environment to Aurora MySQL.
You do not know how far to trust compatibility
"MySQL-compatible" does not tell you at what level behaviour is actually identical.
Distribution-era design decisions are unresolved
Table splitting and access patterns designed for TiDB may or may not belong on a single cluster.
You fear it will be slower
Execution plans change, and you have no way to assess which previously fine query becomes heavy.
They scale differently
TiDB spreads data across nodes; Aurora MySQL is a single cluster over shared storage. The same SQL carries different throughput assumptions.
Plans are rebuilt on the target
A different optimiser means the same query does not necessarily produce the same plan. Index design may need revisiting.
Transaction and locking premises differ
Isolation level and locking differences show up most in highly concurrent processing.
Verify compatibility as "same result and same performance characteristics", not merely "it runs".
Reconcile schema and data types
Identify differences in primary keys, auto-increment, index design, data types, character sets and collations.
Assess queries and batches
Identify queries that get heavier when plans change, and check the load profile of bulk update and delete batches.
Operate Aurora afterwards
Redefine monitoring items including Aurora-specific metrics, and continue performance monitoring after the move.
What you can check yourself first
- Data volume and how unevenly it is distributed across tables
- Peak concurrent connections and connection pool settings
- Whether bulk update or delete batches exist
- Whether long-running transactions exist
- Where TiDB-specific features are used
- Queries you already know to be slow
- How many hours the business can be down
What we can evidence
Migration duration, downtime, post-migration performance change and cost change are not stated because they are not confirmed as measured values.
Frequently asked questions
If it is MySQL-compatible, can we just repoint the application?
Protocol compatibility is not behavioural equivalence. Schema, data types, execution plans, transactions, batch processing and operational procedures each need verification.
Will performance improve after migrating?
We do not claim it will. Performance depends on workload and query characteristics, and in our own engagement the post-migration performance change was not confirmed as a measured value, so it is not published.
Can a 3 TB environment be migrated?
GIIP has migrated an approximately 3 TB TiDB environment to Amazon Aurora MySQL. For larger scales we answer after reviewing the current configuration.
Can you operate Aurora afterwards?
Yes. GIIP continuously monitors and operates cloud databases including multiple Amazon Aurora MySQL instances.
Large-scale database migration checklist — what to settle before you start
Check for free whether your database can be migrated SQL Server to AWSHow to migrate SQL Server to AWS, and what to check first
Check for free whether your database can be migrated Database migration costWhat actually determines the cost of a database migration
Check for free whether your database can be migratedCheck whether a move off a distributed database is feasible
Tell us the data volume, batch processing and downtime tolerance, and we will lay out what needs verifying.