Migrating an approximately 3 TB TiDB environment to Amazon Aurora MySQL
A case study of migrating an approximately 3 TB TiDB environment to Amazon Aurora MySQL — starting from the premise that MySQL compatibility and "move it without verification" are not the same thing.
TiDB is a distributed database; Aurora MySQL is a MySQL-compatible cloud database. Both speak the MySQL protocol, but their internals and operating models differ. GIIP has migrated an approximately 3 TB TiDB environment to Amazon Aurora MySQL, verifying schema, data, queries and operating procedures along the way.
Case summary
| Source database | TiDB |
|---|---|
| Data volume | Approximately 3 TB |
| Target | Amazon Aurora MySQL |
| Main challenge | Verifying compatibility, schema, SQL and operating procedures |
| Disclosure limits | Customer names and business data not disclosed |
The scale figures on this page are based on GIIP’s hands-on experience. Customer names and system-specific information are not disclosed for confidentiality and security reasons.
What this case study establishes
- GIIP has migrated an approximately 3 TB TiDB environment to Amazon Aurora MySQL.
- Schema, data, queries and operating procedures were migrated while checking the differences between a distributed database and a MySQL-compatible cloud database.
- GIIP can continue to monitor and operate Aurora MySQL after the migration.
Structural differences between TiDB and Aurora MySQL
TiDB is a distributed SQL database that spreads data across nodes. Aurora MySQL is a MySQL-compatible database built as a single cluster over shared storage. Because they scale differently, the same SQL can carry different assumptions about execution plans, throughput characteristics and locking behaviour.
So a migration is not "point the application somewhere else". There is a step where table partitioning and access patterns designed for a distributed engine are re-examined against a single-cluster target.
MySQL compatibility does not mean you can skip verification
- Schema: confirm whether primary key and index design that assumed distribution still fits.
- Data types: confirm that type handling and precision differences do not change values after migration.
- SQL: execution plans change, so queries that were never a problem can become heavy.
- Transactions: isolation level and locking behaviour carry different assumptions.
- Batch processing: bulk update and delete load characteristics change, so existing batches need re-checking.
- Operations: backup, failover and scaling procedures cannot simply be carried over.
Data volume
The source was an approximately 3 TB TiDB environment. At that size, choosing the migration mechanism (logical dump versus replication) and designing how much time verification can take become the same conversation.
For this engagement, migration duration, downtime, post-migration performance change and cost change have not been confirmed as measured values, so they are not stated on this page.
Operating Aurora after the migration
GIIP continues to monitor and operate Aurora MySQL after cutover. Cloud databases including multiple Amazon Aurora MySQL instances, plus approximately 30 web services, are under continuous monitoring by AI agents and human experts today.
Monitoring does not stop at detection: it continues through situation analysis, first-line response along approved procedures, reporting, and escalation to human experts where needed.
Representative items to verify in a TiDB to Aurora MySQL migration
The following are representative items to check when migrating from TiDB to Aurora MySQL. It does not mean every one of them was used in this particular engagement.
- 01Schema definition differences (primary keys, auto-increment, index design)
- 02Data type, character set and collation differences
- 03Execution plan changes and the slow queries they can introduce
- 04Transaction isolation level and locking behaviour assumptions
- 05Load characteristics of bulk update and delete batches
- 06Connection count and connection pool design
- 07Behaviour during replication and failover
- 08Backup and restore procedures
- 09Redefinition of monitoring items, including Aurora-specific metrics
- 10Reconciliation of row counts and consistency before and after migration
This list is a general technical explanation. The items that actually apply differ by environment, and this is not a full account of what was performed in this engagement.
Frequently asked questions
TiDB is MySQL-compatible — can we move straight to Aurora?
Protocol compatibility is not behavioural equivalence. Schema, data types, SQL execution plans, transactions, batch processing and operational procedures each need to be verified.
How long does the migration take, and how much downtime?
It depends on data volume, tolerable downtime and how long verification can run. Measured duration and downtime for this engagement have not been confirmed, so we do not quote figures.
Will performance improve after migrating?
We have not confirmed a measured post-migration performance change for this engagement, so we do not claim performance improved. Performance depends on workload and query characteristics; we assess against your actual queries.
Can you handle a 3 TB environment?
GIIP has migrated an approximately 3 TB TiDB environment to Amazon Aurora MySQL. For larger scales we will answer after reviewing your current configuration.
GIIP Database & Cloud Operations Team
Designs, migrates and operates large-scale web services, SQL Server, Oracle, AWS and Azure environments. Experience includes 12 sets of x12large-class AWS RDS for SQL Server environments, an Oracle environment with approximately 120,000 tables, and a migration from an approximately 3 TB TiDB environment to Amazon Aurora MySQL. The team currently monitors and operates multiple cloud databases and approximately 30 web services together with AI agents.
- First published
- Last updated
This page separates what GIIP actually did from general technical explanation. Items listed as general checklists are not claims that every item was performed in this particular engagement.
Customer names, system-specific information and business data are not disclosed, for confidentiality and security reasons. Only scale figures based on GIIP’s hands-on experience are published.
Operated by GIIP Co., Ltd. (Japan operations: SHINSEMA Inc.) / Contact: contact@littleworld.net
Other migration case studies
SQL Server → AWS RDS (x12large class, 5 replicas, 12 sets)
On-premises SQL Server migrated to AWS RDS for SQL Server, with the same class of configuration deployed 12 times.
Oracle migration case studyOracle, ~120,000 tables → AWS
An on-premises Oracle environment with an extreme object count, migrated to AWS.
Related database migration & operations pages
Check whether a migration off a distributed database is feasible
Tell us your data volume, table layout, batch processing and tolerable downtime, and we will lay out what needs to be verified.