ElasticPress hosting for search that left the database.
Once search runs against an external index, your results are a copy of your content. Copies drift, and a drifted search index is wrong without ever looking broken.
Two copies of the truth.
Moving search out of MySQL fixes the performance problem and introduces a synchronisation problem in its place.
Reindexing that reaches the last document
A full reindex pushes every post, term and meta field to the index. It runs as a resumable batch, so a large site finishes rather than stopping wherever the timeout landed.
Drift between index and database, caught
A failed sync leaves a post that exists but cannot be found. Document counts are compared against the database so a gap is noticed rather than reported by a customer.
A fallback when the index is unreachable
If search depends on a service that is briefly down, the failure should be a slower query rather than an empty results page. Queries fall back to the database instead of returning nothing.
Mapping changes handled as migrations
Altering how a field is indexed usually requires a rebuild, not an edit. Those runs are treated as scheduled work rather than something applied live and hoped over.
Bulk edits that do not flood the index
Changing a term across thousands of posts queues thousands of index updates. Those are batched instead of fired one per save while an editor waits.
The index is not the source.
Everything that goes wrong here is a divergence: content that was saved and never indexed, or indexed under a mapping that has since changed.
- Full reindex runs as a resumable batch
- Index and database counts reconciled
- Queries fall back rather than returning nothing
- Bulk edits queued instead of fired per save
Fast, and actually complete.
The point of an external index is that a faceted search stops being a meta query. The risk is that it returns quickly and leaves things out.
What we change for ElasticPress
Search now lives outside WordPress, so every row is about keeping the outside copy in step with the inside one.
| Setting | What we do | Why |
|---|---|---|
| Reindex runs | Resumable batches with progress retained | A full rebuild pushes every document to the index, which on a large site cannot finish inside a request and silently stops part way. |
| Drift detection | Index document counts reconciled against the database | A post that saved but failed to index exists and cannot be found, and nothing about the site looks wrong until somebody searches for it. |
| Query fallback | Falls back to the database when the index is unavailable | An unreachable search service should degrade to a slower query rather than an empty results page that looks like missing content. |
| Mapping changes | Treated as scheduled rebuilds, not live edits | Changing how a field is analysed does not apply to documents already indexed, so results stay inconsistent until everything is rebuilt. |
| Bulk edit indexing | Queued rather than triggered per save | Reassigning a term across thousands of posts fires an index update for each one, which blocks the editor and floods the service at the same time. |
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 can't I find a post that definitely exists?
What happens if the search service goes down?
Do I need to reindex after changing a field mapping?
Is ElasticPress worth it on a medium-sized site?
Keep the index and the content agreeing.
Move the site across. Migration is free, reindexing handled.