Stay organized with collections
Save and categorize content based on your preferences.
Migrating a schema from your source database to Spanner involves a
multi-step process that combines automated tooling with manual analysis
and refinement. The following steps outline the recommended approach:
Schema extraction: Extract the schema definition (DDL) from your source
database.
Initial conversion: You can consider using an automated
schema conversion tool, such as
Spanner migration tool (SMT),
which can handle many of the basic data type mapping and structural
conversions.
Detailed schema review and refinement: Consider converting your source
database schema that's more compatible with Spanner in smaller,
deliberate changes, that can be individually tested and optimized to reduce
the risk of changing everything at once.
Data type mapping: Review and refine the data type mapping generated
by SMT. Ensure that Spanner data types accurately represent
the range, precision, and semantics of the corresponding source database
types.
Primary keys and interleaving: Identify opportunities to use
Spanner's interleaved tables to model parent-child
relationships present in the source database schema. Choose appropriate
primary key strategies
for Spanner such as using UUIDs. SMT can help you choose an
appropriate primary key strategy. Consider
the implications for data locality and hotspot avoidance. Evaluate how
foreign key constraints are used in your source database and determine
how to handle them in Spanner. For more information, see
Parent-child table relationships.
Index optimization: Analyze existing indexes in your source database
and design Spanner indexes to optimize query performance.
Consider dropping infrequently used indexes.
Remove incompatibilities: Remove or rewrite any source database
specific features that aren't supported in Spanner. For
example, Spanner doesn't support stored procedures or
triggers. This might require you to refactor application code.
Schema deployment: Deploy the Spanner schema to a
development or staging environment.
Iterative testing and refinement:
Load sample data
and test the schema with representative application interactions. Monitor
performance and identify areas of improvement. Refine the schema based on the
results of testing. Repeat this process until the schema meets your application's
performance and functional requirements.
Schema validation: Develop scripts or procedures to compare the structure
of the source database and Spanner schemas to ensure that the
conversion was performed correctly.
Final schema deployment: Deploy the validated and refined schema to the
Spanner production instance.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Migrate your schema\n\nMigrating a schema from your source database to Spanner involves a\nmulti-step process that combines automated tooling with manual analysis\nand refinement. The following steps outline the recommended approach:\n\n1. **Schema extraction**: Extract the schema definition (DDL) from your source\n database.\n\n2. **Initial conversion** : You can consider using an automated\n schema conversion tool, such as\n [Spanner migration tool (SMT)](https://github.com/GoogleCloudPlatform/spanner-migration-tool),\n which can handle many of the basic data type mapping and structural\n conversions.\n\n3. **Detailed schema review and refinement**: Consider converting your source\n database schema that's more compatible with Spanner in smaller,\n deliberate changes, that can be individually tested and optimized to reduce\n the risk of changing everything at once.\n\n 1. **Data type mapping**: Review and refine the data type mapping generated by SMT. Ensure that Spanner data types accurately represent the range, precision, and semantics of the corresponding source database types.\n 2. **Primary keys and interleaving** : Identify opportunities to use Spanner's interleaved tables to model parent-child relationships present in the source database schema. Choose appropriate [primary key strategies](/spanner/docs/schema-design#primary-key-prevent-hotspots) for Spanner such as using UUIDs. SMT can help you choose an appropriate primary key strategy. Consider the implications for data locality and hotspot avoidance. Evaluate how foreign key constraints are used in your source database and determine how to handle them in Spanner. For more information, see [Parent-child table relationships](/spanner/docs/schema-and-data-model#parent-child).\n 3. **Index optimization**: Analyze existing indexes in your source database and design Spanner indexes to optimize query performance. Consider dropping infrequently used indexes.\n 4. **Remove incompatibilities**: Remove or rewrite any source database specific features that aren't supported in Spanner. For example, Spanner doesn't support stored procedures or triggers. This might require you to refactor application code.\n4. **Schema deployment**: Deploy the Spanner schema to a\n development or staging environment.\n\n5. **Iterative testing and refinement** :\n [Load sample data](/spanner/docs/load-sample-data)\n and test the schema with representative application interactions. Monitor\n performance and identify areas of improvement. Refine the schema based on the\n results of testing. Repeat this process until the schema meets your application's\n performance and functional requirements.\n\n6. **Schema validation**: Develop scripts or procedures to compare the structure\n of the source database and Spanner schemas to ensure that the\n conversion was performed correctly.\n\n7. **Final schema deployment**: Deploy the validated and refined schema to the\n Spanner production instance.\n\nSource specific guides\n----------------------\n\n- MySQL: [Migrate MySQL schema](/spanner/docs/migrate-mysql-schema)."]]
