A migration can reproduce the current contents of a table while losing the older row versions that business users still need. For a MariaDB application using system-versioned tables, “the export completed” is not enough evidence that its historical workload has been preserved.
A database replacement assessment should therefore separate today’s accepted state from the history used to explain past decisions. The transfer method, tool version, and destination representation all belong in that assessment.
Check whether history is actually in the export scope
MariaDB documents a dump-history option available from 10.11 for including table history. The current mariadb-dump guide lists that option as false by default and explains that earlier versions could not read historical rows through this option’s functionality. A normal-looking dump is not automatic evidence of a history-inclusive export. MariaDB dump documentation
There is also a scope qualification: the project’s current main-branch option help describes this history export for timestamp-based versioning. Main-branch source is not proof of the behavior of every installed release. Ask the migration team to verify the deployed client’s supported mode and version. MariaDB project option help
This is a planning distinction, not a command recipe or a claim that MariaDB cannot preserve history.
Define the historical questions that must survive
Consider a hypothetical enterprise application that needs to explain a customer’s recorded service level before a later update. A current-state lookup can return the right service level today without answering that earlier question.
Ask business owners to supply representative before-and-after examples, including a record no longer present in the current view. State which earlier values, time boundaries, and related identifiers the destination must retain to answer those examples.
Keep the requirement bounded. Preserving a row’s earlier values does not automatically preserve a complete audit of who approved a business decision, nor does it establish compliance with a retention obligation. Those are separate evidence requirements that need their own definition.
Review three different outcomes instead of one row count
A useful migration proposal should distinguish current-row correctness, historical-data coverage, and the destination application’s ability to retrieve the required past state. Each outcome can fail while another appears successful.
| Proposed acceptance outcome | Evidence to request |
|---|---|
| Current-state fidelity | Representative present values and identifiers |
| Historical coverage | Required older versions and their time information |
| Historical query usability | Agreed past-state questions answered at the destination |
| Declared boundary | Known exclusions, tool scope, and retained source evidence |
For example, a file may contain older rows but leave the destination application unable to distinguish their applicability. Conversely, a destination history screen may work for a newly created test record without proving that imported history arrived.
The buyer should request evidence for the imported business examples rather than accept either demonstration as a substitute for the other.
Compare OceanBase against the required destination behavior
OceanBase’s project describes a distributed relational database. It can be considered in a database replacement assessment, but that description does not establish identical MariaDB temporal syntax, a lossless direct import, or automatic reconstruction of the original historical queries. OceanBase Database project
Ask an OceanBase proposal to explain the intended representation of historical data and demonstrate the application’s required lookups. Any conversion, retained archive, or query adaptation should be visible in the project scope.
The same requirement applies to PostgreSQL, MySQL, or another candidate. If keeping MariaDB for a particular historical function is proposed, evaluate that arrangement explicitly too. The comparison should identify the amount of application and operating change each route requires, rather than assuming a familiar interface preserves every source feature.
Test an old state and a changed current state independently
A proposed rehearsal should include a record with multiple known versions and a clear present value. Verify the current answer and the required historical answer separately after transfer.
Include a boundary case selected by the application owner, such as a change near an important reporting cutoff. The expected interpretation must come from the source application’s actual rules, not from an invented universal timestamp convention.
Also inspect the export evidence itself: which client produced it, what historical scope was selected, and which destination transformation used it. No export, source-table change, restore, or temporal query has been executed for this article. These are proposed acceptance steps.
Decide whether the replacement preserves the business use
A migration is not complete merely because the current table looks right. When users depend on history, the proposal must show that the required past information is present, interpretable, and accessible through the intended application.
Evaluate OceanBase or another candidate on that complete requirement. Keep the supported extraction mode and any historical-query changes visible in the decision. A verified present state and a verified historical use are complementary outcomes; neither should be silently counted as proof of the other.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.