MediaWiki powers Wikipedia, which is perhaps the best possible advertisement for a wiki engine. XWiki powers internal knowledge bases at banks, defence contractors, and manufacturers, which tells a different story. When an organisation asks which one to adopt for enterprise use, the answer depends on whether the wiki is primarily a public content platform or an internal structured information system. This comparison walks through architecture, extensibility, governance, and operational cost so you can choose with confidence.
Origins and Philosophy
MediaWiki started as a PHP application for collaborative encyclopaedia editing. It optimises for large numbers of anonymous readers, linear article pages, and a flat namespace. XWiki started in 2003 as a Java application designed from the outset for enterprise use, with a page hierarchy, per-page permissions, a class/object model, and scripting inside pages.
Core Architecture
| Attribute | MediaWiki | XWiki |
|---|---|---|
| Language | PHP 8.x | Java (JVM, OpenJDK 17/21) |
| Web tier | Apache or NGINX with PHP-FPM | Tomcat, Jetty, or standalone |
| Database | MariaDB, MySQL, PostgreSQL, SQLite | MariaDB, MySQL, PostgreSQL, Oracle |
| Search | Built-in or CirrusSearch (Elasticsearch) | Apache Solr (embedded or SolrCloud) |
| Caching | Memcached, Redis | EHCache, Infinispan, Redis |
| Extension model | PHP hooks and skins | OSGi-style extensions, Velocity/Groovy scripting inside pages |
XWiki runs as a single JVM process, which makes memory tuning straightforward and scaling horizontal via clustering. MediaWiki relies on the PHP request lifecycle, which is simpler to reason about at small scale but requires external caching (Varnish, CirrusSearch) to perform well at enterprise volume.
Content Model
MediaWiki stores pages as flat wikitext with namespaces. Templates provide reuse, but you cannot attach structured data to a page and then query it without extensions like Semantic MediaWiki or Cargo.
XWiki's class/object model is its defining feature. Any page can host one or more XObjects, each backed by an XClass that defines properties (string, number, date, reference, list). You can then query XObjects with XWQL:
select doc.fullName from Document doc, doc.object(HR.EmployeeClass) as emp
where emp.department = 'Engineering' and emp.startDate > '2025-01-01'This effectively turns the wiki into a structured application platform. HR directories, asset registers, compliance registers, and meeting minutes can all be built without leaving the wiki.
Permissions and Governance
MediaWiki's permission model is oriented around public reading and authenticated editing. Fine-grained access requires extensions such as Lockdown or PageForms, and enforcement can be tricky on cached pages.
XWiki enforces permissions at the farm, wiki, space, and page level, with separate view, edit, comment, delete, admin, and programming rights. Permissions compose predictably down the hierarchy, and the same model governs REST API access. For regulated industries, this maps directly to access control requirements in ISO 27001 and SOC 2.
Search
Both systems support full-text search. MediaWiki's CirrusSearch uses Elasticsearch and scales well to hundreds of millions of documents. XWiki uses Apache Solr, embedded for small instances and SolrCloud for clustered deployments. Solr supports ACL filtering at query time, which means search results respect XWiki's permission model without post-filtering. This is a significant security property in enterprise contexts.
Extensibility
- MediaWiki: thousands of extensions, but many are community-maintained with inconsistent quality. Upgrading can break extension chains.
- XWiki: a curated Extension Manager with signed releases, dependency resolution, and in-wiki installation. You can also write extensions directly inside a page using Velocity or Groovy, which lowers the barrier to internal tooling.
Performance and Scaling
MediaWiki scales horizontally by adding PHP-FPM workers behind a load balancer with Varnish in front. Wikipedia serves billions of requests per month this way. XWiki scales horizontally by adding JVM cluster nodes that share a database and Solr cluster. Each node consumes 2 to 8 GB of heap depending on page complexity. For 1,000 concurrent users, a two to three node XWiki cluster on mid-range dedicated VPS instances is typical.
Total Cost of Ownership
MediaWiki has lower per-server resource needs at the same user count, which can translate to lower infrastructure cost. XWiki requires more memory but fewer moving parts once deployed, and the structured application features often replace other SaaS tools, which reduces total spend.
When to Choose Which
- Choose MediaWiki for large public reference sites, linear article content, community-driven editing, and when your team has PHP expertise.
- Choose XWiki for internal knowledge bases, compliance-driven environments, structured applications, fine-grained permissions, and when you want scripting inside pages.
Deployment Checklist
Whichever you pick, put the wiki on an infrastructure footprint that matches its role. For XWiki we recommend managed XWiki hosting on European data centers with Solr clustering enabled and database replication. For MediaWiki, the same principles apply, with Varnish and CirrusSearch added to the stack. Review our universal wiki migration strategy for content conversion tools.
Need help evaluating the two for a specific use case? Contact our team for a side-by-side deployment on your own data.
Published by the MassiveGRID team, specialists in enterprise wiki infrastructure and knowledge platform migration.