Database

Database Data Type Mapper

Maps column types between seven database engines, keeping length and precision.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste the column types one per line. Keep the declared length — varchar(120) maps better than varchar.
  2. Choose the target engine, or turn on Show every engine to use the result as a reference table.
  3. Select Map the types.
  4. Check anything marked as unrecognised by hand — it was left blank deliberately rather than guessed at.

What data type mapper does

Every migration and every replication job runs into the same wall: the source engine has a type the target does not. Some of the gaps are obvious, like MySQL having no boolean. Some are quiet and expensive, like a UUID that is sixteen bytes on PostgreSQL and thirty-six characters on Snowflake unless you say otherwise, or a timestamp that silently loses its time zone on the way across. Guessing the mapping usually works until the first value that does not fit.

Paste your column types, one per line, and pick a target engine — or show every engine at once and use the table as a reference. Each type is resolved to a logical type first and then to the target, which is why a declared length or precision survives the trip: varchar(120) becomes nvarchar(120) on SQL Server and varchar2(120 char) on Oracle rather than losing its size. Anything the tool does not recognise is marked as unrecognised rather than mapped to a guess, because a silently wrong type is worse than a gap you can see.

Frequently asked questions

Because mapping pairwise does not scale. Seven engines means forty-two directed pairs to define and keep correct; mapping each source type to a logical type and each logical type to each engine means one table with a row per concept. It also makes the middle step visible, so you can see that your timestamptz was understood as "timestamp with zone" before it became datetimeoffset.

Yes. varchar(120) becomes nvarchar(120) on SQL Server and varchar2(120 char) on Oracle, and numeric(12,2) keeps both its precision and its scale. Types that have no length on the target — BigQuery STRING, PostgreSQL text — drop it, which is correct rather than a loss.

Because guessing would be worse. Engine-specific types such as PostgreSQL enums, ranges, geometry and domain types have no clean equivalent elsewhere, and quietly mapping one to text would hide a decision you need to make deliberately. A blank cell tells you where to look; a wrong cell does not.

Whichever preserves the time zone behaviour you already depend on. PostgreSQL timestamptz stores an instant and converts on display; MySQL timestamp does something similar but silently, while MySQL datetime does not convert at all. Mapping between the two families without checking is one of the most common ways a migration corrupts data it appears to have copied cleanly.