Shared Hosting Database Limits: MySQL Quotas Explained

Understanding Database Quotas in Shared Hosting

When you sign up for a shared hosting plan, the provider allocates a slice of a physical server to your account—along with dozens or even hundreds of other websites. One of the most commonly misunderstood constraints in this environment is the MySQL database quota. Every shared hosting plan comes with explicit limits on the number of databases you can create, the maximum size each database can reach, the number of concurrent connections permitted, and the frequency with which you can execute queries. These limits exist not as arbitrary restrictions but as essential guardrails that prevent any single account from degrading performance for every other tenant on the server.

A typical entry-level shared hosting plan might allow between 1 and 5 MySQL databases, each capped at 500 MB to 1 GB. Mid-tier and premium shared plans often expand this to 10–25 databases with per-database limits of 2–5 GB. Some hosts impose a cumulative database storage cap—say 10 GB across all databases—rather than per-database limits. Understanding which model your provider uses is critical because the operational impact differs dramatically between the two approaches.

At Hosting Captain, we have reviewed database quota structures across more than 40 shared hosting providers, and the variance is substantial. Budget hosts frequently advertise "unlimited databases" but conceal CPU and connection throttles in their Acceptable Use Policies that make the unlimited claim functionally meaningless. This article translates the fine print into actionable guidance so you can avoid database-related account suspensions, plan your growth, and know when it is time to move beyond shared hosting.

Why Hosts Impose MySQL Limits on Shared Plans

MySQL is a resource-intensive service. Every query consumes CPU cycles, reads from—and writes to—disk I/O, and occupies RAM for buffer pools, temporary tables, and sort operations. On a shared server where perhaps 200 cPanel accounts compete for the same physical resources, one poorly optimized database can starve everyone else. Hosts use quotas as a blunt but effective tool to contain the blast radius of a runaway query, a compromised WordPress plugin, or simply an account that has outgrown the shared tier.

Disk I/O is often the binding constraint. Traditional spinning-disk storage (HDD) delivers roughly 80–200 IOPS, whereas a single unindexed WordPress postmeta query can consume hundreds of IOPS in seconds. Even on NVMe-backed shared infrastructure, which is becoming more common, a single account running multiple large JOIN queries can saturate available throughput. Setting per-account database size limits caps the total amount of data that the MySQL daemon must scan for an individual tenant, protecting the broader server population.

Connection limits serve a similar purpose. MySQL allocates a thread and memory per connection. A shared server might configure max_connections at 500, distributed across all tenants. If a single account opens 50 persistent connections—easy to do with a misconfigured plugin or a traffic spike—those connections consume resources that other accounts need. Hence, many shared hosts restrict individual accounts to 15–30 concurrent MySQL connections.

Cumulative query execution time is another invisible throttle. Some providers, particularly those using CloudLinux with MySQL Governor, cap the total number of CPU seconds an account's queries can consume per hour. Exceed that cap, and the account is throttled or temporarily suspended. This is rarely disclosed prominently on pricing pages but appears in the Acceptable Use Policy under language like "excessive resource usage" or "database abuse."

Common Shared Hosting MySQL Limits by Plan Tier

Based on Hosting Captain's analysis of plan specifications from leading shared hosting providers in 2026, the following ranges represent typical database allowances:

Entry-Level Plans (US$2–5/month): These plans commonly permit 1–3 MySQL databases, each limited to 500 MB–1 GB. Concurrent connections are frequently capped at 10–15. These plans are suitable for a single small WordPress site, a personal blog, or a static business landing page with a lightweight contact form database on the side. If you run a WooCommerce store, a membership site, or anything that logs data aggressively, you will hit these limits within months.

Mid-Tier Plans (US$5–10/month): Most mid-tier plans allow 5–10 MySQL databases with individual caps of 1–3 GB. Concurrent connection limits typically rise to 20–25. This tier comfortably supports a medium-sized WordPress site with a staging database, plus perhaps a separate database for a forum, a CRM, or a learning management plugin. However, if your site stores large volumes of analytics data, revision histories, or user-generated content, you may still outgrow this tier.

Premium Shared Plans (US$10–20/month): Premium plans often boast "unlimited databases," but the per-database cap usually sits between 3 GB and 10 GB. Some providers switch to a cumulative cap at this tier (e.g., 25 GB total across all databases). Concurrent connections may reach 30–50. At this level, the constraint is rarely the database count or raw size—it is the CPU and I/O throttling that triggers hidden limits.

It is worth noting that a handful of performance-oriented shared hosts (using LiteSpeed, NVMe, and CloudLinux) offer comparatively generous database resources—sometimes up to 100 concurrent connections and 15 GB per database on their top shared plans. These hosts use aggressive resource isolation to make this feasible. Hosting Captain's shared hosting comparison tables highlight these outliers explicitly.

What Happens When You Exceed Your MySQL Limits

Exceeding your database quota does not always trigger an immediate account suspension, but the consequences are universally disruptive. The specific behavior depends on how your host enforces its limits—through cPanel quotas, CloudLinux LVE (Lightweight Virtual Environment) boundaries, or MySQL Governor policies.

Hard Suspension: Some budget providers configure cPanel database quotas as absolute caps. When a MySQL data directory crosses the threshold, the database engine refuses further INSERT and UPDATE operations. Your site suddenly throws "database error" messages to visitors. WordPress will display the dreaded "Error establishing a database connection" or fail silently on writes. If your site depends on database writes—session storage, order processing, form submissions—those functions break instantly.

Soft Throttling: More sophisticated hosts use CloudLinux MySQL Governor, which does not block operations outright but drastically limits query execution speed when an account exceeds its hourly CPU or I/O budget. Visitors experience slow page loads (10–30 seconds), timeouts, and intermittent 503 errors. Soft throttling is less catastrophic than a hard suspension but harder to diagnose because the symptoms mimic a traffic spike or underpowered hosting.

Automated Account Suspension: If the database issue also triggers broader CPU, memory, or I/O violations under the host's resource usage policy, the entire cPanel account may be suspended automatically. Suspension takes your website offline and often blocks access to phpMyAdmin, preventing you from running cleanup queries to resolve the issue. Recovery requires contacting support, which can take hours on budget hosts.

Support-Initiated Intervention: Some managed shared hosts proactively email account owners when database usage crosses 80% of the limit. This is the ideal scenario—it gives you time to optimize, archive old data, or upgrade before any service disruption occurs. Hosting Captain's recommended providers generally offer this proactive alerting.

How to Check Your Current Database Usage

Before you can optimize, you need visibility into your actual database consumption. Most shared hosting accounts provide three mechanisms:

cPanel's MySQL Databases Interface: Navigate to cPanel → MySQL Databases. The interface typically lists each database with its current disk size. Some hosts also display a usage bar or percentage. This is the most accessible method. If your host does not show database sizes here, they may expose this information through the "Disk Usage" tool or the "Resource Usage" dashboard within cPanel.

phpMyAdmin: Select your database in the left sidebar, then click the "Operations" tab. The "Data size" and "Index size" values show you where your storage is going. High index sizes often point to over-indexed tables—a common issue with plugin-heavy WordPress installations. phpMyAdmin also lets you sort tables by size, which is the fastest way to identify which tables are bloated.

CloudLinux Resource Usage Dashboard: If your host uses CloudLinux (most do), cPanel includes a "Resource Usage" or "CPU and Concurrent Connection Usage" section. This shows whether your account has been hitting MySQL Governor throttles. Look for "MySQL faults" or "database seconds" metrics. A consistently high "database seconds" number suggests your queries are disproportionately expensive relative to other accounts on the same server.

At Hosting Captain, we recommend checking these dashboards monthly—even if your site is running smoothly. Many slow-quietly failures begin weeks before a visible outage, and early intervention is far less painful than emergency cleanup under the pressure of a suspended account.

Optimizing Your Databases to Stay Under Limits

Most shared hosting database overages are avoidable with routine housekeeping. The following techniques are safe to execute on a live production site (perform a backup first) and can reduce database bloat by 30–70%.

Clean Up WordPress Revisions and Auto-Drafts: WordPress stores unlimited post revisions by default. A single blog post edited 30 times generates 30 revision rows—each a near-duplicate of the post content. Over years, revisions can account for 40–60% of your wp_posts table size. Run this SQL query via phpMyAdmin to purge revisions:

DELETE FROM wp_posts WHERE post_type = 'revision';

To cap future revisions, add define('WP_POST_REVISIONS', 3); to your wp-config.php file. Auto-drafts are another source of bloat—WordPress creates a draft every time the post editor is opened and often fails to clean them up. You can purge auto-drafts with:

DELETE FROM wp_posts WHERE post_status = 'auto-draft';

Delete Transient Cache Entries: WordPress plugins and themes store temporary data in the wp_options table as "transients." Expired transients are supposed to be garbage-collected automatically, but on sites with heavy plugin rosters, orphaned transients accumulate and bloat wp_options into the hundreds of megabytes. A simple query cleans these out:

DELETE FROM wp_options WHERE option_name LIKE '%_transient_%';

Alternatively, use a maintenance plugin like WP-Optimize or Advanced Database Cleaner, which provides a GUI for these operations and adds safety checks.

Optimize Table Overhead: MySQL tables accumulate "overhead"—fragmented space from deleted rows—that inflates their disk footprint without storing useful data. In phpMyAdmin, check all tables, select "Optimize table" from the dropdown, and execute. This rebuilds the table and reclaims wasted space. For WordPress installations, this can free 5–20% of storage.

Archive Old Log Data: Plugins like Wordfence, Redirection, and WooCommerce maintain activity logs, redirect logs, and order data that grow indefinitely. These tables can silently consume gigabytes. Configure log retention policies inside each plugin—Wordfence allows you to limit the "Days to keep audit log events," and Redirection lets you set a maximum log retention period. For WooCommerce, consider exporting orders older than two years to CSV and deleting them from the live database if they are no longer needed for operational reporting.

Disable Unused Plugins' Database Tables: Plugins often leave their tables behind after deactivation. Use phpMyAdmin to identify tables with names that do not match any active plugin, verify they are genuinely unused, and drop them. This is an advanced operation—back up first and double-check dependencies.

Indexing for Query Efficiency: While indexes consume additional disk space, they dramatically reduce the I/O and CPU cost of common queries, making it less likely that your account trips MySQL Governor throttles. Focus on columns used in WHERE, JOIN, and ORDER BY clauses. For WordPress, ensure the default indexes on wp_postmeta (meta_key) and wp_options (option_name) are present—some migrations strip them accidentally.

When to Upgrade Beyond Shared Hosting

Database optimization can buy you months, but it is not a permanent solution for growing websites. Certain signals indicate that your database needs have permanently outgrown the shared hosting tier, and continuing to optimize is only deferring an inevitable migration.

Chronic MySQL Governor Throttling: If your Resource Usage dashboard shows MySQL faults or throttled database seconds every single day—even after optimization—your query volume exceeds what the host considers acceptable for a shared account. Continuing under these conditions risks a sudden account suspension.

You Consistently Exceed 80% of Your Size Cap: A database that sits at 80%+ of its allocated size limit despite aggressive cleaning is likely supporting a site that generates too much data for the plan. This is common with membership sites, e-commerce stores with large product catalogs, forums, and content-heavy blogs with tens of thousands of posts.

You Need Features Shared Hosting Cannot Provide: Some database workloads require features that shared hosts deliberately disable for security and performance reasons—persistent connections, custom MySQL configurations, EVENT schedulers, triggers on MyISAM tables, or the ability to install specialized storage engines like InnoDB's FULLTEXT indexing with custom stopword lists. If your application requires any of these, you need at minimum a VPS.

Upgrade Paths: The logical next step is a managed VPS, where you receive guaranteed CPU cores, dedicated RAM, and complete control over your MySQL configuration. Most managed VPS plans at Hosting Captain's recommended providers start at US$20–30/month—often only slightly more than premium shared hosting—and lift all the resource artificial ceilings we have discussed. If high availability matters, look for providers that offer managed cloud VPS with automated database backups, replication, and failover support. For ultra-high-traffic e-commerce, a managed dedicated server or a cloud-based MySQL-compatible service (Amazon RDS, Google Cloud SQL) running alongside your hosting provides effectively unlimited database headroom.

Frequently Asked Questions