Relevanssi hosting sized for the index, not just the posts.
Relevanssi builds its own index inside MySQL, and on a content-heavy site that index is routinely larger than every post you have written. The database has to be configured for it.
Everything a database-backed index asks of a host.
Relevanssi does not call out to a search service. Every query and every rebuild happens in your database, which makes this a MySQL tuning problem.
An index that fits in memory
The InnoDB buffer pool is sized to hold the Relevanssi index alongside the rest of the working set, so a search reads from memory rather than pulling index pages off disk one query at a time.
Rebuilds that finish
A full reindex on a large site will outlast any browser request. Ours run from WP-CLI with the execution ceiling raised, so the job completes instead of dying halfway and leaving a partial index.
Search pages stay dynamic
Result pages are per-query and often per-user, so they are kept out of the page cache. The expensive lookups behind them are cached in Redis instead, which is where the repetition actually is.
Room for long documents
Indexing long posts, custom fields and attachment text means writing large rows. Packet and row limits are raised so those writes succeed rather than failing silently mid-index.
Backups that know the index is rebuildable
Content is backed up nightly and replicated off the origin. The index can be regenerated from it, so a restore does not depend on having captured a consistent copy of a table that changes constantly.
Know the index is current.
A stale search index is invisible until somebody searches for the post you published this morning and finds nothing. These are the things worth watching.
- One-click admin login, no shared passwords
- Index size tracked against the buffer pool
- Plugin and core updates with per-item status
- Restore any daily backup from the dashboard
Search that answers before they retype it.
Relevanssi queries cannot be cached at the page level, so their speed is decided entirely by whether the index is in memory when the query arrives.
What we change for Relevanssi
These differ from a standard WordPress site on the same plan, and every one of them exists because the search index lives in your database rather than in a separate service.
| Setting | What we do | Why |
|---|---|---|
| InnoDB buffer pool | Sized to hold the Relevanssi index in addition to the normal working set | The index on a content-heavy site frequently exceeds the size of the posts table itself, and once it no longer fits in memory every search starts reading index pages from disk instead of RAM. |
| max_allowed_packet | Raised well above the default for index writes | Indexing long posts together with custom fields and attachment content produces single statements far larger than a default MySQL install accepts, and the rejection surfaces as content that is simply never findable. |
| Index rebuilds | Run through WP-CLI with the execution ceiling lifted, never from an admin page request | A full reindex on a large archive runs for many minutes, so triggering it from the browser means a request that dies partway and leaves the index containing some of the site and none of the rest. |
| Search result pages | Excluded from the page cache; the underlying lookups cached in Redis | Every result page is specific to one query string and often to one user's permissions, so caching the page is pointless while caching the query behind it removes the repeated work. |
| Index growth monitoring | Index table size tracked and alerted against the configured pool | The index grows with the archive rather than with traffic, so a site that has been fast for a year degrades gradually with no change in visitors and nothing in the traffic graph to explain it. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why is my Relevanssi search slower than it used to be?
How long does a full reindex take?
Should I use Relevanssi or ElasticPress?
Can search result pages be cached?
Do my backups include the search index?
Run Relevanssi with a database that fits the index.
Free migration, a buffer pool sized for your archive, and rebuilds that complete.