When to choose MediaWiki or DokuWiki for your team wiki
Choose MediaWiki when the wiki will grow into a large, database-backed knowledge base that needs a long support horizon and a broad extension ecosystem, and choose DokuWiki when the content is modest, the team wants flat-file storage with no database to run, and directory login through its bundled authldap and authad plugins covers your identity needs. Both are GPL wikis, so license alone will not separate them. The decision turns on four drivers: expected content volume, how much the wiki must integrate with other systems, who will maintain it, and how often the team can afford upgrades. On volume and integration, MediaWiki stores pages in a relational database, with MariaDB or MySQL recommended, and its PluggableAuth extension covers OpenID Connect, SAML through SimpleSAMLphp, LDAP through LDAPAuthentication2, and other login methods. If you need single sign-on to a non-directory provider or a broad set of extensions, MediaWiki is the stronger starting point. DokuWiki's default configuration keeps all files under a data directory, which is simple to back up but needs a check of how your content volume and access patterns perform in your own environment. Confirm both points by testing with a representative copy of your content. On maintenance and upgrades, MediaWiki publishes an LTS release every two years, and the current LTS line is 1.43, supported until December 2027, per the MediaWiki version lifecycle page. Teams that cannot upgrade every year should plan around LTS. DokuWiki ships on a dated release cadence, with the 2026-07-14 "Mort" release and a later security hotfix, so the team must apply updates promptly. Before committing, name the person who owns upgrades and ask whether that person has the time for the cadence you choose.
Which wiki fits which scenario
This table maps common team situations to the wiki that fits better and the condition that decides it. Read each row as a starting point, then check the condition against your own identity, data, and staffing constraints before choosing.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Large multi-department knowledge base | MediaWiki | Many editors, many namespaces, and heavy page volume favor a database-backed engine with an extension ecosystem and LTS upgrade planning on the MediaWiki version lifecycle. |
| Small engineering team documentation site | DokuWiki | A small team with modest page counts can run DokuWiki's file-based storage with a default configuration and no database to maintain. |
| AD-centric office | DokuWiki | DokuWiki bundles authad for Active Directory, so AD sign-in works without adding an extension, though group mapping must be confirmed in your environment. |
| AD-centric office with broader external sign-in needs | MediaWiki | PluggableAuth offers LDAP through LDAPAuthentication2 along with OpenID Connect and SAML, which suits sites that also federate other identity sources. |
| Wiki that must be fed by external systems | MediaWiki | MediaWiki's extension ecosystem and database backend give more integration paths, but confirm which extensions your source systems need and their license compatibility. |
| Team with no database administrator | DokuWiki | With no database to back up or tune, DokuWiki's file-based default reduces the operational surface, provided file backups and permissions are handled. |
| Team that needs formal upgrade planning | MediaWiki | MediaWiki publishes LTS releases every two years and supports upgrades from up to two LTS releases back, which helps schedule upgrade work. |
| Site needing per-page permission granularity | MediaWiki | Confirm the exact permission model you need against the MediaWiki and DokuWiki documentation, since DokuWiki's ACL plugin covers namespace-level control. |
How MediaWiki and DokuWiki are built and deployed
The two engines differ at the storage layer before they differ on features. MediaWiki is a PHP application that depends on a supported database, while DokuWiki keeps its content in files by default. Each cards below covers a deployment decision that follows from that split.
Database-backed MediaWiki
MediaWiki runs as a PHP application on a supported database. MariaDB or MySQL is recommended, and PostgreSQL 10 or later and SQLite 3.31 or later are also supported. Your backup plan must capture the database and the uploaded files together, and you need a restore test that proves both come back in step. Ask your team which database engine it already operates and who owns its patching.
File-based DokuWiki storage
DokuWiki's default configuration stores pages and metadata as files under a data directory (savedir ./data) rather than in a database. There is no separate database service to size or patch. Backups are a matter of copying that directory consistently, and you should confirm that your file-level snapshot or backup tool handles it while the wiki is in use.
PHP versions and runtime
Both engines run on PHP, but the minimum versions differ. The latest stable MediaWiki requires PHP 8.3.0 or later, while DokuWiki's composer.json requires PHP 8.2 or later. If your platform team pins one PHP runtime for several internal apps, check that a MediaWiki LTS line and a DokuWiki release both run on it before you commit.
Web server and hosting footprint
MediaWiki is broadly compatible with web servers that can invoke a compatible PHP version, and Apache HTTPD and Nginx are commonly used. DokuWiki is also a PHP application, so the web server choice is similar, but its smaller footprint means fewer moving parts. Ask your team whether it wants a database tier to be part of the wiki's operational scope, since that decides how much MediaWiki adds to the host.
Upgrades and release cadence
MediaWiki publishes an LTS release every two years, and upgrades are supported from up to two LTS releases back, so planned upgrade windows are predictable. DokuWiki ships dated releases, and its 2026-07-14 line received a hotfix on September 2, 2026. Plan for a test instance that mirrors your installed extensions or plugins before you apply either engine's upgrade to production.
Authentication integration path
DokuWiki bundles authldap and authad, so directory sign-in is part of the core package. MediaWiki reaches LDAP, OpenID Connect and SAML through the PluggableAuth framework, which means an extra extension to install, version and test against each MediaWiki upgrade. Confirm which sign-in method your identity team supports and whether the extension's MediaWiki version support matches your upgrade path.
Feature comparison: MediaWiki against DokuWiki
This table compares the two GPL wikis on license, storage, authentication, permissions, extensibility, editing, scale, upgrades and API support. Read each row as a question to answer for your own environment, and treat any cell that says to confirm as an open item for your evaluation.
| Capability | MediaWiki | DokuWiki |
|---|---|---|
| License | GPL-2.0 or later; extensions using MediaWiki functions must use the same or a compatible license | GPL-2.0 |
| Storage model | Relational database (MariaDB or MySQL recommended; PostgreSQL 10+ and SQLite 3.31+ also supported) | Files in a data directory by default (savedir ./data), with no database required for core storage |
| Built-in authentication | Local accounts; external login added through PluggableAuth plugins for OpenID Connect, SAML (SimpleSAMLphp), LDAP (LDAPAuthentication2), OAuth and REMOTE_USER | Bundled authplain (default), authldap, authad for Active Directory and authpdo for SQL databases |
| Permissions model | Confirm the namespace and page-level rights you need in your installed extensions and configuration | Bundled ACL plugin for page and namespace access control |
| Extensibility | Large extension ecosystem; confirm each extension's license, maintenance status and MediaWiki version support before adopting it | Bundled extension manager and config manager; confirm third-party plugin compatibility with your release |
| Editing and admin tools | Confirm editor options and workflow features against the version you plan to run | Bundled revert plugin and log viewer; user manager for account administration |
| Scale considerations | Database-backed design; confirm capacity, caching and database sizing with your own page and traffic profile | File-based design; confirm backup, search and concurrency expectations for your content volume |
| Upgrade model | Current stable 1.46; LTS 1.43 supported until December 2027; upgrades supported from up to two LTS releases back | Dated releases such as 2026-07-14, with hotfixes; confirm your upgrade path and plugin compatibility |
| API support | Confirm the API modules and rights you need for your integrations | Bundled remote API; confirm the methods your integrations require |
What the GPL licenses mean for each wiki
MediaWiki is licensed under the GNU General Public License version 2 or later. The license also reaches the extensions that depend on the engine: any extension that uses MediaWiki functions must be released under the same license or a compatible one. For an internal team this is usually a non-issue, but it matters once you write custom extensions, fork the codebase, or distribute modified builds to partners or customers. The license governs the code you distribute, so the obligations land on whoever ships the modified package.
- Core license: GPL-2.0-or-later covers the engine itself, so you may run and modify it for internal use without a license fee.
- Extension terms: Extensions that call MediaWiki functions must carry the same or a compatible license, which affects any in-house or third-party extension you add.
- Distribution: Shipping a modified build outside your organization brings source-availability duties under the GPL.
- Paid editions: The license terms do not list a paid edition, so ask the project or a commercial support provider directly what support options exist.
- Extension ecosystem: Review the license of each third-party extension before installation, because the extension's terms are separate from the core.
Before you adopt custom extensions, have legal review confirm how the compatibility requirement applies to your planned code and distribution model.
DokuWiki is licensed under GPL-2.0, as shown in the license metadata of its GitHub repository. The project's README credits Andreas Gohr and the DokuWiki community and points to dokuwiki.org for documentation and installation. The license covers the core and the plugins distributed with it, and a plugin you write for internal use has the same copyleft considerations as any GPL-2.0 work if you distribute it. Because the core is a single GPL-2.0 codebase with bundled plugins, the license terms for the stock install are straightforward, but custom plugins still need a review before they leave your environment.
- Core license: GPL-2.0 covers the wiki engine and the plugins shipped in its repository.
- Custom plugins: Plugins you write that are distributed beyond your organization fall under GPL-2.0 obligations.
- Paid editions: No paid edition is supplied in the research for this comparison, so DokuWiki's licensing does not describe any commercial tier.
- Support options: Confirm with the DokuWiki project or any third-party provider which commercial support, hosting or training services exist and what they cost.
- Bundled plugins: Authentication and administration plugins that ship in the repository are covered by the same core license, which simplifies a standard install.
Before you rely on DokuWiki for an audited environment, confirm the support and maintenance arrangements you need in writing, because the license alone does not describe them.
Neither fact set lists a paid edition, feature gate or commercial license for MediaWiki or DokuWiki. That does not mean none exists. It means the comparison cannot state one, and the gap matters for procurement. Support, hosting, managed upgrades and training may be available from the projects, their foundations, consultancies or service providers, but each needs confirmation before you budget for it. A GPL license keeps the software free to use, while the costs of running a wiki sit in the people who install, patch, back up and customize it.
- What is free: The software license permits use without a license fee for each platform covered on these tabs.
- What may be paid: Support contracts, managed hosting, upgrades, training and custom development are separate services.
- Who to ask: The MediaWiki project, the DokuWiki project and any vendor you engage each set their own support terms.
- What recurs: Labor for upgrades, security patching and backups recurs regardless of license.
- What to request: Ask for written scope, response expectations and the named support channel in any quote.
Before you select either platform, request written confirmation of the support options each project or vendor offers, and record them in your procurement file.
How MediaWiki LTS releases compare with DokuWiki's release cadence
MediaWiki and DokuWiki ship on very different rhythms, and that difference shapes how much testing you must schedule each year. MediaWiki publishes an LTS release every two years with a one-year overlap in LTS support. The current stable line is 1.46, released on June 30, 2026 with end of life in July 2027, and the LTS release is 1.43, released on December 21, 2024 and supported until December 2027. Since 1.36, upgrades are supported from up to two LTS releases back, so a team on 1.43 can plan a jump to a later LTS without stepping through every intermediate version. Confirm the exact upgrade path for your installed version in the MediaWiki version lifecycle page before you commit to a window.
DokuWiki works differently. Its releases carry a date rather than an LTS label, such as 2026-07-14 "Mort", which was published on July 14, 2026. Security and bug fixes arrive as hotfixes on that line, including 2026-07-14c on September 2, 2026 and the 2026-07-14b hotfix on August 11, 2026, which fixed a security issue. A dated line gives you fast access to fixes but no multi-year support promise to plan around, so the decision you make is whether you can apply hotfixes promptly. Subscribe to the dokuwiki/dokuwiki releases page and assign an owner to read each hotfix's notes.
For MediaWiki, the planning question is which LTS you will sit on and when you will move to the next one, with extensions as the main risk. Each extension, such as PluggableAuth, must be checked against the target MediaWiki version before the upgrade, and PluggableAuth 7.x requires MediaWiki 1.40 or later. For DokuWiki, the planning question is cadence discipline: a staging copy of the data directory and the conf settings lets you test each hotfix quickly. Whichever you choose, ask your vendor or internal team to document a rollback step and a tested backup before every upgrade.
Moving content from DokuWiki to MediaWiki, or the reverse
This sequence moves a wiki's pages, permissions, attachments and sign-in from one engine to the other without losing history or locking users out. It ends with a tested cutover and a rollback path that the team has verified.
Inventory namespaces, pages and attachments
The wiki owner and an administrator list every DokuWiki namespace, page, media file and page revision count, then mark which content is current, archived or obsolete. For MediaWiki, the team records the target namespaces and the content models it will use. Done means a signed-off inventory spreadsheet that maps each DokuWiki namespace to a MediaWiki namespace or category, with pages marked for migration or retirement. Pages that will not move are listed so no one assumes they were kept.
Map ACLs and accounts to groups
An administrator exports the DokuWiki user list and the access control rules, which DokuWiki stores per namespace and per page, and translates them into MediaWiki user groups and namespace-level rights. Where sign-in will come from a directory, the team decides whether PluggableAuth will use LDAP through LDAPAuthentication2 or another supported plugin, and records which DokuWiki groups map to which MediaWiki groups. Done means a written permission matrix that a reviewer has checked against the original rules, including any pages where the mapping is imperfect.
Convert markup and templates
A developer converts DokuWiki syntax to MediaWiki wikitext, either with a conversion tool the team has validated on a sample or with scripted rules for headings, links, tables and media references. DokuWiki plugin syntax and custom templates have no direct equivalent, so they are listed and rebuilt as MediaWiki templates or extensions. Done means a sample of pages from each namespace renders correctly in a test instance, and every plugin-dependent page is on a rebuild list with an owner.
Migrate attachments and revision history
The team moves media files into MediaWiki's file storage and imports page revisions in order, checking that timestamps, authors and edit summaries carry over where the import method supports them. Because DokuWiki keeps its content in files under a data directory rather than a database, the import path depends on what the team exports from that store. Done means a reconciliation report showing counts of pages, revisions and files in source and target, with every gap explained.
Test authentication and permissions
Testers sign in to the staging instance with each user type, including directory-backed accounts, local accounts and administrators, then attempt reads, edits and deletions in each namespace against the permission matrix. The team confirms that PluggableAuth behaves as configured for the chosen identity source and that login failures are logged. Done means a test log that records each user type, each expected and actual result, and the fixes applied, signed off by the security owner.
Confirm details with vendors and documentation
Before cutover, the team checks the current MediaWiki and extension documentation for the PHP, database and extension versions it will run, and confirms with the DokuWiki project documentation which features and plugins it is relying on for export. Anything the sources do not settle, such as support for a specific plugin behavior or a conversion edge case, goes to the vendor or project maintainers in writing. Done means a list of open questions with answers recorded and a decision on each item.
Cut over and keep a rollback path
On an agreed window, the team freezes edits on the source wiki, runs the final incremental export and import, repeats the reconciliation report, and switches the public address or redirects links. The original DokuWiki instance and its data directory stay read-only and intact until the owner accepts the result. Done means users can reach the new wiki, the reconciliation report shows no unexplained differences, and a documented rollback procedure has been rehearsed.
Where implementation projects for each wiki usually run long
MediaWiki projects usually run long at the edges of the platform rather than in the core install. Provisioning the database is the first decision: the latest stable release requires PHP 8.3.0 or later, and MariaDB or MySQL is recommended, so the team must confirm the database version, PHP build and web server (Apache HTTPD or Nginx are commonly used) before anyone writes configuration. Extension selection is the second delay point. Each extension needs a license review, because MediaWiki is GPL-2.0-or-later and extensions that use its functions must carry the same or a compatible license. PluggableAuth is usually the longest item: the directory mapping for OpenID Connect, SAML through SimpleSAMLphp, or LDAP through LDAPAuthentication2 has to be tested with real groups, and PluggableAuth 7.x requires MediaWiki 1.40 or later. Upgrade planning also belongs in the first sprint, since the team must choose a release line (1.43 is the LTS, supported until December 2027) and rehearse the database and extension updates before go-live.
DokuWiki projects usually run long at permissions and storage, even though the install is short. Because the default configuration keeps pages and metadata in the data directory (savedir ./data) rather than a database, the first risk is file ownership and write permissions for the web server user, which are often wrong on a copied or containerized host. Backup design is the second risk: the file store is the content, so the team must decide how to snapshot it consistently and restore it in a test environment. ACL design is where most projects stall. The access control plugin works per namespace and page, so the team needs a written role matrix before editing conf/acl.auth.php, and the same matrix must match the groups supplied by authldap or authad. Confirm with your own directory administrators how group names and nested groups will resolve, because a mismatch there shows up only after users log in.
Questions buyers ask before choosing a self-hosted wiki
Can DokuWiki use LDAP or Active Directory without extra products?
Yes, DokuWiki bundles the authldap and authad authentication plugins in its lib/plugins directory, so directory sign-in does not require a separate identity product. The effort sits in configuration: you point the plugin at your directory, map groups to DokuWiki's access control rules, and test with a service account and representative users. Confirm that your directory layout, nested group handling and account lockout behavior match what the bundled plugins expect, and test before cutover. Ask your platform team which directory mode (LDAP or AD) applies and who owns the service account.
When does a database matter for a wiki like MediaWiki or DokuWiki?
A database matters when you need to query, report on or bulk-edit content at scale, or when your operations standard requires database backup and replication tooling. DokuWiki's default configuration stores all its files under a data directory (savedir ./data) instead of a database, which keeps the footprint simple but shifts backup and consistency work to file-level processes. MediaWiki requires a database: the latest stable release supports MariaDB 10.3+, MySQL 5.7+, PostgreSQL 10+ and SQLite 3.31+, and MariaDB or MySQL is recommended because Wikimedia uses MariaDB. Confirm which database your DBAs already support, and who patches it.
What does MediaWiki's LTS policy mean for upgrade planning?
MediaWiki releases an LTS version every two years with a one-year overlap in LTS support, and since 1.36 upgrades are supported from up to two LTS releases back. Per the lifecycle page, 1.46 is the current stable release with end of life in July 2027, and 1.43 is the LTS release, supported until December 2027. Plan your window around those dates: an LTS line gives you a stable target for a planned upgrade, while a non-LTS line forces more frequent moves. Confirm the current lifecycle page before you commit to a version, and budget testing for each extension you rely on.
What ongoing effort does each wiki need after go-live?
Both wikis need routine patching of the web server and PHP runtime, backups, and periodic review of installed extensions or plugins. MediaWiki adds database maintenance and extension compatibility checks at each core upgrade, and it requires PHP 8.3.0 or later for the latest stable release. DokuWiki requires PHP 8.2 or later and fewer moving parts, but you still own plugin updates and the security hotfixes published on its releases page, such as the 2026-07-14b hotfix published on August 11, 2026. Ask who will track releases and who approves a patch window.
Is migrating between MediaWiki and DokuWiki practical?
Migration is practical when page count is modest, page history matters less than current content, and you can accept a manual review of links, templates and plugin-generated markup. Neither source document describes a supported one-click conversion, so treat the move as a content project: export, map namespaces and categories, rebuild access rules, and verify internal links. Ask the implementer to inventory extensions, templates and authentication settings first, and to define what history and attachments must survive. Confirm these steps in a written scope before work begins.
What should a quote for a self-hosted wiki project include?
A useful quote lists the scope in writing: the version to install, the database or file storage design, the authentication method, the extensions or plugins in scope, the migration approach, backup and restore testing, and documentation handed over at the end. Ask whether the price covers one-time setup, recurring support or upgrades, and whether testing and cutover are separate line items. DeployOpen does not publish a price list, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for each component to be priced separately so you can compare options fairly.
Which wiki fits a team that needs granular permissions?
MediaWiki's permission model depends on user groups and the extensions you add, and the PluggableAuth framework connects it to OpenID Connect, SAML through SimpleSAMLphp, LDAP through LDAPAuthentication2, OAuth and REMOTE_USER. DokuWiki bundles an access control (acl) plugin that sets read and write rights per namespace, so rules for small teams are straightforward to express. Choose based on how many distinct permission zones you need and whether you require external identity federation. Confirm the exact rule model against the current version of each product before you design your access matrix.
How DeployOpen helps choose and implement a wiki
DeployOpen helps teams decide between MediaWiki and DokuWiki against their own permissions, identity and content needs, then plans, implements and documents the chosen platform inside the client's own infrastructure. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope lists the wiki use cases, content volume and users each platform must serve.
- Identity requirements such as LDAP, Active Directory or OIDC sign-in are defined before a platform is chosen.
- Permission models, namespaces and page ownership rules are documented as part of the agreed deliverables.
How we build
- Installation covers the web server, PHP runtime and, for MediaWiki, the database layer in your environment.
- Authentication is configured and tested, including any extensions or bundled plugins the scope requires.
- Security hardening, backup routines and content migration are built and verified against the written scope.
How we hand over
- Handover documentation covers the configuration, permission design, backup and restore steps and upgrade procedure.
- Your administrators receive a walkthrough of editing, access control and day-to-day maintenance tasks.
- Open items, such as extension choices or licensing questions to confirm with the vendor, are recorded in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Upgrade planning follows the release lifecycle of the chosen platform, which we confirm with you before each change.
- Retainer scope, including which upgrades and tests are covered, is agreed in writing before work starts.
