Convert MySQL data types to Snowflake: the full mapping table, the query that proves each risky column before you load it, and the two places Snowflake's own connectors disagree

How does MySQL to Snowflake data type mapping work?

Sort the columns into three piles. Pile one converts cleanly and needs no thought: DATE, TIME, VARCHAR, TEXT, the ordinary integers, BINARY and JSON all have honest equivalents, and JSON is genuinely better in Snowflake than it was in MySQL. Pile two is not on the mapping list at all, and Snowflake tells you what happens: any unlisted type is mapped to TEXT by default. Pile three is the dangerous one. Those columns convert, load and behave differently, and nothing in the migration will mention it.

Pile three is invisible to the tooling for a structural reason. A connector can tell you that a type has no target, because that is a fact about its own mapping table. It cannot tell you that a column which converted perfectly well was carrying a meaning the target will not preserve, or that a flag column now answers a filter differently. Those are facts about your data and your application, and the only place the evidence still exists is the MySQL instance you are about to stop querying.

There is a second reason to check rather than trust, and it is unusual enough to be worth stating plainly. Snowflake publishes a data mapping page for its MySQL connector and another for its SQL Server connector. They are the same product family. They do not answer a decimal overflow the same way, and they do not answer a bit column the same way. Neither page acknowledges the other. A published mapping is a starting position, not a fact, even when the vendor publishing it owns the destination.

MySQL to Snowflake data type mapping table

The target column is what Snowflake publishes for its own MySQL connector. Every row was checked against the MySQL 8.4 Reference Manual and the Snowflake SQL reference on 6 September 2026. Rows marked "see below" are the ones that look equivalent and are not.

Eight risky mappings, and the query that proves each one is safe

This is the part no mapping table carries. For each risky conversion below, there is a query you can run against MySQL today, before you load anything, that tells you whether the risk is theoretical or whether it is already sitting in your data. Run all eight in an afternoon. They are the cheapest work in the entire migration.

SELECT table_name, column_name, numeric_precision, numeric_scale
FROM information_schema.columns
WHERE table_schema = DATABASE()
  AND data_type = 'decimal'
  AND numeric_precision > 38;

SELECT table_name, column_name
FROM information_schema.columns
WHERE table_schema = DATABASE()
  AND column_type = 'tinyint(1)';

-- then, for each column returned:
SELECT is_active, count(*) FROM orders GROUP BY is_active;

SELECT table_name, column_name, column_type
FROM information_schema.columns
WHERE table_schema = DATABASE()
  AND data_type = 'bit';

SELECT count(*) FROM orders
WHERE created_at = '0000-00-00 00:00:00'
   OR delivered_on = '0000-00-00';

SELECT count(*) FROM subscriptions
WHERE expires_at > '2037-01-01';

SELECT max(length(body)) AS max_text_bytes FROM articles;
SELECT max(length(file_data)) AS max_blob_bytes FROM attachments;

SELECT table_name, column_name, data_type, column_type
FROM information_schema.columns
WHERE table_schema = DATABASE()
  AND data_type IN ('set','enum');

SELECT data_type, count(*) AS columns
FROM information_schema.columns
WHERE table_schema = DATABASE()
GROUP BY data_type
ORDER BY columns;

How do I convert a MySQL TINYINT(1) to a Snowflake boolean?

Query the distinct values first, then cast deliberately in the target DDL. If a column holds only 0, 1 and NULL, a cast to BOOLEAN is safe and you should make it, because leaving booleans as integers pushes the ambiguity into every query written afterwards. If the column holds anything else, you have to decide what that value means before you choose a cast, and the decision is a business one rather than a technical one.

The reason this matters more than it sounds is that MySQL and Snowflake genuinely disagree. MySQL's manual is explicit that BOOL and BOOLEAN are synonyms for TINYINT(1), that zero is false and non-zero is true, and that the constants TRUE and FALSE are aliases for exactly 1 and 0. So in MySQL, 2 = TRUE is false. Snowflake's conversion rules say that zero converts to FALSE and any non-zero value converts to TRUE. So in Snowflake, that same row is true. A filter that excluded it now includes it, on data that migrated perfectly, with no error on either side.

There is a related detail worth knowing while you are in there. MySQL has deprecated the display width attribute on integer types outright, and its manual states that the width is unrelated to the range of values a column can store. TINYINT(1) has never meant a one-bit column. It has always been a full byte, and any value from -128 to 127 is legal in it, which is exactly how the value 2 got there in the first place.

Does Snowflake use MySQL?

No. Snowflake is a columnar analytic warehouse with its own storage engine and its own SQL dialect. It is not a MySQL fork and it is not MySQL compatible in the way that, say, MariaDB is. Ordinary queries move across largely unchanged because both follow the SQL standard for the common cases, and that is precisely what makes the differences dangerous: the parts that break are loud and get fixed, while the parts that quietly mean something else are the type system, the boolean handling and constraint enforcement.

The constraint point deserves its own sentence. Snowflake accepts PRIMARY KEY, UNIQUE and FOREIGN KEY definitions on standard tables, records them as metadata the optimizer can use, and does not enforce them. Only NOT NULL and CHECK are always enforced. Coming from MySQL with InnoDB foreign keys switched on, that is a bigger change than the type mapping, and it shows up first as double-counted revenue after a pipeline replays a batch. Land every ingestion path in a staging table and MERGE on the business key rather than appending.

Why do my row counts match but my numbers are wrong?

Because every failure mode on this route preserves row counts. A DECIMAL that lost precision is still one row. A flag that became a hex string is still one row. A spatial column that arrived as text is still one row. Row-count reconciliation is the check almost everyone runs and it is the check that cannot detect anything described on this page.

Reconcile on values instead. Per table, compare the row count, the SUM of every numeric column, MIN and MAX of every date, a count grouped by day, and a count grouped by each boolean flag. That last one takes a minute to write and is the check that catches the TINYINT problem, because it is the only comparison where the MySQL answer and the Snowflake answer differ on data that copied perfectly.

Should I use DATETIME or TIMESTAMP before migrating to Snowflake?

DATETIME, for almost everything, and standardize before you migrate rather than after. Snowflake's connector maps DATETIME to TIMESTAMP_NTZ and TIMESTAMP to TIMESTAMP_TZ, and both of those are correct: MySQL documents that it converts TIMESTAMP values to UTC for storage and back on retrieval, and that this does not happen for DATETIME. The mapping is faithfully reproducing a real difference.

The trouble is that the difference is invisible in application code. Two columns in the same table, both holding what a developer thinks of as a date and time, land in two Snowflake types with different time zone semantics, and any query that compares them has to reconcile that. MySQL TIMESTAMP also stops at 2038-01-19, which bites today rather than in twelve years, because contract and subscription end dates are stored ahead of time. Picking one type per table during the migration costs an afternoon and removes a class of bug permanently.

What MySQL data types does Snowflake not support?

There is no formal unsupported list, which is a different and slightly worse situation than a vendor publishing one. Snowflake states that any MySQL type not in its mapping table is mapped to TEXT by default. The types that fall through that gap in practice are the spatial family, GEOMETRY, POINT, LINESTRING and POLYGON, along with anything exotic a long-lived schema accumulated. They arrive as strings, every spatial function you were using stops existing, and nothing warns you.

Two further cases behave like unsupported types even though they map. MySQL TIME legally holds a duration from -838 to 838 hours as well as a clock time, and only the clock time survives. And MySQL's SET is stored as a bitmask but arrives as a comma-separated string in column declaration order, so anything that treated it as a set is now parsing a string whose ordering was decided by DDL somebody wrote years ago.

What this costs if you get it wrong

Not much in tooling, and quite a lot in reloads. Every mistake in this article is found after a load and fixed by running the load again, and a migration backfill is the most expensive thing you will ever ask a warehouse to do. On row or event based pipeline pricing it is the largest month you will have; on Snowflake credits it is a sustained spike in warehouse time. Budget for at least three full loads and you will probably use two. Teams that watch cloud and SaaS spend as it accrues notice the third reload while it is running rather than on the invoice five weeks later, which is usually the difference between a conversation and an incident.

The eight queries in the table above are the cheapest insurance available against all of it. They run against a database you already have, they need no new tooling, and they take an afternoon. Every one of them turns a question you would otherwise answer after go-live into a decision you make while it is still free to change your mind.

The full tool comparison for this route, including what each vendor bills by and the binlog prerequisite that rules Snowflake's own connector out on some managed hosts, is on our MySQL to Snowflake migration tools page, and the step by step cutover sequence is in the MySQL to Snowflake migration guide. The equivalent treatment for the other routes out of MySQL is in convert MySQL data types to PostgreSQL, and the neighboring connector this page compares against is covered in convert SQL Server data types to Snowflake. If MySQL is staying alive alongside the warehouse, the ongoing case is in Snowflake ETL tools, and the budget model behind either program is in what a data migration really costs.