Wiki hosting for content with a long edit history.
A wiki's database is mostly not its articles. It is the revisions behind them, and that is what decides how the site performs in year three.
Everything a wiki asks of a host.
Articles are edited far more often than they are written, and WordPress keeps every version of every one of them.
A posts table that stays workable
Revisions are capped per article and archived beyond that, so the table WordPress joins against on every query does not grow to twenty times the size of your actual content.
History you can still read
Archived revisions stay retrievable and diffable from the dashboard, so capping the live table costs you table size rather than the record of who changed what and when.
Dense internal linking, resolved once
A wiki article links to dozens of others and each of those links is a lookup. Those resolutions are held in the object cache instead of being recomputed on every page view.
Search that finds the sentence
Full-text search runs against a real index rather than a wildcard match on post content, which is the difference between instant results and a query that reads the whole table.
Contributor edits without collisions
Post locking and an autosave interval tuned for long articles mean two contributors are warned about each other before one of them overwrites the other's work.
See what the history is costing you.
Revision growth is invisible until it is not. It shows up as a database that has quietly tripled while the article count stayed flat.
- Revision and table-size breakdown
- Per-site storage view
- One-click admin login for editors
- Restore any daily backup from the dashboard
An article with four hundred revisions behind it.
The article renders the same either way. What differs is how much of the posts table the database had to walk through to find it.
What we change for a wiki
These are the settings that differ from a standard WordPress site on the same plan. Each follows from a wiki storing far more history than content.
| Setting | What we do | Why |
|---|---|---|
| WP_POST_REVISIONS | Capped per article, with older versions moved to an archive table | Uncapped revisions leave the posts table an order of magnitude larger than the content it holds, and every query on the site pays for that. |
| Autosave interval | Lengthened for long-form articles | A default autosave on a ten-thousand-word article writes a full copy of it every minute of an editing session. |
| Full-text search | Indexed rather than a wildcard match on post content | Searching article bodies with a LIKE query reads every row, and that is precisely the query a wiki runs most often. |
| Object cache | Redis, sized to hold link and term resolutions | Articles that link to dozens of others turn a single page view into dozens of separate lookups without one. |
| Database maintenance | Scheduled table optimisation after each archive run | Rows moved out of a large table leave their space behind unless the table is rebuilt afterwards. |
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.
Will capping revisions lose our edit history?
How many articles can a wiki hold?
Is the search plugin included?
Can several people edit at once?
Do you migrate from MediaWiki?
Move your wiki to a host that accounts for its history.
Free migration, revisions that do not swallow the database, and search that finds the sentence.