Migrate MySQL and MariaDB to Supabase PostgreSQL

A move from MySQL to PostgreSQL should be rehearsed before cutover. WZ-IT provides a Supabase migration from €3,490 after reviewing schema, data and application behaviour.

A MySQL or MariaDB to Supabase migration changes both provider and database engine. Supabase runs PostgreSQL. Tables and many standard types can be converted, while SQL dialect, routines, character sets and application assumptions need separate review.

The objective is not the fastest possible copy. It is a reproducible PostgreSQL structure with verified data and a compatible application.

Why migration is more than data export

MySQL, MariaDB and PostgreSQL differ in areas including:

• auto-increment and sequences
• Boolean and integer behaviour
• ENUM, SET and domain models
• UNSIGNED numbers
• DATETIME, TIMESTAMP and time zones
• zero dates and otherwise invalid date values
• JSON functions and operators
• collations, ordering and case sensitivity
• stored procedures, functions, triggers and events
• upserts, quoting and vendor-specific SQL syntax

An import can complete technically while producing incorrect values, sort order or application behaviour. Acceptance must therefore cover both data and behaviour.

Inventory the source

Look for source data that MySQL tolerates but PostgreSQL rejects, including invalid dates, truncated text or broken foreign-key assumptions.

Define the PostgreSQL target model

Document conversion choices explicitly. Examples include:

The correct mapping depends on business semantics. Automatic conversion is a starting point, not the final architecture decision.

pgloader or controlled ETL

The official Supabase guide offers a guided Colab workflow and pgloader. pgloader can copy schema and data directly from MySQL to PostgreSQL and convert many types automatically.

A custom ETL or export process can be preferable when:

• only selected data should move
• values need cleansing before import
• large tables require incremental transfer
• complex type and naming rules apply
• every transformation needs an audit trail

Choose the method after a representative rehearsal.

Routines and application logic

Stored procedures and functions do not become portable through data import. MySQL or MariaDB code needs implementation in PL/pgSQL, SQL, Edge Functions or an external application service.

Also review:

• raw SQL in source code
• ORM dialect and generated migrations
• transaction isolation and locking
• case sensitivity of table and column names
• pagination, full-text search and JSON queries
• error codes and retry behaviour

A staging deployment must run fully against Supabase before cutover.

Prevent silent semantic changes

Some differences do not cause an obvious import failure but still change results. Compare empty strings and NULL, case sensitivity, implicit type conversion, division, time zones and collation behaviour with real application data. The same applies to ON UPDATE timestamps, automatic defaults and queries that rely on a particular MySQL SQL mode.

Define business invariants for critical tables instead of validating row counts alone. Examples include unique customer identifiers, unchanged balances, consistent status transitions and complete relationships. Run these checks after the rehearsal and again immediately before release.

Supabase services are a separate step

The application can continue using a PostgreSQL driver after the database move. Introduce Supabase Auth, Storage, Realtime, the Data API and RLS only where they are required.

RLS in particular changes the permission model. Map application roles to user JWTs, anon, authenticated and server-side access, then verify them with negative tests.

Rehearsal and cutover

Validate at least:

• table and row counts
• checksums or samples of critical data
• decimal, date, Unicode and binary values
• primary and foreign keys
• sequences and new inserts
• views, triggers and replacements for routines
• critical read, write and reporting queries
• runtime and load on the source

Plan a write pause or a separate delta process for the final transfer. Use the Supabase migration checklist for the sequence and the PostgreSQL-to-Supabase guide for the target database.

WZ-IT can operate the result as managed Supabase after acceptance.

Sources

• Supabase: migrate from MySQL to Supabase
• pgloader documentation
• PostgreSQL: data types