Catalog Configuration

The catalog is the source of truth behind DBModeler’s engine behavior, canonical type system, and SQL command templates.

What the catalog controls

Catalog configuration affects how DBModeler interprets and exports schema data.

Examples include:

supported engines
canonical data types
type fallback rules
sequence, identity, and auto-increment behavior
command templates for generated SQL
foreign-key action support

Default catalog versus custom catalog

Most users work with the built-in catalog.

Use a custom catalog when you need to:

add or tune engine metadata
extend type mappings
override fallback behavior
customize SQL generation templates

Custom catalogs extend the default behavior rather than replacing the whole product model blindly.

Project-level engine configuration

At the project level, DBModeler uses catalog metadata to drive setup fields such as:

default schema
table engine
default ID generation strategy
field type suggestions

This is why engine choice at project creation is more than a label. It changes the behavior of the modeling and export pipeline.

Type fallback behavior

DBModeler works with canonical types first and engine-native SQL second.

That means the same modeled field can export differently across engines depending on:

direct support
fallback to another type
fallback to an explicit SQL expression

When to customize the catalog

Reach for custom catalog work when the default product behavior is structurally wrong for your environment, not just when a single exported statement needs a one-off patch.

For isolated SQL exceptions, custom scripts are usually the lower-risk option.

Practical advice

Keep catalog changes versioned outside the app.
Test import and export after any custom catalog change.
Review validator export too, because catalog changes can affect both SQL and schema-generation behavior.

Next: Appearance and Themes