Choosing a Drupal database before the platform is built
If you are standing up or migrating a Drupal platform, pick the database before any code is written: MariaDB, MySQL or PostgreSQL. Drupal supports MariaDB, MySQL, PostgreSQL or SQLite according to the Drupal.org system requirements page, and the choice is not a setting you can change cheaply later. It shapes what the installer expects, which contributed modules will work without patches, how backups and restores are run, how major upgrades of the database are planned, and which hosting services you can use. Treat it as an architecture decision with the same weight as the web server and hosting model, not as a default to accept from the installer.
Decide early because the database choice constrains several other decisions. Confirm the exact database versions your target Drupal release and your chosen hosting platform support, since minimums differ by Drupal release and the PHP requirements move with them. Then check every contributed module on the shortlist for database-specific code, especially any module that relies on MySQL-only or PostgreSQL-only features, and record which ones need a supported alternative or a patch. If the platform will run on a managed database service, confirm the engine, version, backup retention, point-in-time recovery and maximum connection limits with the provider before the build plan is fixed. Changing engines after content, custom modules and integrations are in place means a full migration, so the cost of deciding late is high.
For a Drupal 7 migration, the database decision also affects the migration path, because the new site is built fresh and its data is moved in with the Migrate tooling rather than upgraded in place. Document the decision, the reasons and the versions in the architecture record so that the team running the platform in later years knows why the engine was chosen. The sections that follow cover version minimums, contributed module compatibility, PostgreSQL-specific requirements and managed options in detail.
How each database option fits a Drupal platform
This table compares MariaDB, MySQL, PostgreSQL and managed database services across the factors that matter for a Drupal platform: licensing, team skills, contributed module support, replication and upgrade paths. Read each row as a question to answer for your own environment, and treat the PostgreSQL facts as firm while confirming MySQL and MariaDB details with their vendors and the module pages.
| Factor | MariaDB or MySQL | PostgreSQL |
|---|---|---|
| Licensing | Confirm the license terms of the specific MySQL or MariaDB edition and distribution your organization will run. | Released under the PostgreSQL License, a liberal open source license similar to the BSD or MIT licenses. |
| Supported versions | Confirm current version support and Drupal's stated minimum for your Drupal release with the vendor and the Drupal system requirements page. | Versions 14 to 18 are supported. Version 14 support ends November 12, 2026 and version 18 support runs to November 14, 2030. |
| Contributed module support | Some contributed modules include MySQL-specific code. Check each module's issue queue and documentation before you commit. | Some search and text features depend on the pg_trgm extension. Confirm extension availability on your managed or self-hosted instance. |
| Team skills | Often a fit where the team already runs MySQL or MariaDB in production and has tested backup and restore runbooks for it. | Fits teams with existing PostgreSQL operations experience or where a PostgreSQL standard already exists in the organization. |
| Replication | Confirm replication topology, failover tooling and consistency settings with your vendor for the version you select. | Supports hot standby servers for read-only queries, and both synchronous and asynchronous replication. Automatic failover needs external tools. |
| Major version upgrades | Confirm the supported upgrade path and rollback approach for your version with the vendor. | Logical replication works across major versions, and pg_upgrade and dump-and-restore are documented. Plan and test the chosen method. |
| Managed services | Compare managed MySQL or MariaDB offerings for backup retention, maintenance windows and supported extensions or plugins. | Compare managed PostgreSQL offerings for supported major versions, extension lists, point-in-time recovery and connection pooling. |
Checking contributed modules for MySQL-specific code
Core Drupal runs on MySQL, MariaDB and PostgreSQL, but contributed modules are written by many authors and may not be tested on every database. The cards below set out how to find database-specific code, judge its test coverage and price the work if a module needs patching or replacing before the database decision is final.
Why contributed code is the risk
Core Drupal is built to run on each supported database, but a contributed module can issue raw SQL, assume MySQL behavior or call functions that exist only in one engine. The problem often appears late, when a feature fails on the first PostgreSQL test site rather than in a design review. List every contributed project in the composer lock file and mark which ones query the database directly, so the review starts from evidence rather than from the module names you already know.
Read the module issue queue
Open each project's issue queue on Drupal.org and search for terms such as PostgreSQL, pgsql, MySQL, MariaDB and database-specific errors. Note whether reports are open, whether maintainers have responded, and whether a fix was merged for the release you plan to run. An issue that has sat unanswered for a long time suggests you will carry the patch yourself, so record that as a cost before you commit to the module.
Inspect database-specific code paths
Search the codebase for raw queries, direct calls to database driver classes, and SQL syntax that differs between engines, including quoting, limit clauses, date functions and full-text search. Also check for update hooks and schema definitions that use engine-specific types or indexes. Each hit should be classified as handled through the Database API, guarded by a driver check, or unsafe for PostgreSQL, because only the last group blocks the decision.
Confirm test coverage on PostgreSQL
A module that passes its own tests on MySQL says little about PostgreSQL. Ask whether the project runs automated tests against PostgreSQL, whether its continuous integration covers the Drupal versions you will run, and whether you can reproduce those tests in your own environment. Where coverage is thin, plan a smoke test of each feature that writes data, including imports, exports, reports and scheduled jobs, on a copy of the production database.
Price the patch or replacement
Cost depends on how many modules need work, how deep the change goes and whether your team or a partner maintains the fork. A patch that must be reapplied at every release adds recurring effort, while a replacement module brings its own configuration, data migration and testing. Ask any implementation partner for a fixed-scope estimate that lists each module, the chosen remedy, who owns the code after handover and how upgrades will be tested.
Decide before the build starts
Use the review results to choose the database before modules are configured around it. If every critical module runs cleanly on PostgreSQL, the decision rests on operational factors. If one essential module cannot run without changes and no alternative exists, that finding may settle the choice in favor of MySQL or MariaDB, so record the evidence with the architecture decision.
Why PostgreSQL search features need pg_trgm
Some search and matching features on PostgreSQL depend on the pg_trgm extension, which adds trigram-based text comparison to the database. If your Drupal platform uses PostgreSQL, confirm before build starts which contributed modules or search configurations need `pg_trgm`, because the answer changes what your database service must support. Check the module documentation on Drupal.org for each search or matching feature in scope, and record the requirement in your platform design. Do not assume a feature works on PostgreSQL just because the core database requirements are met.
Next, confirm that the extension can be installed where your database actually runs. On a self-managed PostgreSQL server, your DBA needs to install the extension package and create it in the Drupal database with appropriate privileges. On a managed database service, the provider controls which extensions are available and which roles can create them, so ask the provider to list pg_trgm as supported on your engine version and tier, and confirm who performs the installation. Note that the extension must be present in every environment that runs the same code, including restored copies used for staging and disaster recovery. The PostgreSQL versioning policy is a useful reference when you plan the engine version that the extension must support.
Test the search behavior in staging before you commit to PostgreSQL. Load a realistic content volume, run the exact search and autocomplete queries your editors and visitors will use, and compare results with the MySQL or MariaDB baseline if you are still deciding. Check index creation time, query performance after a restore, and behavior after a PostgreSQL major upgrade, since the extension must be reinstated or verified in the new cluster. Record the results and the installation steps in your runbook so that the dependency is visible to the team that will maintain the platform.
Setting up and validating the chosen database
This sequence takes the database decision from a written choice to a Drupal site that installs, updates cleanly and can be restored from a tested backup. Each step ends with a check that the reader can record as evidence before moving on.
Confirm target Drupal and database versions
Your team or DeployOpen's architect fixes the Drupal major version and the database engine and version together, using the Drupal system requirements and the PHP requirements for that Drupal release. Check that the chosen Drupal version supports the database version you plan to run, and that the PHP version meets the minimum for the Drupal release (Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, Drupal 12 requires PHP 8.5 or later). For PostgreSQL, confirm the major version is still within its support window, because support dates differ by version. Done when a signed version matrix exists and every component has a supported version listed against it.
Audit contributed modules for database-specific code
Inventory every contributed module and custom module, then search their code and issue queues for MySQL-specific queries, raw SQL and database-driver assumptions. Run Drupal's Upgrade Status check against the target version where it applies, and record each module's maintenance status and Drupal compatibility. Modules that need PostgreSQL-specific extensions, such as pg_trgm for trigram search, must be listed separately. Done when the audit produces a list of modules with a pass, replace or test-first decision, and the engineering lead has approved it.
Choose self-managed or managed hosting
Decide whether the database runs on servers you operate or on a managed service in your cloud account, and document the reason. Managed options need checks on the provider's supported engine versions, extension support (for PostgreSQL, confirm pg_trgm is available), backup retention, point-in-time recovery, maintenance windows and private networking. Self-managed options need an owner for high availability, pooling, patching and upgrades. Ask any provider or vendor to confirm these items in writing, because availability varies by service and region. Done when the hosting decision is recorded with the named owner for backups and upgrades.
Create the database and required extensions
Create the database, a dedicated application user with the least privileges Drupal needs, and the character set and collation the platform standard requires. For PostgreSQL, enable pg_trgm in the Drupal database if the chosen modules depend on it, and confirm the extension version after creation. Store credentials in your secrets system and keep them out of the Drupal codebase. Connection pooling, such as PgBouncer, is set up here if the design calls for it. Done when a test connection from the web tier succeeds, the extension list matches the module audit, and the credentials are stored outside the repository.
Install Drupal and connect it to the database
Install the Drupal codebase built with Composer into a non-production environment, pointing the settings file at the database through environment-provided values. Use the installer or a site install command appropriate to your Drupal version and database driver. Confirm the status report shows the database driver, version and any warnings about missing extensions. Done when the site installs, the status report has no database errors, and the install is recorded with the exact Drupal and database versions.
Run updates and configuration import
Import a copy of production content and files into the test environment if available, then run the database update process and the configuration import in the order your release process defines. Watch for module update hooks that fail on the chosen engine, and review each failure against the audit from step two. Repeat the update on a clean copy to confirm it is repeatable. Done when the update completes without errors, the configuration import reports no unexpected differences, and the test site passes the core functional checks your team defined.
Test backups and restores
Run a full backup with the method your platform team chose, such as logical dumps, physical backups or managed snapshots, and restore it into an empty environment. For PostgreSQL with point-in-time recovery, also test restoring to a chosen timestamp and confirm WAL archiving is running. Compare row counts or a checksum of key tables, and confirm the restored site loads and the files match. Time the restore and record the result. Done when a restore has been completed and verified, the recovery procedure is written down, and the owner has signed it off.
Security and operations for the database layer
Once the engine is chosen, the database layer needs decisions on who and what can connect, where credentials live, how data is recovered and how the service stays up. The cards below cover those decisions for a Drupal platform running on PostgreSQL, with the points to confirm before a build is signed off.
Choose a password method that uses SCRAM
PostgreSQL documents several client authentication methods, including password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth. For a Drupal database, the common choice is password authentication stored with SCRAM, since PostgreSQL 18 deprecated MD5 password authentication in its favor. Confirm which method your Drupal hosts, migration tooling and admin tools can all use before you set password_encryption and pg_hba.conf rules.
Use directory or certificate login for admins
Methods such as GSSAPI, LDAP, certificate and OAuth let administrators sign in with identities your organization already manages, instead of shared database passwords. This matters most for the people who can read the whole Drupal database, including support staff and migration engineers. Ask which method your identity provider and database client support, and who approves changes to the pg_hba.conf file.
Keep credentials out of settings.php
Drupal reads its database connection from settings.php, so a password written there ends up in the codebase, backups and build artifacts. Pass the connection details through environment variables or a secrets manager, and keep the file readable only by the web server user. Confirm how each environment, including CI and migration jobs, receives its credentials and how those credentials rotate.
Restrict network paths to the database
The database should accept connections only from the Drupal application tier, the migration host and approved admin paths. Place it on a private subnet or network segment, set listen_addresses to the required interfaces and limit each pg_hba.conf rule to specific hosts and users. A connection pooler such as PgBouncer can sit between the application and the database to reduce the number of direct connections you need to allow.
Plan backups and point-in-time recovery
A nightly dump does not give you a recovery point near the moment of an incident. Continuous archiving of WAL files allows point-in-time recovery to a chosen moment, but only if the archive is stored separately and restores are rehearsed. Ask for a documented restore test that covers the Drupal database and the file store together, because a restored database that points to missing files still fails.
Separate hot standby from automatic failover
PostgreSQL supports hot standby servers that answer read-only queries, and it offers synchronous replication, where a commit waits for standbys, and asynchronous replication. PostgreSQL does not detect a failed primary or promote a standby by itself, so automatic failover requires external tools that you must select, configure and test. Decide whether a manual promotion is acceptable for your recovery targets, and confirm who performs it and how Drupal is redirected.
How database major upgrades differ by engine
PostgreSQL minor releases are the routine patches within a major version. The PostgreSQL project states that minor releases never change the internal storage format, so applying one means replacing the executables and restarting the server. The data directory stays where it is, and no dump or conversion step is needed. Minor releases arrive at least once every three months, which makes them the part of database maintenance most likely to recur on a fixed cadence.
- No data conversion: A minor update replaces binaries and restarts the service; the data files are not rewritten.
- Frequent cadence: The project's versioning policy commits to minor releases at least once every three months.
- Drupal coordination: Schedule the restart alongside Drupal maintenance windows so that cache and database connections recover together.
- Standby order: Where replicas exist, patch and restart them in a planned order and confirm replication recovers before moving on.
- Rollback: Keep the previous binary package available so the team can return to the prior minor release if the restart fails.
Confirm the exact patch procedure, package source and restart sequence for your operating system and any managed service before the first maintenance window.
Major upgrades change the on-disk format, so they need a deliberate migration path. The PostgreSQL upgrading documentation describes three routes: dump and restore with pg_dumpall, in-place conversion with pg_upgrade, and logical replication from the old version to the new one. Dump and restore is the simplest to reason about but takes the longest for large databases. Logical replication works between different major versions and can cut the cutover to several seconds of downtime, although it adds setup work and needs verification before the switch.
- Dump and restore: Simple and well understood, but downtime grows with database size.
- pg_upgrade: Converts the data directory in place; PostgreSQL 18 retains planner statistics across major upgrades and adds parallel jobs and a --swap option.
- Logical replication: Allows a switchover with only several seconds of downtime, according to the upgrading documentation, once the replica is caught up.
- Extensions and configuration: Check that extensions such as pg_trgm exist on the new version and that Drupal's database driver settings still match.
- Test restores: Rehearse the chosen route against a copy of production data and time it before committing to a window.
Run the chosen method in a staging environment with a production-sized copy, then confirm row counts, Drupal status reports and search indexes before cutover.
PostgreSQL publishes a fixed support window for each major version. The versioning policy states that each major version is supported for 5 years after its initial release. PostgreSQL 18 was first released on September 25, 2025 and is supported until November 14, 2030. Version 17 is supported until November 8, 2029, version 16 until November 9, 2028, and version 15 until November 11, 2027. Version 14 is supported until November 12, 2026, so a platform built on it must plan its move to a supported major version before that date. Versions 13 and earlier are no longer supported.
- Version 14 deadline: Support ends on November 12, 2026, so the upgrade needs to be scheduled and tested well before it.
- Newest line: Version 18 is supported until November 14, 2030, which gives the longest runway for new builds.
- Annual major releases: A new major version arrives about once a year, so a Drupal platform should plan a recurring upgrade cycle rather than a single project.
- Unsupported versions: Versions 13 and earlier receive no fixes; confirm the version in use with a query against the running server.
- Vendor timing: Managed services may publish their own support dates; confirm those separately from the community dates.
Record the current major version, its end-of-support date and the owner of the upgrade in the platform's operations calendar.
The supplied research does not cover the MySQL and MariaDB upgrade procedures, release timelines or support windows, so this tab cannot state them. Drupal supports both engines alongside PostgreSQL, and the upgrade path depends on which distribution, release line and hosting model the organization uses. Oracle's MySQL and the MariaDB project publish their own lifecycle policies, and cloud providers may add separate dates for managed instances. The Drupal system requirements page is the place to confirm which versions the current Drupal release accepts.
- Release line: Confirm which MySQL or MariaDB line is in use and whether it is still receiving fixes.
- Upgrade method: Ask the vendor or distribution maintainer which in-place or dump-based upgrade method they document.
- Drupal compatibility: Check the supported database versions for the Drupal release you plan to run.
- Managed service dates: Ask the cloud provider for its end-of-support and forced-upgrade schedule.
- Replication and rollback: Confirm how replicas and backups are handled during the upgrade and how to roll back.
Before comparing engines on upgrade effort, get written answers from your database vendor or provider for each item above.
Whichever engine the platform uses, the upgrade decision becomes a recurring operational task. Drupal's own release cycle and the database's support window run on different clocks, so the two need to be planned together. A PostgreSQL major upgrade can be scheduled against the published end-of-support dates, while minor patches and Drupal security releases follow their own rhythm. Keeping these in one calendar helps the team avoid combining a database cutover with a Drupal major upgrade in the same window.
- Separate changes: Avoid performing a database major upgrade and a Drupal major upgrade in the same maintenance window.
- Backup before change: Take and test a backup immediately before any major database change.
- Staging parity: Keep staging on the same engine and major version as production so rehearsals are meaningful.
- Ownership: Name the team responsible for each database upgrade and its sign-off criteria.
- Quote scope: When asking a partner for a quote, request the upgrade route, testing, rollback plan and the number of environments covered.
Review the database support dates against the Drupal release schedule at least once a year and adjust the plan when either changes.
Limits to confirm before committing to an engine
Database choice for Drupal depends on constraints that change by release, module and provider. The cards below list what to verify in your own environment before you commit, because each one can override a general preference for MySQL, MariaDB or PostgreSQL.
Exact minimums for your Drupal version
Drupal runs on MariaDB, MySQL, PostgreSQL or SQLite, but the supported engine versions can differ by Drupal release. Confirm the minimum database version that matches the Drupal core you plan to run, and check it against the versions your hosting provider offers, not only the versions listed in general documentation. Record the result in the decision document so the upgrade plan for future Drupal releases can be checked against it.
Contributed module database compatibility
Some contributed modules include code written for one database engine. Before you commit, list every contributed module on your build and check its issue queue and code for engine-specific queries, SQL functions or schema assumptions. Ask your development partner to test the full module list on the engine you choose, because a module that works on MySQL may need changes on PostgreSQL, and the reverse is also true.
Extension support on managed services
If you plan to use a managed database, confirm that the service offers every PostgreSQL extension your site requires, including pg_trgm for trigram-based search. Extension availability differs between providers and sometimes between versions of the same service. Ask the provider for the exact list of supported extensions and versions, and test the Drupal install and search functions on that service before you rely on it.
Licensing and support terms
Drupal itself is GPL-2.0-or-later with no paid edition, but the database engine and its hosting carry their own terms. PostgreSQL uses a permissive license, while MySQL and MariaDB have different commercial and distribution arrangements. Confirm with your vendor or provider which support contract covers your engine, who answers for production incidents, and what support windows apply to the version you run.
Replication and failover behavior
High availability is not automatic on any engine you pick. Confirm how your chosen setup handles primary failure, including whether automatic failover is included, which external tools are needed, and how Drupal reconnects to a new primary. Test the failover path under your own configuration, since the behavior depends on how replication, connection pooling and health checks are set up.
Performance under your own load
Published comparisons rarely match your query mix, data size or concurrency. Run a load test that uses your real content model, search configuration, cron and editorial traffic, and measure query latency and connection use on each candidate engine. Use the results, not general reputation, to decide whether the engine meets your sizing targets and your upgrade windows.
Questions teams ask before choosing a Drupal database
Is MySQL or PostgreSQL better for Drupal?
Neither engine is better for every Drupal site, and both are listed by Drupal.org as supported database options alongside MariaDB and SQLite. The right choice depends on the Drupal release you plan to run, the contributed modules you depend on, the database services your hosting provider already runs well, and the skills your operations team has. Start by checking which engines your chosen modules support and which versions your platform team can patch on schedule. The Drupal system requirements page is the starting point for supported engines.
How much does it cost to move a Drupal site from one database engine to another?
No fixed figure applies, because the cost depends on the work around the data move rather than the copy itself. The main drivers are the number of custom modules with engine-specific SQL, contributed modules that behave differently per engine, the size and shape of the content and revision history, the number of environments to rebuild, and how much testing the business requires before cutover. Ask any partner to break a quote into discovery, code changes, data migration, testing and cutover, and to state which items recur after launch, such as patching and backup verification.
How long does a database decision take for a Drupal platform?
The decision itself can be short, but the evidence behind it takes longer. Teams usually need to inventory contributed and custom code for engine-specific queries, confirm the minimum database versions for their target Drupal release, and test the shortlisted engine against a realistic copy of the site. Duration rises when several sites share one database platform, when compliance reviewers must approve a new engine, or when the team has no existing operations experience with it. Ask for the decision criteria and the test plan in writing before agreeing a timeline.
What does the client team need to provide for the database work?
The work needs named owners on your side for decisions and access. Typically this includes a platform or infrastructure owner who can provision database hosts or managed services, a security contact who approves encryption, network paths and credential storage, and an application owner who can confirm which content, users and integrations must keep working. Your team should also provide a current inventory of contributed modules, custom code, cron schedules and backup arrangements, plus a staging environment that can hold a production-sized copy of the data.
Can our own team choose and install the database without a partner?
Yes, many teams do this in house, provided they have the operations skills to run the engine after launch. Drupal installs against MariaDB, MySQL, PostgreSQL or SQLite, so the install step is rarely the hard part. The harder work is the decision evidence, high availability design, backup and restore testing, and upgrade planning for the engine itself. Teams that lack this experience often choose a partner for a fixed-scope review, then run the platform internally. Confirm your team's capacity for patching and restore testing before deciding.
Do managed database services change the effort of choosing a Drupal database?
Managed services shift effort rather than remove it. The provider usually handles host provisioning, some patching and backup tooling, which reduces operational work for your team. However, you still need to confirm which engine versions the service offers, which extensions and authentication methods it enables, how replication and failover behave, and how restores are tested. Those checks depend on the provider and the engine release, so ask the vendor for their current support matrix. Managed or self-managed, the Drupal side of the decision (module compatibility and supported versions) is unchanged.
Which PostgreSQL version should a new Drupal platform target?
Pick a PostgreSQL major version that is still in its support window for the whole planned life of the site, and confirm it against your Drupal release requirements. PostgreSQL 18 was first released on September 25, 2025, and is supported until November 14, 2030. Versions 17, 16, 15 and 14 are supported until November 8, 2029, November 9, 2028, November 11, 2027 and November 12, 2026 respectively, so older versions will need upgrades sooner. Check the PostgreSQL versioning policy before choosing, and plan the upgrade path into the budget.
How DeployOpen scopes the database decision
DeployOpen scopes the database choice as a written, fixed-scope engagement that starts from the platform you already run or plan to run. The first step is a review of your Drupal version, your PHP runtime, the contributed modules you depend on and the hosting model. Because the database must match the Drupal release you target, the review checks the version minimums for MariaDB, MySQL and PostgreSQL against that release, and it flags any contributed module that carries MySQL-specific code or needs a PostgreSQL extension such as pg_trgm. Where the answer depends on facts the review cannot settle alone, such as your managed database service's supported versions, DeployOpen lists the items your team must confirm with the vendor before the decision is final.
The output is a written decision record that names the chosen engine and version, the reasons for it, the rejected options and the risks you accept. DeployOpen then implements the choice in your infrastructure, which can include the database build, connection settings, backups and restore tests, and any module changes needed for the engine you pick. Testing covers a restore into a non-production copy, a run of your critical Drupal paths against that copy, and a check of the upgrade route for the next major release. DeployOpen hardens and documents the result so your operations team can maintain it. Quotes follow the written scope, and DeployOpen does not publish a price list.
After launch, the database is one component among many, so ongoing support is often arranged as a retainer covering patching, backup verification, Drupal core and contributed module updates, and planned database upgrades. Ask any partner, including DeployOpen, to state in the quote which tasks are one-time, which recur, who holds administrative access, and how incidents are escalated. Those answers decide whether the database choice stays sound over the life of the platform.
