WordPress vs Drupal vs Joomla: which CMS for which site

Pick WordPress unless you have a specific reason not to. It runs over 40% of all websites according to W3Techs' survey, every theme and plugin you might want exists for it, and anyone you hire later will know it. Pick Drupal when the site is really a structured-content application - many content types with fields, fine-grained permissions, editorial workflow, serious multilingual - and you have a developer who will maintain it with Composer. Pick Joomla when you want more built in than WordPress offers (multilingual, access levels, a structured menu system) without Drupal's developer overhead, and you accept a much smaller ecosystem. All three are PHP applications on a MySQL-compatible database, and all three cost you some time every month in updates, whichever you choose.

The short comparison#

The table hides the most important difference: how much of the site is the CMS and how much is extensions. A WordPress site is mostly plugins - a contact form, SEO, caching, security, backups, a page builder - and its quality is the quality of those plugins. A Drupal site is mostly core plus configuration, with fewer and larger modules. Joomla sits between. That shapes everything else: security exposure, upgrade pain and who you need to keep it running.

Requirements: PHP, database and memory#

All three need PHP with the usual extensions (mysqli or pdo_mysql, gd or imagick, mbstring, xml, zip, curl, intl for Drupal and recommended for the others), a web server with URL rewriting, and a MySQL-compatible database. The exact version floors move with each release, so treat these as current at the time of writing and check the project's requirements page before you install.

Memory is where the real differences show. PHP runs each request in a worker with its own memory_limit, and the CMS plus its extensions decide how much a request needs:

• WordPress runs a simple site in 64-128 MB per request; WooCommerce and page builders push that to 256 MB or more. A whole small site including the database fits in 1 GB. How much RAM does WordPress need works the numbers by traffic.
• Drupal is heavier per request - 128 MB is a realistic floor and 256 MB normal for a site with many modules - but its built-in caching means most anonymous requests never build a page at all.
• Joomla sits close to WordPress for a comparable site.

The CMS line on RE:NODE starts at 1 GB for exactly this reason: a single site with a database fits, and the bigger plans are for plugin-heavy installs and several sites side by side. PHP ini settings that matter covers memory_limit, upload_max_filesize and the rest of what you will want to change.

WordPress: the default for good reasons#

WordPress is a blogging engine that grew into a general CMS, and the history shows: content is posts and pages, with custom post types and fields (via plugins like Advanced Custom Fields) bolted on. For most sites that is fine, and its advantages are hard to beat:

• The ecosystem. Whatever you need - booking, a shop, memberships, a forum, multilingual - there are several plugins, a few of them excellent.
• The editor. The block editor is good for people who write, and non-technical staff learn WordPress faster than anything else.
• The talent pool. Every web agency and many freelancers know it.
• Automatic updates. Minor core releases, which carry security fixes, install automatically by default. Plugin and theme auto-updates can be switched on per item.

The costs are the flip side. Most WordPress compromises come through plugins, not core: an abandoned plugin with a known hole is the usual way in. A site with forty plugins has forty vendors whose code runs with full access to your database. Performance problems are usually one heavy plugin. The fix is discipline rather than a different CMS - fewer plugins, chosen for maintenance history, and updates applied weekly - and WordPress security hardening covers the rest.

Installation is a zip file and a browser installer: create a database and user, upload the files, fill in wp-config.php or let the installer write it. Installing WordPress manually walks through it on a host without a one-click installer.

Drupal: structured content and serious permissions#

Drupal is a content framework. You define content types with typed fields, taxonomies, relationships between entities, views that list and filter them, and a permission system that can grant exactly one role the right to edit exactly one type of content. Core includes things WordPress needs plugins for:

• Multilingual - four core modules translate content, configuration and the interface.
• Content moderation and workflows - draft, review, published, with permissions per transition.
• Views - the query builder for listings, feeds and REST output, in core since Drupal 8.
• Layout Builder and caching - per-page layouts, plus Internal Page Cache and Dynamic Page Cache, which serve most requests without rebuilding the page.
• JSON:API in core, which makes Drupal a reasonable headless back end.

Modern Drupal is built and updated with Composer. A new site starts with composer create-project drupal/recommended-project, modules are added with composer require drupal/<module>, and updates are composer update followed by drush updatedb. That is the right way to manage a PHP application and the wrong way for a site owner who has never used a terminal. If nobody on the project is comfortable with Composer, Drupal will become the site nobody dares to update.

Major upgrades are incremental since Drupal 8: each major version removes code that was deprecated in the previous one, so a site that keeps up with deprecations moves from 10 to 11 without a rebuild. The painful migration was Drupal 7 to 8, and Drupal 7 reached end of life in January 2025 - any Drupal 7 site still running is unsupported. The Drupal hosting guide covers settings.php, cron and caching in detail.

Joomla: more in the box, smaller crowd#

Joomla's core is broader than WordPress's out of the box: multilingual sites with language associations, a menu system that drives page layout, user groups and viewing access levels, custom fields, workflows, and a built-in update component that updates core and installed extensions from the administrator. For a club, a school, a membership site or a multilingual brochure site, Joomla can do without extensions what WordPress needs three or four plugins for.

The trade-off is the ecosystem. There are far fewer extensions and templates, a larger share of them commercial, and fewer people who know the system well. The jump from Joomla 3 to 4 broke many templates and extensions and pushed a lot of sites to rebuild; the 4 to 5 upgrade was gentler, with a backward-compatibility plugin to keep older extensions working while their developers caught up. Check that the extensions you depend on support the current major version before you upgrade.

Joomla installs like WordPress: upload the package, create a database, run the web installer, and delete the installation folder when it tells you to. The Joomla hosting guide has the configuration and update details.

Upkeep: what each one costs you every month#

All three are software that is attacked automatically, all day, by scanners looking for known holes. The CMS you choose is less important than whether you keep it updated.

Whatever you run, the routine is the same: a backup before every update, updates applied weekly rather than whenever someone remembers, a short check that the site still works afterwards, and extensions removed - not just disabled - when you stop using them. The database is half the site, so the backup has to include it; see database backups and restores.

What they cost beyond hosting#

All three are free and GPL-licensed. The money goes elsewhere, and it is worth estimating before you choose, because the hosting bill is usually the smallest line.

• WordPress is cheap to start and gets more expensive as it grows. The best plugins for forms, SEO, backups, multilingual and shops have free versions and paid tiers sold as yearly licences, and a paid tier is what you need for updates and support. A business site commonly runs three to six of them. Let a licence lapse and that plugin stops receiving updates, which brings you back to the abandoned-plugin problem.
• Drupal has almost no commercial module market; nearly everything on drupal.org is free. The cost is people: building content types, views and permissions well takes a developer, and so does keeping a Composer-managed site current. A Drupal site with no developer budget behind it is a liability.
• Joomla has a larger share of commercial extensions than WordPress, often from small vendors, sold as subscriptions. Check how long a vendor has been releasing updates before you build a site around their extension.

Count your own time too. An hour a month of updates and checks is the realistic minimum for any of them, and the hour you skip is the one that matters.

Hosting any of them on nginx#

All three ship rules for Apache in an .htaccess file (Joomla as htaccess.txt, to be renamed). nginx does not read .htaccess at all. On nginx the same rules - pretty URLs and, just as important, the rules that deny direct access to private files - must exist in the server configuration instead. The core of it for all three is the front-controller pattern:

location / {    try_files $uri $uri/ /index.php?$args;}location ~ \.php$ {    include fastcgi_params;    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;    fastcgi_pass php-fpm;}

Drupal also needs its settings.php and private files directory kept away from the web, and Joomla's security rules from htaccess.txt translated. A host that sells nginx-based CMS hosting should have these in place; if pretty permalinks give you 404s on a fresh install, it is this.

On RE:NODE the CMS line - called Engines in the catalogue - runs on nginx and PHP, and you install the CMS yourself through the file manager or SFTP. There is no one-click installer, which also means nobody pins you to a version. Each plan carries database slots for the site's database and a proxy slot: point an A record at the address the panel shows and the certificate is issued and renewed automatically.

Choosing: a quick decision guide#

• A blog, a small business site, a portfolio, a WooCommerce shop: WordPress.
• A site where non-technical staff will do all the editing and you will not have a developer: WordPress, with as few plugins as you can manage.
• Many content types with relationships, complex roles, editorial approval, several languages, and a developer on hand: Drupal.
• A multilingual or membership site without a developer, where you prefer core features to plugins: Joomla.
• A Russian-language news or media portal with an existing DataLife Engine licence: DLE, covered in DataLife Engine hosting.
• A site that rarely changes and has no logins or forms: possibly no CMS at all - a static site is faster, cheaper and has nothing to patch. See static site hosting.

The worst choice is the one nobody on the team can maintain. A well-kept WordPress site beats a neglected Drupal site on security, speed and cost every time.

FAQ#

Is WordPress less secure than Drupal or Joomla?

WordPress core has a good security record. It is attacked more because it is everywhere, and most real compromises come through outdated or abandoned plugins. Drupal's reputation for security comes partly from its security team and partly from sites having fewer, better-reviewed modules. An updated WordPress site with few plugins is not meaningfully less secure.

Can I move from one CMS to another later?

Yes, but it is a migration project, not a button. Content can be moved with importers and migration tools - Drupal's Migrate API is strong, and WordPress has importers for many sources - but themes, URLs, forms and extension data have to be rebuilt. Choose with a few years in mind.

Which CMS is fastest?

With page caching on, all three serve anonymous visitors quickly, because the cached page skips PHP and the database. The differences appear for logged-in users and uncached pages, where extension count and quality matter more than the CMS. Drupal's built-in caches give it a good default; WordPress needs a caching plugin or server-side cache - see WordPress speed and caching.

Do they all work with MySQL 8.4?

Current releases of all three support MySQL 8.0 and later, and MySQL 8.4 is in that series. Older versions - Drupal 7, Joomla 3, very old WordPress plugins - may use removed SQL features or old authentication, which is one more reason to update before you move hosts.

Can I host several CMS sites on one plan?

Technically yes, if storage, memory and database slots allow. It is usually better to keep unrelated sites apart, so one site's compromised plugin cannot reach another site's files and database.