Supporting 8 DBMS: Our Approach to Multi-DBMS Support

Relmic supports 8 database management systems from a single visual editor. This is not just a dropdown that swaps table syntax — each DBMS has its own data types, constraints, auto-increment semantics, identifier rules, and validation logic. Here is how we built it.

Why multi-DBMS matters

Teams rarely work with a single database. A company might use PostgreSQL for its main application, BigQuery for analytics, and SQLite for mobile storage. Agencies and consultants work across client stacks that span MySQL, SQL Server, and Oracle.

A schema design tool that only supports one DBMS forces you to learn a different tool for each project — or worse, design in a generic tool that generates incorrect SQL because it does not understand the target system. Relmic solves this by making DBMS selection a first-class project setting that affects every layer of the editor.

DBMS as a core abstraction

When you create a project in Relmic, you choose a DBMS and a version. This selection propagates through the entire experience:

Data type picker — only shows types valid for the selected DBMS. PostgreSQL users see JSONB and UUID; MySQL users see ENUM and SET.
Default expression suggestions — autocomplete offers functions that exist in your DBMS. A timestamp column suggests now() in PostgreSQL but CURRENT_TIMESTAMP in MySQL.
Validation rules — identifier length limits, reserved keywords, and constraint rules are checked against the specific DBMS. Read more in the Validation docs.
Code generation — exported DDL uses the correct syntax, quoting style, and dialect for the target DBMS.

What makes each DBMS different

SQL is standardized, but every DBMS extends and deviates from the standard in meaningful ways. Here is a brief look at the unique characteristics Relmic handles for each:

PostgreSQL

Rich type system with arrays, JSONB, UUID, and composite types. SERIAL and IDENTITY for auto-increment. Extensive function library for defaults.

MySQL

ENGINE selection (InnoDB for foreign keys), ENUM and SET types, AUTO_INCREMENT columns, charset and collation settings per column.

MariaDB

MySQL-compatible with additions like sequences, system-versioned tables, and extended JSON support.

SQL Server

IDENTITY columns, NVARCHAR for Unicode, schema-qualified naming, computed columns, and T-SQL-specific default expressions.

SQLite

Flexible type affinity system, limited ALTER TABLE support, AUTOINCREMENT only on INTEGER PRIMARY KEY, no ENUM type.

Oracle

NUMBER with precision and scale, VARCHAR2 vs CHAR semantics, sequence-based auto-increment, 128-character identifiers (12c+).

BigQuery

Struct and array types, partitioning and clustering options, no traditional primary or foreign key enforcement.

Redshift

Distribution and sort key strategies, DISTSTYLE options, Redshift-specific data types like SUPER for semi-structured data.

Version-aware generation

DBMS versions matter. PostgreSQL 15 supports MERGE statements that PostgreSQL 13 does not. Oracle 12c raised the identifier length limit from 30 to 128 characters. MySQL 8.0 introduced CHECK constraints that earlier versions silently ignored.

When you select a DBMS version in Relmic, the data type list, default expression suggestions, and validation rules adjust to match. If you use a feature that is not available in your selected version, validation flags it before you export.

Beyond SQL: ORM and type exports

Multi-DBMS support extends to non-SQL exports as well. When you export a Prisma schema, Relmic sets the correct provider and maps column types to Prisma's type system. Drizzle ORM exports use the correct dialect package (drizzle-orm/pg-core vs drizzle-orm/mysql-core). TypeScript interfaces and JSON Schema exports are DBMS-agnostic but still reflect the exact types you configured.

See the full list of formats in the Forward Engineering docs.

Switching DBMS

What if you start a project targeting PostgreSQL and later need to support MySQL? Relmic lets you change the target DBMS in project settings. When you switch, the editor re-validates your schema against the new DBMS rules and highlights any incompatibilities — types that do not exist, identifier names that are reserved, or constraints that work differently.

This makes Relmic useful not just for designing new schemas, but for evaluating the effort of migrating between database systems.