ClickHouse and MySQL integration

How ClickHouse connects to MySQL for live queries and writes

A team that needs MySQL operational data inside ClickHouse analytics has two live options: the MySQL table engine, which maps a single remote MySQL table into ClickHouse, and the MySQL database engine, which exposes a remote MySQL database as a ClickHouse database. Both run SELECT and INSERT queries against the remote server, and the table engine can also rewrite INSERT as REPLACE INTO through replace_query=1 or append an ON DUPLICATE KEY clause. This page explains how to configure, secure and test those connections safely. It covers self-managed deployments only, because the MySQL database engine is not supported in ClickHouse Cloud.

The first decision is which engine fits the workload. The table engine is narrower and easier to reason about: each mapped table is one explicit contract with one MySQL table, so schema drift is visible at the table level. The database engine maps every table in a schema, which is convenient for exploration but means a MySQL schema change can surface unexpectedly in ClickHouse. Before either one reaches production, confirm the MySQL server version, the account privileges, and the exact type mapping for every column you read. The ClickHouse MySQL table engine reference lists the connection parameters and the write options you should check against your own schema.

Writes deserve the most caution. REPLACE and ON DUPLICATE KEY behavior depends on the unique keys defined in MySQL, not on anything ClickHouse enforces, so a write that looks idempotent can overwrite rows you did not intend to change if a key is missing or wrong. Use a dedicated MySQL account with the narrowest grants for the target tables, keep TLS for the connection through a named collection, and test each write path against a copy of the MySQL schema with representative rows before enabling it. Plan a rollback for any table that accepts writes from ClickHouse, and record which team owns the MySQL side of the contract.

What you need before connecting ClickHouse to MySQL

Four decisions and one confirmation come before any table engine is created. Each card below is a prerequisite that the MySQL table engine and MySQL database engine depend on, and each one is easier to settle now than after queries start failing in production.

A supported ClickHouse version

Pick the self-managed ClickHouse release first, because it sets the MySQL features and the security support window you inherit. The security policy lists versions 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and all other versions as unsupported. Choose between the latest stable line and an LTS line, and read the changelog for the release you pick. Confirm the exact MySQL versions that release supports in the ClickHouse MySQL engine docs before you pin anything.

The MySQL edition and release track

Decide between MySQL Community Edition and MySQL Enterprise Edition, and choose an LTS or Innovation track. Community Edition is free under the GPL and includes replication and Group Replication, but it has no hot backup or Transparent Data Encryption, which Enterprise adds. An Innovation release is supported only until the next Innovation release, so most production MySQL servers are better matched to an LTS line. Check the version on the server against the ClickHouse docs, not only against the newest release.

Network paths and firewall rules

ClickHouse connects to MySQL over the MySQL protocol, so the ClickHouse server, not the client, must reach the MySQL port. Map every ClickHouse node that will run these queries, including each replica, and open only that source address to the MySQL listener. If you use TLS, confirm that the certificate name matches the host name ClickHouse connects to. Test the path from each ClickHouse host with the MySQL client binary before creating any table, because a failed engine creation message can be vague.

A least-privilege MySQL account

Create a dedicated MySQL account for ClickHouse rather than reusing an application or administrator login. Grant SELECT on the specific tables that queries will read, and grant INSERT only on tables that ClickHouse must write, because the REPLACE and ON DUPLICATE KEY options need write rights. Avoid granting privileges on all databases. Record the account name and the grant statements in your change record so that a reviewer can see exactly what ClickHouse can change.

TLS certificate material

Gather the CA certificate, and the client certificate and key if MySQL requires mutual TLS, before you write any configuration. The MySQL database engine accepts the ssl_ca, ssl_cert and ssl_key file paths only inside a named collection defined in the server configuration, so these files must be present on every ClickHouse node with correct ownership and permissions. Plan certificate renewal and rotation as part of the same change, because a rotated certificate on the MySQL side will break every engine that depends on the old one.

Confirmed version compatibility

Before you build, confirm in the official ClickHouse documentation which MySQL versions the chosen ClickHouse release supports for the MySQL table engine and database engine. Record the answer alongside the ClickHouse and MySQL versions you have actually tested, since the docs and your own environment can differ. Treat any version not listed in the docs as untested, and plan a pre-production test with representative tables and queries before anything reaches production.

Configuring the MySQL table engine and database engine step by step

This sequence takes a ClickHouse cluster from a dedicated MySQL account and encrypted connection to a tested table engine and an attached database, with a check at each stage so that problems surface on a test table before any production data is involved.

Create a dedicated MySQL account with least privilege
The MySQL administrator creates a separate account for ClickHouse, scoped to the specific databases and tables it needs, and does not reuse an application or administrator login. Grant only the privileges the chosen pattern requires: SELECT for read-only access, and INSERT or UPDATE only on the test table when writes are planned. Restrict the account to the ClickHouse server's network address. The step is done when a login from the ClickHouse host succeeds and a query against a forbidden table is refused, which confirms the grants behave as written.
Confirm TLS material and the MySQL endpoint
The team confirms that MySQL accepts encrypted connections and collects the CA certificate, and the client certificate and key if the server requires client authentication. Store these files on the ClickHouse hosts with ownership and permissions that let only the ClickHouse service read them. Verify the handshake from the ClickHouse host with the MySQL command-line client before touching ClickHouse configuration, since most failures at this stage are certificate paths, hostnames that do not match the certificate, or file permissions. The step is done when an encrypted session opens from the ClickHouse host using the same files you plan to reference.
Define the TLS named collection in server configuration
The ClickHouse administrator adds a named collection to the server configuration that holds the host, port, database, user, password and the TLS file paths ssl_ca, ssl_cert and ssl_key. The MySQL database engine accepts TLS file paths only through a named collection defined in server configuration, so this is the required location for them. Keep the password out of SQL statements and out of version control, and confirm the server configuration file permissions match your secrets policy. The step is done when the server restarts or reloads cleanly and a query that references the collection name returns the expected MySQL server version, which confirms the collection is readable.
Create a test table with the MySQL table engine
On a non-production MySQL table with a known primary key, the ClickHouse administrator creates a table using the MySQL table engine that points to the named collection and the test table. Declare column types that match the MySQL definitions and mark columns that can hold NULL as Nullable, so reads do not fail or silently coerce values. Run a SELECT count on the ClickHouse table and the same count directly in MySQL. The step is done when both counts match and a sample of rows with dates, decimals and nullable columns returns the same values from both sides.
Test writes and enable replace or upsert options only where needed
Run a small INSERT through the test table and confirm the row appears in MySQL with the expected values. Only if the workflow must overwrite existing rows, set replace_query=1 so inserts become REPLACE INTO, or add an ON DUPLICATE KEY clause for upserts. Test each option against a duplicate key in the test table, and record exactly what the MySQL table holds afterward, because the two behaviors differ on which columns are kept and on how auto-increment values change. Plain INSERT is the safer default when duplicates should be an error. The step is done when a duplicate-key test produces the outcome your data design requires, documented in the change record.
Attach a MySQL database with the database engine
Only after the table engine behaves correctly, the ClickHouse administrator attaches a whole remote MySQL database with the MySQL database engine, referencing the same named collection. Check that the engine is supported on your deployment, because the MySQL database engine is not supported in ClickHouse Cloud, and confirm the database engine can see the tables and column types you expect. Restrict which ClickHouse users can read or write through the attached database, since it exposes every table in the source database. The step is done when SHOW TABLES from the attached database lists the expected MySQL tables and a SELECT count on one of them matches MySQL.
Verify connection recovery and record the configuration
Simulate a brief interruption by restarting the test MySQL service or blocking the connection for a short window, then rerun the SELECT count and a test query to confirm ClickHouse reconnects without manual changes. Capture the final table and database definitions, the named collection name, the MySQL account's grants and the TLS file locations in your runbook, without the secret values. Ask the MySQL team to confirm their side of the account and certificate rotation process. The step is done when the post-interruption counts match and the runbook lists who owns the account, certificates and rollback steps.

Table engine or database engine: which one fits your query pattern

The MySQL table engine maps a single remote MySQL table to a ClickHouse table that you define yourself, with explicit column names and types. Queries against it run SELECT statements on the MySQL server, and INSERT statements write back to it, so ClickHouse does not store a copy of the rows. This suits a focused query pattern, such as joining a handful of reference tables from an operational database into a ClickHouse report. Because you declare the columns, the ClickHouse side stays stable even when someone adds a column to the MySQL table, and you control exactly which fields reach analysts.

Explicit column definitions: You write each column and its ClickHouse type, so type casting happens in one place that your team reviews.
Schema drift stays contained: A column added upstream does not appear until you change the table definition, but a dropped or renamed column breaks queries that reference it.
Write behavior per table: Inserts can be turned into REPLACE INTO with the replace_query setting, or given an ON DUPLICATE KEY clause, so each table declares its own conflict rule.
Predictable blast radius: A misconfigured table affects only the queries that touch it, which makes testing against a staging MySQL server straightforward.
Many tables means many definitions: Each table needs its own statement, so a large number of tables adds maintenance work that grows with the count.

Before you rely on this engine, confirm the supported data types, the pushdown behavior and the write options in the official engine documentation for your ClickHouse version.

How MySQL column types map to ClickHouse types

This table lists common MySQL column types and the ClickHouse types you would typically choose for each, along with the Nullable and casting questions to settle. Use it as a checklist for a test table, not as a list of guaranteed conversions. The main takeaway is that every mapping, especially for DECIMAL, temporal and JSON columns, should be confirmed against the engine documentation on your ClickHouse version.

MySQL type	ClickHouse type to choose	What to verify with a test table
Integer widths (TINYINT to BIGINT, signed and unsigned)	Matching signed or unsigned integer type sized to the MySQL range	Unsigned MySQL values above the signed range, and boundary values at each width
DECIMAL(p,s)	Decimal type with precision and scale copied from the MySQL definition	Rounding, scale preservation and arithmetic results after the query returns
DATETIME	DateTime or DateTime64 with a chosen precision	Fractional seconds, zero dates and time zone handling on read
TIMESTAMP	DateTime or DateTime64, decided with the session time zone in mind	Conversion to UTC, behavior around daylight saving changes and the server time zone setting
VARCHAR and CHAR	String, or FixedString only where length is fixed and known	Multibyte characters, trailing spaces in CHAR columns and collation effects on comparisons
TEXT and BLOB variants	String, sized for the largest value you expect	Maximum value length, binary content and whether values need decoding downstream
JSON	String for raw storage, or a parsed type after you test the mapping	Key order, numeric precision inside the document and how invalid documents are handled
ENUM	String or Enum8/Enum16 with the value list fixed in the schema	How new enum members added in MySQL reach ClickHouse and whether unknown values fail the query
Nullable columns	Nullable(T) wrapper on each column that can hold NULL in MySQL	Default values and NULL semantics in filters, aggregates and joins, plus the storage cost of Nullable columns

How REPLACE and ON DUPLICATE KEY change write behavior

The MySQL table engine offers two ways to change what an INSERT does on the MySQL side. Setting replace_query to 1 makes the engine send REPLACE INTO instead of a plain insert, and the engine can also append an ON DUPLICATE KEY clause to the statement it sends. Both options are decided on the MySQL server, not in ClickHouse, so the outcome depends on the MySQL table's primary key and unique indexes. A row that collides with an existing key is either deleted and reinserted (REPLACE) or updated in place (ON DUPLICATE KEY). Neither behavior is what a ClickHouse user might expect from an append-only analytics table, so treat both as write semantics that belong to the MySQL schema.

Retries are where these options matter most. A plain INSERT that is retried after a timeout can create duplicate rows if the MySQL table has no unique key covering those columns. With a suitable unique index, a retried statement can become idempotent, because the second attempt overwrites or updates the same key instead of adding a row. The reverse is also true: a REPLACE removes the old row and inserts a new one, which fires delete triggers, resets columns that were not supplied, and can change auto-increment values. Confirm which columns the ClickHouse side sends, whether every target table has a unique key that matches the business identity of a row, and whether any MySQL triggers or foreign keys react to deletes.

Before enabling either option, confirm how it interacts with your MySQL transaction design. Check the isolation level and whether the application writes to the same rows at the same time, since a REPLACE can race with an update from another session. Ask your DBA to review the table definition, the binary log consumers, and any replication filters, because a REPLACE appears there as a delete followed by an insert. Then test a retry storm and a duplicate batch against a copy of the schema on a non-production server. Your team should own the final decision, and it should be written down with the MySQL schema it was tested against.

Securing the connection with TLS, named collections and least privilege

The MySQL table engine and MySQL database engine put a standing connection from your ClickHouse cluster into a production database, so the controls around that connection matter as much as the query syntax. The cards below cover where TLS files and credentials live, how the MySQL account is scoped, which network paths are open, and who may create tables that reach production data.

TLS paths live in a named collection

The MySQL database engine accepts the TLS file paths ssl_ca, ssl_cert and ssl_key only inside a named collection defined in the server configuration, not in a query. Keep the CA bundle and client certificate paths there so they are set by whoever administers the server, and confirm that the MySQL server actually enforces TLS for the account ClickHouse uses. Check the certificate expiry and the rotation procedure before the first production deployment.

Keep credentials out of query text

A password written directly into a CREATE TABLE ... ENGINE = MySQL(...) statement can end up in query logs, the query history in system tables and client tooling. Store the MySQL user and password in a named collection and reference that collection by name. Then review the server's query log settings and any log masking you apply, and confirm that analysts cannot read the collection definition through their own accounts.

Scope the MySQL account to needed tables

Create a dedicated MySQL account for ClickHouse and grant only the privileges each table needs, usually SELECT on named tables and INSERT only where writes are required. Avoid reusing an application account with broad write rights. The MySQL side is where the hard limit sits, because a ClickHouse user that can create a table can still only reach what the MySQL account allows.

Use ClickHouse roles and row policies

ClickHouse access control covers users, roles, row policies, settings profiles and quotas. Grant users access to MySQL-backed tables through roles, so the permission is reviewed in one place, and restrict the built-in default user, which starts with all permissions. Confirm which ClickHouse accounts may read the table engine output, since a readable MySQL-backed table exposes whatever the MySQL account can see.

Allowlist the network path

Limit the connection from ClickHouse nodes to the MySQL server's listening port with firewall rules or security groups that allow only the ClickHouse hosts. Route the traffic over the private network, not a public address, and confirm that the MySQL server's bind address and host-based account rules match that path. Re-check the allowlist after any node is added, replaced or moved to another subnet.

Review who can create MySQL-backed tables

A table created with the MySQL engine opens a connection to whatever host and database it names, so anyone who can run CREATE TABLE or CREATE DATABASE can point ClickHouse at production MySQL. Limit those grants to a small administrative group, review them on a schedule, and ask which accounts currently hold them. Confirm your change process records each new external table and its owner.

Common MySQL integration failures and how to fix them

This table pairs each common failure when ClickHouse reads or writes MySQL with its likely cause and the fix to try first. Use it as a triage list during a pilot, then confirm each fix against your own MySQL version, certificates and table definitions.

Failure	Likely cause	Fix
TLS handshake errors	The ssl_ca, ssl_cert or ssl_key path in the named collection points to a missing file, a file the ClickHouse service account cannot read, or a certificate that does not match the MySQL server.	Define the paths in the server-side named collection, confirm file ownership and permissions for the ClickHouse process, and check the CA chain against the certificate MySQL presents. Remember that the database engine reads TLS settings only from the named collection.
NULL values fail on non-Nullable columns	The MySQL column allows NULL, but the ClickHouse column was declared without Nullable, so the engine cannot place the value.	Declare the ClickHouse column as Nullable(T) where the MySQL column is nullable, or coalesce NULLs in a view or materialized view before they reach a MergeTree table. Decide per column, and document which choice you made.
Type mismatches after a MySQL schema change	A column was widened, renamed, dropped or changed type on the MySQL side, so the ClickHouse table definition no longer matches what the server returns.	Compare both definitions after every MySQL migration, recreate the ClickHouse table or column with the new type, and run a test SELECT before resuming writes. Put schema changes on the MySQL side into the same change process as ClickHouse changes.
Unexpected duplicates after writes	Retries or replayed batches inserted the same rows again because the write used plain INSERT, and the MySQL table has no conflict handling for the key.	Use the replace_query setting so INSERT becomes REPLACE INTO, or add an ON DUPLICATE KEY clause, and confirm the MySQL table has a primary or unique key that defines a duplicate. Test a replayed batch on a copy before enabling it in production.
Connection limits on the MySQL server	Many ClickHouse queries or parallel reads open sessions at once, and the server reaches its configured maximum number of connections.	Limit concurrent queries from ClickHouse, cap connections at the MySQL server for the ClickHouse account, and ask your MySQL administrator to confirm the server limit. Move heavy reads to a copy of the data if live queries compete with production traffic.
Queries that scan full MySQL tables	Filters are not pushed down to MySQL, often because of function calls, type conversions or a condition the engine cannot translate, so the whole table is read across the network.	Check the query plan with EXPLAIN, rewrite filters into simple comparisons on indexed MySQL columns, and keep filter types aligned with the MySQL column types. For repeated analytics, copy the data into a MergeTree table on a schedule instead of querying MySQL live.
Named collection not found on the server	The named collection for the database engine or TLS settings was defined in a session or a different server node, not in the server configuration that the engine reads.	Define the named collection in the server configuration on every node that runs the query, then restart or reload according to your ClickHouse version's behavior. Confirm the definition on each replica before testing.

When copying MySQL data into MergeTree beats live querying

Live querying suits occasional lookups, but heavy analytics usually belongs in a copied MergeTree table. Every query made through the MySQL table engine or database engine runs against the MySQL server, so a dashboard that refreshes often or a wide aggregation over years of rows adds load to a system that also serves your application. The query also fails whenever that server, the network path or its credentials are unavailable. Copying the data into a ClickHouse MergeTree table moves the analytical load onto your ClickHouse cluster, lets you set retention with TTL rules, and places the copy under ClickHouse replication and backup, which a live query does not give you.

Decide with four factors: how often the query runs, how many rows it scans, how fresh the answer must be, and how much headroom the MySQL primary or replica has. Frequent or large scans against a production MySQL instance are the strongest signal to copy. Freshness requirements decide the refresh method, since a periodic full or incremental load gives a known lag that you must document for analysts. Ask your MySQL team what replica capacity they can give analytics and whether a read replica is available, because pointing ad hoc analytics at a primary is a common source of production incidents.

Test both paths before choosing. Run the same representative queries through the live engine and against a loaded MergeTree copy, then compare response time, MySQL server CPU and connection use, and whether results match, including NULL handling and type casts. Confirm the refresh job's failure behavior and how long a reload takes at your data volume. Live querying can remain the right choice for small reference tables or for data that must not be duplicated, but the copy is usually the better fit for analytics that run repeatedly.

Questions teams ask before connecting ClickHouse to MySQL

Does the ClickHouse MySQL integration work in ClickHouse Cloud?

The MySQL database engine is not supported in ClickHouse Cloud, so a database-level link to MySQL requires self-managed ClickHouse. The engine connects to databases on a remote MySQL server and exchanges data with INSERT and SELECT. Its TLS file settings are accepted only through a named collection defined in the server configuration, and that configuration lives on the servers you run. The MySQL table engine is documented separately, so confirm its current status in Cloud in the ClickHouse documentation before you finalize the design. For a self-hosted cluster, the rest of this page applies directly.

What drives the effort in a MySQL integration?

Four factors drive most of the effort: the number of schemas and tables to expose, the type mapping between MySQL and ClickHouse columns, the TLS setup, and the write semantics you need. A few tables with simple numeric and string columns is a short exercise. Many schemas with decimal, date, JSON, enum and nullable columns need a column-by-column review, and each mismatch becomes a test case. TLS adds certificate authority distribution, file paths in server configuration and rotation planning. Write semantics decide whether you use plain INSERT, REPLACE through replace_query, or an ON DUPLICATE KEY clause, and each choice changes how duplicates behave on the MySQL side. Ask any partner to break the quote into these four parts, with the tables in scope listed by name.

What does our team need to provide for the work?

Your team provides access and context, while the build is done by your internal team or a partner. Expect to provide a MySQL account with the privileges needed for the chosen read or write pattern, created and reviewed by a MySQL administrator. Network changes are needed so the ClickHouse nodes can reach the MySQL server on its port, which often involves firewall rules and routing approvals. Test data matters: a copy of representative tables in a non-production MySQL instance lets you validate type casting, NULL handling and write behavior before production. You also need a named owner for the MySQL schema who can say which columns change and how often. Agree these items in the written scope so they are not discovered during the build.

Can our own team build this without an outside partner?

Yes, a team that already runs ClickHouse and MySQL can build a basic table engine integration in-house, provided it has people comfortable with both systems. The skills that matter are ClickHouse table and materialized view design, MySQL privileges and schema knowledge, and TLS configuration on both ends. The work gets harder when the scope is broad, when write semantics must be exact, or when no one on the team owns the MySQL schema. Internal teams usually carry the on-call load for the result, so ask who will troubleshoot a broken connection at night. A fixed-scope engagement with DeployOpen covers planning, implementation, testing and documentation. The right choice depends on your team's capacity and the number of tables involved.

How long does a MySQL integration take to deliver?

Duration depends on scope, and no fixed timeline applies to every environment. A limited set of tables with straightforward types and TLS already configured is a much smaller job than a multi-schema estate with strict write rules, custom TLS trust chains and a staged rollout. The main time sinks are type reviews, network approvals and testing against representative data, which often wait on other teams. Ask for a timeline in the written scope that lists the schemas, the number of tables, the write pattern, the environments included and the dependencies you must clear. Treat any duration offered without that list as a rough guess that needs challenge. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

Should we query MySQL live or copy the data into ClickHouse?

Query live when the data is small, changes often and is read occasionally. Copy when analytical queries run repeatedly over large volumes. The MySQL table engine sends SELECT and INSERT traffic to the remote server, so every dashboard query adds load to the operational database. A copied MergeTree table keeps analytics off the source, supports ClickHouse compression and ordering keys, and lets you control retention. Copying needs a refresh method, a clear definition of which changes you capture, and reconciliation checks. Many teams keep live lookups for reference tables and copy event-style data. Decide per table, and document the choice with its owner, refresh pattern and expected freshness.

How do we configure TLS for the MySQL connection?

For the database engine, the documented approach is a named collection in the ClickHouse server configuration that holds the TLS file paths ssl_ca, ssl_cert and ssl_key, because those settings are accepted only there. Plan certificate issuance, file ownership and permissions on the ClickHouse hosts, and a rotation process before the first connection, since an expired certificate can break queries at a bad time. Confirm that your MySQL server requires or accepts TLS for these accounts, and test the handshake from every ClickHouse node, not just one. Store the configuration through your normal change process so the named collection is versioned. Verify the setup with a deliberate connection test in staging before go-live.

Does MySQL licensing affect this integration?

The ClickHouse server is licensed under the Apache License 2.0, and MySQL Community Edition is freely downloadable under the GPL license. The integration uses the standard MySQL connection, so the licensing choice that matters is which MySQL edition you run and whether you need its add-ons. MySQL Enterprise Edition adds features such as Enterprise Backup, Transparent Data Encryption and Enterprise Audit, plus 24x7 Oracle support. Pick the MySQL release track deliberately. The LTS line is supported under the Oracle Lifetime Support Policy, while the Innovation track is supported only until the next Innovation release. Confirm licensing terms for your deployment with your legal and procurement teams, since this page does not provide legal advice.

How DeployOpen scopes and delivers this integration

DeployOpen starts with a written scope, not with a connection string. Before any work begins, the scope, deliverables and timeline are agreed in writing. For this integration, that document should name each MySQL database and table the ClickHouse side will reach, whether access is live through the MySQL table engine or the MySQL database engine, or whether data is copied into MergeTree tables, and which write paths (plain INSERT, replace_query=1 or an ON DUPLICATE KEY clause) are in use. Because most engagements are fixed-scope, the written agreement is where the reader fixes the boundaries of the work, so changes to the table list or write behavior are raised as scope changes rather than absorbed silently. Ask for the scope document to state which ClickHouse and MySQL versions are in use and which MySQL edition and track applies, since those determine the behavior you will test.

The build happens in your environment. DeployOpen configures the integration on your ClickHouse servers and your MySQL instances, using your network paths, your accounts and your certificate authority. The MySQL database engine stores its TLS file paths (ssl_ca, ssl_cert, ssl_key) in a named collection defined in the server configuration, so that configuration, the read-only MySQL account and the ClickHouse users allowed to query the tables are all created and reviewed as part of delivery. Credentials and certificate files stay where your team controls them. Nothing is hosted by DeployOpen on your behalf unless the written scope says so.

Testing uses representative data that your team approves for this purpose, not synthetic rows alone. DeployOpen checks how each MySQL column type maps to ClickHouse types, how NULL values surface in Nullable columns, and how writes behave when keys collide, comparing the result with what MySQL holds afterward. Those results become the acceptance evidence for the integration. Once the integration is live, DeployOpen can continue with a retainer for ongoing support, upgrades of either side and re-testing after schema changes, if your team wants that cover. Whether a retainer is needed, and its terms, is a separate written decision that you can make after delivery.