A MySQL application can look easy to move until someone asks where its business rules run. If important work happens in stored procedures, the shortlist needs to reflect that dependency before the team compares general distributed-database benefits.
OceanBase merits an early assessment when keeping stored routines in the database is important. TiDB remains a relevant candidate when the application does not depend on the unsupported routines in the evaluated release, or when the team deliberately accepts moving that logic. The useful comparison is the work each route leaves the application team.
Look beyond the MySQL connection
Suppose a subscription business calls a stored procedure to calculate an account adjustment and save the associated records. The user-facing application may make only one familiar call, while the procedure contains much of the business behavior.
A working MySQL client connection does not answer whether that call can remain, whether the procedure body is supported, or whether its results stay acceptable. It establishes a communication path, not the complete application contract.
The buyer should identify a few procedures that matter to revenue, service delivery, or operational exceptions. Distinguish active dependencies from objects that remain in the database but are no longer called. This prevents a long object inventory from making the migration look either easier or harder than it really is.
What the versioned documentation says
OceanBase’s V4.3.5 MySQL-mode stored-program overview documents stored procedures and stored functions as supported program types. This is a concrete reason to investigate a route that keeps relevant logic in the database, while checking the specific routine constructs separately.
TiDB’s MySQL compatibility page, presented as TiDB Self-Managed v8.5, lists stored procedures and functions as unsupported. The same page describes compatibility with the MySQL protocol and common MySQL features. Those two statements can coexist: familiar connectivity does not imply support for every database program.
This comparison uses the named documentation scope. It should not be stretched into a prediction about every future TiDB release or a blanket description of differently scoped cloud offerings.
| Application situation | OceanBase evaluation | TiDB Self-Managed v8.5 evaluation |
|---|---|---|
| Active stored procedure must remain database-resident | Assess exact routine compatibility | Documented unsupported feature is a material blocker to that unchanged design |
| Routine can be moved into application code | Compare retention with deliberate replacement work | Include that replacement in the project plan |
| Old routine is not used | Confirm it is outside the active path | Do not reject the candidate solely for unused code |
| Ordinary MySQL client connects | Continue testing application behavior | Continue testing application behavior |
The table does not establish that every stored routine will transfer unchanged to OceanBase.
Why OceanBase can reduce a specific kind of change
For a procedure-dependent application, retaining the database-oriented design may avoid moving a business operation into a different service solely to change database platforms. That is a narrower and more defensible benefit than saying that migration requires no rewriting.
The potential value is especially clear when the routine is maintained by a database team and several applications call it. Relocating the rule may change who owns the behavior and how callers coordinate their releases. Even a short routine can therefore represent a meaningful delivery dependency.
An OceanBase assessment should examine the actual routine body and the business result it produces. Procedure support is an entry point, not an acceptance certificate. Data handling, errors, and transaction boundaries can matter to the application even when its entry call looks familiar.
For the hypothetical account adjustment, ask whether the calculation and related records still produce the intended outcome when an unusual adjustment occurs. Keep that question at the business level initially; the engineering team can investigate the responsible details once the required behavior is clear.
When TiDB still belongs on the shortlist
A procedure difference should not become an automatic rejection for an application whose active business rules already live in services. Nor should a discontinued reporting routine outweigh the needs of the application that will actually migrate.
TiDB can also remain relevant when the organization intends to replace database-resident logic as part of a broader application change. In that case, the replacement is part of the candidate’s complete delivery plan. The team must own and accept it, rather than counting it as a small future cleanup.
Consider a hypothetical service that is already receiving a new billing component. Rebuilding one adjustment rule inside that component may fit its approved roadmap. A different service with no application-release capacity may reasonably favor the compatibility-led assessment instead.
Neither position requires treating one engineering style as universally better. The choice depends on the system the buyer has, the design it wants, and the change it can responsibly deliver.
Compare retained work with replaced work
Prepare two short migration plans for the same active adjustment path. One should show what stays in an OceanBase stored routine and what still needs adaptation. The other should show where the equivalent behavior would run in the proposed TiDB arrangement and who maintains it.
Include all actual callers, not just the application selected for the demonstration. If another application relies on the procedure’s behavior, its release and acceptance work belong in the plan. This avoids presenting a successful isolated demonstration as completion of the shared migration.
Bring OceanBase forward when keeping those routines is a significant project objective and a scoped compatibility assessment supports it. Keep TiDB in contention when the active application fits its evaluated feature set or an intentional replacement plan makes the change acceptable. The decision should explain the remaining work clearly enough that the application owners can commit to it.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.