Oracle Database to MySQL: How to Move Your Data

Moving data from Oracle Database to MySQL usually starts with an export. Data Pump, or a set of hand-written SELECT statements piped into a loader, gets the rows across once. It does not get them across again tomorrow, it re-reads everything when you try, and it tells you nothing about what was deleted in between.

This guide covers the managed path: replicating Oracle tables into MySQL with Airbyte on a schedule. Before the setup, though, settle one question, because it changes how much care the rest deserves. Are you migrating off Oracle, or keeping it as the system of record and building a MySQL copy alongside? The technical steps are identical. The tolerance for imperfect type mapping is not.

Oracle Database to MySQL at a glance:

Why move data from Oracle Database to MySQL?

Two situations account for most of these pipelines, and they want different things from it.

The first is cost and access. Oracle licensing makes it expensive to give every internal application its own connection, and plenty of teams simply are not allowed near it. A MySQL copy gives an application or a reporting tool something to read without adding load or licence cost to the system of record. Here, small type-mapping imperfections are usually tolerable.

The second is a genuine migration off Oracle, where the pipeline runs alongside the old system during cutover and keeps MySQL current until traffic switches. Here nothing is tolerable, because the copy becomes the system of record. Every column whose type maps almost correctly is a defect waiting to be discovered by a customer rather than by you.

What do you need before you start?

The prerequisites depend heavily on which Oracle connector you use:

A decision about deletes. The standard Oracle source replicates using a cursor and cannot observe a deletion, so a row deleted in Oracle stays in MySQL indefinitely with nothing reporting the discrepancy. Log-based change data capture is on the Enterprise Oracle source. Decide which you need before anything else.

DBA time, if you want CDC. Enterprise CDC needs supplemental logging plus instance-level settings, and a grant list covering flashback access, select on any table, the catalog roles, select on any transaction, log mining, and rights to create tables and sequences and lock tables. On a multitenant container database each grant needs the container clause and an extra privilege applies.

An identifier length audit. LogMiner ignores tables and columns whose names exceed 30 characters, silently. Run this check before the first sync, not after a table has quietly stopped updating.

A MySQL user with write access. On the destination side you need a database and a user able to create and write tables in the target schema. Airbyte adds its own metadata columns to each table alongside your data.

If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on both databases before you begin.

How do you build an Oracle to MySQL pipeline in Airbyte?

Step 1: Prepare Oracle and plan your column types

Create a read-only Oracle user, apply the CDC grants if you are using Enterprise, and audit your identifier lengths. Then go through the columns and decide how the awkward ones should land, particularly anything declared as NUMBER without precision. This is the step people skip and the one that determines whether the result is trustworthy.

Step 2: Configure the Oracle source

Click Sources in the left navigation, then New Source, and select the Oracle connector you decided on, following adding a source. Supply the host, port, service name or SID, schema and credentials, and pick an encryption method. Native network encryption and TLS with certificate verification are both available; unencrypted is offered only on self-managed Airbyte, and it is not the option to reach for just because it works.

Step 3: Configure the MySQL destination

Click Destinations, then New Destination, and select MySQL, following adding a destination. Supply the host, port, database and credentials. If this is a migration, decide now whether the application can tolerate Airbyte's metadata columns in the tables it will read, or whether you will expose views that exclude them.

Step 4: Create the connection and verify the types

Click Connections, then New connection, pick your source and destination, and select tables and a sync mode per stream. Run the first sync against a subset rather than the whole schema, then compare the resulting MySQL column types and a sample of values against Oracle before extending. Finding a precision problem on three tables is a morning. Finding it on ninety, after a report has been built, is not.

Why would CDC silently skip a table?

LogMiner ignores tables whose names exceed 30 characters, and columns whose names exceed 30 characters. It does not warn and it does not error. The table sits in your connection looking configured and never receives an update.

The counterintuitive part is which schemas this affects. Oracle capped identifiers at 30 characters for most of its history, so genuinely old schemas are under the limit everywhere by construction. Anything built on 12.2 or later can use longer names, and descriptive naming conventions produce them easily. A table called CUSTOMER_SUBSCRIPTION_RENEWALS is exactly 30 characters. One more word and CDC stops seeing it.

Datatypes have the same shape of problem. LogMiner does not support every Oracle type, and user-defined types such as a VARRAY cannot be replicated through CDC at all. If your schema leans on object types, check them before committing to a design that assumes log-based capture.

How do Oracle types land in MySQL?

Oracle's NUMBER can be declared without precision or scale, in which case it holds a far wider range than any single MySQL numeric type covers exactly. MySQL forces a choice between an integer type, a fixed-point decimal and a floating-point type, and each loses something different: fixed-point preserves exactness at the cost of range, floating-point does the reverse.

For financial columns the answer is always fixed-point decimal with explicit precision, and it is worth declaring those columns in MySQL yourself rather than accepting what the pipeline infers. For identifiers and counters an integer type is fine. The columns worth actually inspecting are the ones nobody thought about: a NUMBER holding a ratio, a measurement or a score, where precision loss throws no error and surfaces as a small unexplained variance in a report six weeks later.

Two more to check. Oracle's large object types and MySQL's text types have different size ceilings and different behaviour around trailing spaces in fixed-length character columns. And Oracle's DATE carries a time component, which surprises anyone assuming it behaves like a MySQL DATE, so look at any column where a report groups by day.

Frequently asked questions

Does the standard Oracle source support CDC?

No. Log-based change data capture is on the Enterprise Oracle source. The standard connector uses a cursor and cannot capture deletes.

Why is one of my Oracle tables never updating in MySQL?

Check the identifier length. LogMiner ignores tables and columns whose names exceed 30 characters, without raising an error.

How should I map Oracle NUMBER columns?

Fixed-point decimal with explicit precision for anything financial, integer types for identifiers and counters. Inspect any NUMBER holding a ratio or measurement, where precision loss is silent.

Does this migrate my indexes and stored procedures?

No. The pipeline moves rows. Constraints, indexes, triggers, sequences and procedural logic have to be recreated separately as part of the wider migration.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven, from creating the source through to scheduling the connection. If you would rather manage pipelines as infrastructure, the same source, destination and connection can be provisioned from configuration files instead.

Get your Oracle data into MySQL

Decide first whether this is a migration or a reporting copy, because that answers how much type-mapping care is warranted and whether you need Enterprise CDC. Then audit identifier lengths, declare your numeric columns deliberately, use an encrypted connection, and verify types on a subset before extending to the whole schema.

Airbyte's connector catalog includes 600+ pre-built connectors, so the same Oracle source can also feed a warehouse without rebuilding anything. For MySQL as a source rather than a destination, see MySQL to Snowflake, and for log-based replication with a far lighter setup cost, PostgreSQL to Databricks is a useful comparison.

Start syncing now →