Every wiki platform comparison you have ever read is basically the same article with different logos slapped on top. Platform A has 400 extensions. Platform B has a prettier editor. Platform C is free and open source. So you pick one, burn a weekend on setup, and eighteen months later you are the only person who still remembers the admin password while the whole thing rots into a graveyard of half-finished pages.
That is not a platform problem. That is a comparison problem. The feature grids are measuring the wrong stuff.
Here is what actually decides whether a wiki survives contact with real humans, plus the workarounds people quietly use when the platform they picked turns out to be a trap.
The Question Nobody Asks Until It Is Too Late
Who maintains this in year three?
That is it. That is the whole comparison. Everything else is decoration.
Wikis do not die because the search was slightly worse. They die because:
- The one person who understood the upgrade process got a new job
- A major version bump broke the theme and nobody had time to fix it
- The permission model turned out to be all-or-nothing, so nobody could share anything safely
- The editor was annoying enough that people wrote their notes somewhere else instead
- The hosting bill crept up quietly until someone asked why we are paying for this
If you compare platforms against that list instead of against a spec sheet, your shortlist collapses fast.
The Four Real Categories
Strip away the branding and there are only four kinds of wiki platform. Everything else is a variation.
1. Flat-file wikis
Pages live as individual text files on disk. No database required.
- Upside: Backups are literally copying a folder. You can read your entire wiki in a text editor. Migration off it is trivial because there is nothing to export.
- Downside: Search and permissions get weak fast. Anything past a few thousand pages starts to creak. Multi-user editing conflicts are a real risk.
- Best for: Small teams, personal knowledge bases, and anyone who has been burned by a dead database before.
2. Database-backed wikis
The classic model. Pages, revisions, users, and permissions all live in a relational database.
- Upside: Handles scale, granular permissions, huge revision histories, and real full-text search. Battle-tested.
- Downside: Setup and upgrades are heavy. Backups are more than a file copy. A failed upgrade can take the whole thing down with no easy rollback.
- Best for: Organizations with hundreds of editors and someone who actually enjoys server administration.
3. Hosted and subscription wikis
Someone else runs it. You pay monthly or per seat.
- Upside: Zero maintenance, instant setup, usually a nice editor, and mobile access that does not make you want to throw your phone.
- Downside: Your content lives on someone else’s infrastructure, under their rules, at a price they can change whenever they want. Export exists, but it rarely exports the structure.
- Best for: Teams with no technical staff and a budget line that is not going to get cut in six months.
4. Version-controlled text wikis
Pages are plain-text files stored in a version control repository, edited either through a light web interface or offline.
- Upside: Full history, branching, offline editing, and absolutely bulletproof portability. The content outlives the tool.
- Downside: Not friendly to non-technical contributors. Merge conflicts are a personal growth opportunity.
- Best for: Technical teams who already live in version control and treat documentation like code.
What to Actually Compare
Once you know your category, compare on these and ignore the rest.
- Storage model. Can you read your content without the tool? If not, you are renting your own knowledge.
- Permission granularity. Per-page, per-space, or all-or-nothing? Most comparisons skip this and it is the single most common reason wikis get abandoned.
- Editor friction. The best platform is the one your least technical contributor will actually use twice.
- Search quality. Search that misses synonyms is the reason people go back to browser bookmarks.
- Export format. What does it produce — a folder of clean pages, or a proprietary blob only the vendor’s tool can open?
- Upgrade path. Can you upgrade one version at a time without a maintenance window, or is every update a project?
- Cost curve. Not the price today. The price at 3x your current user count.
The Uncomfortable Stuff Nobody Puts on the Comparison Page
Export is not migration. Every platform exports. Almost none of them export in a format the next platform imports cleanly. You get the text, then you spend three weekends rebuilding links, categories, and permissions by hand. Budget for that before you commit, not after.
Extension rot is the silent killer. The plugin ecosystem that made a platform attractive at evaluation time quietly dies. Core updates land, plugins do not follow, and you end up pinned to an old version forever. A platform with ten maintained features beats one with four hundred abandoned ones.
Permission gaps get discovered at the worst time. Some platforms can restrict who reads a page but not who can rename it, or hide a space but leak it through search results and recent-changes feeds. Test this with a real second account before you trust it.
Public wikis attract spam within weeks. Open editing sounds great until it is not. Expect to need some combination of account requirements, rate limits, and captchas, or your wiki becomes a link farm.
Features get removed. Hosted services retire functionality constantly. If a workflow depends on one specific feature, assume it has a two-year shelf life.
Workarounds That Quietly Work
These are the moves people make when they are stuck with a platform that is not quite right.
- Mirror everything to flat files on a schedule. Even a mediocre flat export is enough to rebuild from if the platform disappears. Automate it and forget it.
- Use the API to dual-write. Push content into a second, boring, self-hosted instance. Nobody talks about the backup wiki. Everybody is grateful for it.
- Scrape your own wiki into a static site. Great for archival, great for offline search, and a solid middle finger to any future paywall.
- Stand up a throwaway copy for upgrades. Restore a snapshot, run the upgrade there, screenshot everything that breaks. Then decide if it is worth it.
- Treat markup conversion as a scripting problem, not a manual one. A few hours of regex beats a month of copy-paste, and it is repeatable when you migrate again in three years.
- Keep a plain-text index of every page title and link. It makes any future migration dramatically less painful.
A Decision Order That Actually Works
- Count your editors and how technical the least technical one is.
- Decide whether the content must be readable without the tool. If yes, go flat-file or version-controlled.
- Check permission granularity against your actual sharing needs, not your imagined ones.
- Export a test wiki from your top candidate and try to import it into your second candidate. This will change your ranking.
- Pick the boring option. Boring platforms are still alive in five years.
The Bottom Line
The best wiki platform is not the one with the longest feature list. It is the one that survives the departure of its most enthusiastic admin, the one whose content you can pick up and walk away with, and the one your least technical teammate will actually open on a Tuesday afternoon.
Compare accordingly. And while you are at it, set up that automated export tonight. You will not need it for a year or two, and then one day you will need it very badly.