Data Type Mapping

DBModeler models fields through canonical type IDs and then maps those logical types to the selected engine during export and import.

How the mapping model works

The app starts with a database-agnostic type system, then applies engine-specific rules from the catalog.

That lets DBModeler keep the editor consistent while still producing engine-specific SQL.

Mapping outcomes

When a field is exported, DBModeler can do one of several things:

• use the native engine type directly
• fall back to a different canonical type representation
• fall back to an explicit SQL expression
• reject or broaden unsupported edge cases

Examples of where mappings matter most

• UUID may map very differently across PostgreSQL, MySQL, and Oracle.
• numeric precision and scale support varies across engines.
• binary, JSON, and spatial families are especially engine-sensitive.
• array support is not universal and may degrade to broader storage strategies.

Why canonical types are useful

Canonical types make these workflows possible:

• consistent field editing in the UI
• more predictable import normalization
• validator-schema generation from the same model
• multi-engine export without reauthoring the whole diagram

Practical rule

If a field is important to interoperability, inspect the final engine-specific SQL instead of assuming the logical type name tells the whole story.

Next: Catalog JSON Structure