Most managed hosting plans ship a database (MySQL/MariaDB or Postgres, depending on the stack) with sensible-but-generic default indexing on the tables their own control panel or CMS installer creates. What they don't do is index the tables and columns your application actually queries — that's on you. We tested default index behavior across our regular managed-hosting test pool and found a consistent, avoidable pattern: sites hitting slow-query thresholds not because of host-level limits, but because nobody added the indexes their query patterns actually need.
What “Default Indexing” Actually Covers
When a host auto-installs WordPress, WooCommerce, or a similar CMS, the installer's own schema comes with the primary keys and a handful of standard indexes the software's developers included (e.g., WordPress's default indexes on `wp_posts.post_status`, `wp_postmeta.meta_key`). What it does not include is any index tailored to your site's specific query load — a custom plugin's meta lookups, a WooCommerce store with heavy filtered product queries, or any custom table your theme or plugin creates without its own indexing.
The Most Common Missing Index We Found
Across our test sites running WooCommerce or similar product-catalog structures, the single most common slow-query culprit was unindexed `postmeta`-style key-value lookups on custom meta fields (price ranges, custom attributes, stock status filters) — WordPress's own default `meta_key` index helps, but compound lookups filtering on multiple meta conditions at once routinely fell back to a full table scan without additional composite indexes. This is a WordPress/WooCommerce-specific pattern, but the general lesson — default indexes cover the platform's own core queries, not your customizations — holds across CMS platforms.
How to Check If This Affects You
Enable the slow query log (available via most hosts' database panel, or directly via `SET GLOBAL slow_query_log = ‘ON'` if you have that access level) and look for repeated queries exceeding your host's threshold — commonly 1-2 seconds by default, though this is configurable on plans with direct database access. Run `EXPLAIN` on the flagged queries; a `type: ALL` (full table scan) on a table with more than a few thousand rows is the clearest signal a missing index is the problem, not raw server capacity.
What You Can (and Can't) Fix Yourself
| Access level | What you can typically do |
|---|---|
| Shared hosting, control-panel only | Usually nothing directly — request the host add a specific index via support, or move to a plan with database access |
| Managed hosting with phpMyAdmin/database panel | Add indexes yourself via the panel's index editor, or run `ALTER TABLE … ADD INDEX` if SQL access is exposed |
| VPS/dedicated with full database access | Full control — add composite indexes, analyze query plans, adjust index cardinality |
Adding an Index Without Breaking Things
Adding an index is generally safe and non-destructive (it doesn't change data, only how it's looked up), but on a large table it can briefly lock the table during creation on older MySQL/MariaDB versions — test on a staging copy first if your host offers one, and add indexes during low-traffic windows on production if you don't have a staging environment. Over-indexing has a real cost too: every additional index slows down writes (inserts/updates), so add indexes for queries you've actually confirmed are slow, not preemptively for every column you might someday filter on.
What We Tested and Found
We ran identical WooCommerce-style catalog query patterns (filtered by price range + custom attribute + stock status) against default-indexed vs. properly-indexed versions of the same schema on comparable hosting plans. The properly-indexed version returned results in a small fraction of the time of the default-indexed version once the product table passed a few thousand rows — the gap widens as table size grows, since a full table scan's cost scales with row count while an indexed lookup's cost barely does.
FAQ
Will my host add missing indexes for me if I ask?
Some managed-hosting support teams will on request, especially if you can point to a specific slow query from the log; others will direct you to self-service tools or a higher plan tier with direct database access. Policy varies by provider — ask before assuming either way.
Does upgrading my hosting plan fix missing-index slow queries?
No — a bigger plan gives you more raw CPU/RAM to brute-force through a full table scan faster, but it doesn't fix the underlying scan. A properly placed index on a small plan will usually outperform a full table scan on a much larger plan for the same query.
How do I know which columns to index?
Start from your slow query log and `EXPLAIN` output rather than guessing — index the columns that appear in `WHERE`, `JOIN`, and `ORDER BY` clauses of queries you've confirmed are actually slow.
Bottom Line
Default database indexing on managed hosting covers the platform's own core schema, not your site's specific query patterns — that gap is the most common avoidable cause of slow queries we see in testing, and it's frequently mistaken for a hosting-capacity problem when it's actually a missing-index problem. Check your slow query log before upgrading a plan to fix a performance issue; an index fix is usually cheaper and more effective than a bigger server.
