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,SETand domain modelsUNSIGNEDnumbersDATETIME,TIMESTAMPand 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
| Area | Typical questions |
|---|---|
| Engine | MySQL or MariaDB, version and storage engines |
| Data model | Tables, keys, constraints, views and partitioning |
| Types | Unsigned, enum, JSON, decimal, binary and date/time |
| Character sets | UTF-8 variants, collations and sort semantics |
| Logic | Procedures, functions, triggers and events |
| Application | Drivers, ORM, raw SQL and migration tooling |
| Operations | Size, write load, maintenance window and rollback target |
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:
| MySQL or MariaDB | Possible PostgreSQL target |
|---|---|
AUTO_INCREMENT |
Identity column or sequence |
TINYINT(1) |
boolean after checking values |
UNSIGNED BIGINT |
Larger type or constraint |
ENUM |
PostgreSQL enum, lookup table or check constraint |
DATETIME |
timestamp with an explicit timezone decision |
JSON |
Usually jsonb after reviewing queries |
| MySQL Event | pg_cron, worker or external automation |
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.
