MariaDB Holds the Truth. Most Integrations Only Read It.

Why MariaDB ends up holding the operational truth

MariaDB began in 2009 as a fork of MySQL, taken by Michael Widenius after Oracle's acquisition of Sun put the original project's future in doubt. He named it after his younger daughter, Maria, the same way MySQL was named after his elder daughter, My. That story is worth reading in full, and we told it in the origin story of MariaDB. The reason it matters here is practical: a fork that stayed open source under a foundation is a fork plenty of enterprises adopted deliberately, and it has been drifting from upstream MySQL ever since.

That drift is invisible until you connect something to it. Both databases speak the same wire protocol and both write a binary log, so a MySQL client connects without complaint. The details an integration depends on are no longer identical.

None of that stops a connection from opening. It does mean a change capture implementation written against MySQL's GTID format has to understand MariaDB's, and a field mapping that expects a native JSON column has to handle a LONGTEXT that happens to contain JSON. If you run both engines in the same estate, the MariaDB connector and the MySQL connector are treated as separate systems for this reason.

Change capture: read the binary log, do not poll the table

There are two ways to find out that a row in MariaDB changed. You can ask, repeatedly, or you can be told.

Asking means polling: a query every 30 or 60 seconds against an updated_at column, ordered and limited, per table. It works on small tables and gets expensive quickly. It needs an indexed timestamp on every table you care about, it misses hard deletes entirely, it misses any update that does not touch the timestamp, and it competes with your application for the same buffer pool and the same connections. At a few hundred tables it becomes background load a DBA will notice.

Being told means change data capture from the binary log. MariaDB already writes every committed row change there for replication and point-in-time recovery. A sync engine registers as a replica, reads the stream from a GTID position, and receives inserts, updates, and deletes in commit order with no query load on the tables. Set binlog_format=ROW so events carry before and after images rather than statement text, and keep binlog_row_image=FULL if you want conflict resolution to compare the old value.

That shape is the one to hold a vendor to. One stream in, writes back out through the same engine, and every application system on the far side going through the integration layer rather than opening its own connection to your primary.

Writing back into MariaDB is the half most tools skip

Reading is the easy direction. Every ELT vendor can extract from MariaDB. Ask what happens when the value changes on the other side and the answers thin out fast.

A write-back path has to solve problems an extract never meets. It has to write a single row rather than reload a table, because reloading a 40 million row orders table to change one status is not something you do to a production primary. It has to write inside a transaction and be idempotent, so a retry after a network timeout does not create a duplicate. And it has to respect what is already on the table: foreign keys, unique indexes, triggers, and any ON UPDATE CASCADE relationship that quietly fans one write out across several tables. We walked through that fan-out in cascading changes and best practices, and it applies unchanged to MariaDB.

Then there is the connection budget. max_connections on a busy primary is a finite number, often set between 150 and 500, and it is already spoken for by the application's pool. An integration that opens a connection per worker, per table, or per sync run is competing with the thing that pays the bills. A platform should hold a small pooled count, release connections quickly, and back off rather than pile up when the server is under load. Ask for that number before you sign anything. The configuration walkthrough in the MySQL two-way sync guide covers the same settings, and most of it transfers directly.

Schema drift, replica lag, and Galera

Databases move. Someone adds a column, widens a VARCHAR, renames a field, or runs an online schema change that rebuilds the table under a new name and swaps it in. If the sync engine holds a cached picture of the schema and has no way to notice, one of two things happens: it starts writing into a column that no longer means what it did, or it stops.

• DDL in the binary log. ALTER TABLE shows up in the stream. An engine that reads it can update its own mapping and surface new fields as unmapped, instead of failing on the next row event.
• Online schema change tools. gh-ost and pt-online-schema-change build a shadow table and cut over. Change capture has to follow the cutover rather than keep reading a table that is about to be dropped.
• Replica lag. Reading from a read replica takes load off the primary and costs you freshness. Seconds_Behind_Master is an estimate, not a guarantee, and a lagging replica turns a two-way sync into a race.
• Galera. A Galera cluster is multi-primary with certification-based replication and per-node binary logs. Attach change capture to one pinned node, or the same transaction can be seen twice after a node rejoins.

Origin tracking is what makes the whole thing safe. Every write the platform makes into MariaDB is tagged, so when that row comes back through the binlog a moment later it is recognised as an echo and dropped rather than pushed back out to the CRM. Without it, a two-way sync is an infinite loop with a delay on it.

One-way ETL is not integration

A pipeline that copies MariaDB into a warehouse every night answers questions about yesterday. It does not keep the account status in the CRM aligned with the row that decides whether the customer can log in. Those are different problems, and only one of them is what people mean when they say the database has to be integrated.

Stacksync connects MariaDB to more than 1,000 systems on a single engine, in real time and in both directions, with change capture from the binary log, row-level write-back, no-code field mapping with Python transforms where you need them, and an audit trail on every write. Start with the MariaDB connector, the pair pages for MariaDB and Salesforce and HubSpot and MariaDB, or the two guides that go with this one: how to sync MariaDB with Salesforce and two-way sync between MariaDB and HubSpot. To see it running against your own schema, book a demo.