Open Dental MariaDB 10.11: 2026 Upgrade Guide
Plan an Open Dental MariaDB 10.11 upgrade with database backups, storage, version requirements, services, test restores, integrations, and rollback preparation.
Open Dental's current documentation says its latest version uses MariaDB 10.11.10 and that its installer supports MariaDB 10.11. The vendor's Database Management System Upgrade Wizard requires Open Dental version 24.3 or greater and enough storage to create two full backups of the database data folder plus additional working space. Those details make one principle clear: a database-engine upgrade should be planned around backup validation, service coordination, storage, integrations, and a rollback path before the maintenance window begins.
Key Takeaways
Open Dental's current documentation uses MariaDB 10.11 and recommends vendor support for the DBMS upgrade process; verify the live vendor requirements again before scheduling a production change.
Create and validate backups before the database-engine upgrade and make sure there is enough local storage for the vendor's documented backup requirements.
Stop or coordinate services that access the database, test the application and integrations after the change, and keep a rollback/recovery decision point in the maintenance plan.
What does Open Dental currently document about MariaDB 10.11?
Open Dental's MariaDB documentation states that the current Open Dental version uses MariaDB 10.11.10 and that the vendor supports MariaDB 10.11 through its installer. Because vendor requirements change, verify the current documentation immediately before an upgrade rather than copying an old checklist indefinitely.
The same documentation says the DBMS Upgrade Wizard can upgrade supported older MySQL or MariaDB environments to MariaDB 10.11 and recommends contacting Open Dental Support for assistance.
What should be checked before the maintenance window?
Confirm the current Open Dental version, database engine and version, data path, available storage, backup destination, database size, server health, Windows services that access the database, third-party integrations, and administrative access.
Open Dental currently documents version 24.3 or greater as a requirement for its DBMS Upgrade Wizard and requires sufficient storage for two full backups of the database data folder plus additional space. Treat those as vendor requirements to verify again on the day the work is scoped.
Why should backup validation come before the upgrade?
A backup file existing is not enough. Verify that the database and image data needed for recovery are included, the destination is reachable, the backup completes without errors, and the team knows how it would restore if the upgrade fails.
Open Dental's built-in backup tool can create and restore backups and explicitly notes that restoring to another computer can be used to test whether backups are working. The vendor also says its supplemental backup feature is not a replacement for a full backup strategy.
Which services and integrations need coordination?
Open Dental's documented upgrade steps call for closing Open Dental on workstations and stopping Open Dental services plus third-party services that access the database. Identify those services before the outage window so the team is not discovering them while production is down.
Also map imaging bridges, reporting tools, eConnector functions, integrations, scheduled jobs, backup agents, and any custom process that reads from or writes to the database.
How should the upgraded environment be validated?
Validate database connectivity from representative workstations, patient search, scheduling, chart access, imaging bridges, printing, claims or clearinghouse workflows, eConnector functions, user permissions, backups, and any integration the practice depends on.
Record the new database version and update server documentation. If the change introduced performance or compatibility problems, use the pre-defined recovery decision point instead of making unlimited production changes under pressure.
What should a rollback plan contain?
Define the last known-good state, backup location, restoration steps, responsible technician, vendor escalation path, time limit for troubleshooting before rollback, and how staff will be told whether the office can reopen normally.
A rollback plan does not guarantee every database change is instantly reversible. It gives the team an agreed recovery path and prevents a failed maintenance window from turning into improvised recovery.
Sources and References
Primary sources used for this article
Regulations, product support information, and incident details can change. Review the linked primary sources for the latest status.
Current vendor documentation on MariaDB 10.11, supported upgrade paths, storage requirements, version requirements, and upgrade steps.
Current vendor documentation on backup, restore testing, supplemental backups, and alternate backup options.
Risk-management framework supporting controlled maintenance, recovery, and technology lifecycle decisions.
Common Questions
Frequently asked questions
What MariaDB version does Open Dental currently use?
Open Dental's current MariaDB documentation states that its latest version uses MariaDB 10.11.10. Verify the vendor page before production work because supported versions can change.
Does Open Dental recommend support for the MariaDB upgrade?
Yes. Its current documentation recommends contacting Open Dental Support for assistance with the DBMS upgrade.
Can the built-in Open Dental backup tool test a restore?
Open Dental documents that an existing backup can be restored to another computer to test that backups are working or when recovery is needed.
Is Open Dental supplemental backup enough by itself?
No. Open Dental explicitly says the supplemental backup feature is not designed to replace existing full backup methods.
Should third-party services be stopped during the upgrade?
Open Dental's documented upgrade steps call for stopping Open Dental services and third-party services that access the database. Identify those services in advance.
Should a practice upgrade MariaDB without checking integrations?
No. Database and software changes should be coordinated with the workflows and integrations the practice actually uses, then validated before normal operations resume.