Why is Open Dental running slow?
Open Dental is a MySQL/MariaDB application: every workstation talks to a shared database server. So when Open Dental feels slow, the cause is almost always one of three things - the database server's resources or disk, the local network path to it, or the A-to-Z images folder sitting on a slow share - plus two quieter culprits, an under-tuned MySQL configuration and antivirus scanning the database files. It is almost never "the internet." Two quick questions narrow it down fast.
First: everywhere or one machine? Slow charting or slow images?
Two splits do most of the diagnostic work. If every workstation is slow, the cause is shared - the MySQL server, its disk, or the network to it; if only one machine is slow, the cause is local to it. And if charting is fine but images crawl, the problem is the A-to-Z images folder, not the database. Answer those two before changing anything.
The most common causes of Open Dental slowness
1. Confirm where the MySQL server actually runs
As with any shared-database app, a common finding is "the MySQL/MariaDB server is running on a workstation someone also uses for clinical work." That machine is now context-switching between charting and serving database queries to every other operatory. Moving the database role to a dedicated machine - even a small mini PC with an SSD and enough RAM - resolves a large share of the multi-user slowness we see.
2. Look at disk and RAM on the server, not the workstation CPU
Staff blame "the computer," but the constraint is usually the database server's disk and memory. A spinning hard drive serving MySQL to several operatories is the canonical bottleneck; an SSD changes the subjective experience immediately. RAM matters too, because MySQL caches the working set in memory (see MySQL tuning below).
3. Look at the local network path, not "the internet"
Open Dental between operatories needs local bandwidth and low latency, not internet speed. A tired 100-megabit switch where a gigabit one belongs, or operatory machines on Wi-Fi that should be on Ethernet, produces exactly the "slow with multiple users" symptom. Wired, gigabit, and a healthy switch are the baseline.
4. Tune the MySQL/MariaDB configuration
A default MySQL install is not tuned for a busy practice database. For InnoDB tables, an
undersized innodb_buffer_pool_size is the classic problem: the database cannot keep
enough in memory and hits disk constantly. Open Dental documents recommended MySQL settings -
apply them on a server with adequate RAM, and this is frequently the single biggest improvement.
5. Confirm antivirus exclusions for MySQL and Open Dental
Generic antivirus scanning every read and write to the MySQL data directory and the Open Dental program/image folders can cut database performance sharply and occasionally lock files. Exclude the MySQL data directory and the Open Dental folders on both the server and the workstations. Missing exclusions are a frequent, avoidable cause of both slowness and errors.
6. Check the A-to-Z images folder and where it lives
If images are the slow part, look at the A-to-Z images folder. When it lives on a slow disk, a saturated network share, or a remote location reached over a thin link, opening an imaging exam will crawl while charting stays fast. Put the images folder on fast, local, well-connected storage, and confirm the path is consistent across workstations.
7. Database maintenance and version
Running an old Open Dental version, or skipping routine database maintenance, can leave performance degraded as the database grows. Keep Open Dental reasonably current, let its updates apply the schema changes they ship, and if the database has grown very large, have a dental-fluent technician review it. If you ever see integrity or corruption warnings, stop and get a verified backup before anything else. (Related: do my dental backups actually work?)
8. Set the server's Windows power profile to High performance
If the database server is on "Balanced" or "Power saver," it throttles down during quiet spells and then has to spin back up when an operatory hits it. "High performance" is the right setting for a machine serving a clinical database.
MySQL connection errors and timeouts
The fan-out symptom "Open Dental can't connect to MySQL" is usually one of three things: the MySQL/MariaDB service is not running (often after a reboot or update), the workstation cannot reach the server on the database port (3306 by default), or antivirus/firewall is blocking that port. Confirm the service, then the network path and port, then the firewall - in that order - before reinstalling anything.
Self-hosted vs Open Dental Cloud
The checks above assume a self-hosted MySQL database on your own network, which is the common setup. If you run Open Dental's hosted/cloud option instead, slowness shifts to your local internet connection and the remote-session or browser layer rather than your own server and switch - a different diagnostic path worth naming so you investigate the right side.
What an autonomous RMM does about Open Dental slowness
On the CyberCore early-access cohort, the agent watches the signals behind these checks: whether the MySQL/MariaDB service is running, whether the database role sits on a workstation, whether the server's disk is the bottleneck, whether antivirus exclusions are applied, and whether the network path to the database is healthy. The well-understood cases - a stopped database service, a missing exclusion - surface (and, inside the owner-authorized allowlist, can be remediated) in seconds, with every action logged. The owner sees the cause, not just "Open Dental is slow again." (See Glass-box RMM and What is a Dental RMM?.)