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.
Articles are edited far more often than they are written, and WordPress keeps every version of every one of them.
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.
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.
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.
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.
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.
Revision growth is invisible until it is not. It shows up as a database that has quietly tripled while the article count stayed flat.
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.
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. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, revisions that do not swallow the database, and search that finds the sentence.