PostgreSQL vs MySQL vs MariaDB: which to choose

PostgreSQL vs MySQL vs MariaDB: which database fits your self-hosted application

For a new build on a permissive license, choose PostgreSQL. Choose MySQL or MariaDB when MySQL compatibility or an existing estate decides the question. That answer holds for most teams, but it only becomes a decision once you have checked the application itself. Many self-hosted products ship with a supported list of database engines, and some ship only MySQL or MariaDB drivers, stored procedures or SQL modes. Start by reading the vendor's supported database matrix for your application version, then list every SQL dialect feature, authentication method and extension the application relies on. Only after that does licensing, release policy and high availability design come into play.

On licensing, PostgreSQL is released under the PostgreSQL License, a liberal license similar to BSD or MIT, and supports each major version for 5 years after its initial release. MySQL Community Edition is available under the GPL and follows an LTS track and an Innovation track, with the Innovation releases supported only until the next Innovation release. MariaDB Server is GPLv2, and its maintainers say it will remain free and open source. For high availability, PostgreSQL provides hot standbys and synchronous or asynchronous replication, but it does not supply automatic failover, so you must plan an external tool such as Patroni. MySQL Community Edition includes InnoDB Cluster and Group Replication with automated failover, while MariaDB offers Galera synchronous multi-primary clustering. Paid features differ: MySQL Enterprise Edition adds Enterprise Backup, Transparent Data Encryption and Enterprise Audit, and you should confirm whether your team needs any of them before assuming a paid tier.

Migration effort is the cost that is hardest to reverse, so ask your application vendor and your DBA team three things before you commit: which database versions are certified, which engine-specific features the schema uses, and how the team will run upgrades. A switch from MySQL to PostgreSQL usually requires schema and query changes and a data migration plan, while MariaDB is more compatible with MySQL applications but diverges in places you should verify against the release you intend to run. Confirm the support window for the exact release you plan to deploy in the vendor's documentation, and document the decision with a short compatibility test in your own environment.

Which database fits which scenario

This table maps common self-hosted scenarios to the database that fits best and the supplied fact behind that choice. Read each row as a starting point, then confirm the named requirement with your application vendor before committing to a migration.

Scenario	Best fit	Reason and what to confirm
New application with no legacy constraints	PostgreSQL	PostgreSQL uses the permissive PostgreSQL License and supports each major version for 5 years after release. Confirm your team's need for the specific extensions and features you plan to use.
Existing MySQL application	MySQL or MariaDB	MariaDB keeps a high degree of MySQL compatibility, and MySQL is the upstream engine. Confirm with the application vendor which MySQL version and SQL mode it certifies before any upgrade.
Need for Galera synchronous multi-primary	MariaDB	The MariaDB Server README lists Galera synchronous multi-primary clustering. Confirm with the vendor that the application tolerates multi-primary write conflicts and that your team can operate Galera.
Need for a native vector data type	PostgreSQL or MariaDB	MariaDB lists a native VECTOR type with HNSW indexing since 11.8. Confirm the vector dimensions, index type and recall needs your application requires, and test them on your target version.
Need for Oracle support or Enterprise features	MySQL	MySQL Enterprise Edition adds Enterprise Backup, Transparent Data Encryption, Enterprise Audit and 24x7 Oracle support. Confirm the current subscription terms and which features your compliance controls actually require.
Team that wants a single GPL-family fork	MariaDB	MariaDB Server is GPLv2 and the MariaDB Foundation states it will remain free and open source software independent of any commercial entity. Confirm the license terms of any plugins or storage engines you depend on.

What each database licenses, offers and charges for

PostgreSQL is released under the PostgreSQL License, a permissive license similar to the BSD and MIT licenses. The supplied facts do not describe a paid PostgreSQL edition, so the software itself carries no license fee and no vendor-run enterprise tier. Commercial support, when you want it, comes from third parties, and the cost structure is therefore set by the people you hire rather than by the license.

License terms: The PostgreSQL License permits use, modification and redistribution with few conditions, so there is no per-core or per-node license fee to budget.
Recurring cost: Any support contract, managed hosting or retained operations service is paid to a third party and recurs according to that contract.
One-time cost: Design, initial deployment, high availability tooling and migration work are typically one-time, though they may be bundled into an ongoing retainer.
Support options: Ask each third-party provider which PostgreSQL major versions they cover and how they handle the five-year support window per major version.
Tooling: High availability, failover and backup tools are separate open-source projects, so their licenses and any paid support must be checked individually.

Confirm with each support provider whether their fees cover the specific tooling in your stack, since the database license alone does not settle that question.

How long each release line stays supported

PostgreSQL gives a self-hosted team the most predictable maintenance calendar of the three. Each major version is supported for five years after its initial release, and a new major version arrives about once a year. The supported set is 14 through 18: 14 ends November 12, 2026, 15 ends November 11, 2027, 16 ends November 9, 2028, 17 ends November 8, 2029, and 18 ends November 14, 2030. Minor releases arrive at least every three months and never change the storage format, so they are executable replacements followed by a restart. Plan the move off 14 before November 2026, choosing between pg_upgrade and logical replication based on how much downtime your application tolerates. The PostgreSQL versioning policy is the document to check against your change calendar.

MySQL Community Server runs two tracks with different calendars. LTS releases, such as 9.7.2 and 8.4.11 on the current download page, receive five years of premier support and three years of extended support under Oracle's Lifetime Support Policy. Innovation releases, such as 26.7.0, are supported only until the next Innovation release, so a team on that track must upgrade on Oracle's schedule or leave the supported line. Features are added only in the first release of an LTS series, and later point releases carry necessary fixes, which makes the LTS track the better fit for a fixed maintenance calendar. The supplied facts do not give an end-of-support date for 8.0.46, so confirm it with Oracle before standardizing on that line.

MariaDB publishes one long-term release each year. Community binaries for an LTS release are supported for three years after general availability, followed by two more years of critical and security fixes, so the binaries and the fixes end on different dates. MariaDB 12.3 is the current LTS, with a general availability date of May 28, 2026, and 11.8, 11.4 and 10.11 remain maintained LTS lines. Rolling releases arrive quarterly, and 13.0 reaches community end of life in Q4 2026, which suits teams that accept frequent upgrades. For a self-hosted calendar, pin production to an LTS line, schedule the yearly move, and confirm the exact fix window for each branch with the MariaDB Foundation before you set the maintenance budget.

What drives the running cost of each database

The three engines are free to download, so the running cost comes from people, support and upgrades rather than from the license. Each card below names one cost component, who gets paid for it, whether it is one-time or recurring, and what to request in a quote.

Engineers who operate HA tooling

Replication, failover and split-brain handling are the largest recurring cost for most teams. PostgreSQL does not detect a failed primary or promote a standby on its own, so you add external failover tooling and staff who understand it. MySQL Community ships Group Replication with automated failover and MariaDB offers Galera clustering, which change the skills you need. Ask a quote to separate the one-time build from the ongoing on-call and review hours.

Backup and point-in-time recovery

Backup tooling is a recurring operational cost because restores must be tested, not just scheduled. PostgreSQL relies on continuous archiving of WAL for point-in-time recovery, and MySQL Enterprise Edition adds Enterprise Backup for hot backups. Storage for archives and retention periods grow with change rate. Ask what is set up once, what runs on each restore test, and who owns the recovery runbook.

Upgrade effort per release cadence

Upgrade work recurs on the vendor's release calendar, and the calendars differ. PostgreSQL ships a new major version about once a year and supports each major for 5 years. MySQL offers LTS and Innovation tracks, and MariaDB has yearly LTS releases with rolling releases in between. Count the effort of testing, scheduling and rolling each upgrade across every database you run. Ask whether the quote covers major upgrades or only minor patching.

Connection pooling and extensions

Connection pooling and extension management add setup and testing work that the engine itself does not cover. PostgreSQL connection costs often call for a pooler such as PgBouncer in front of the cluster, and each extension you rely on must be validated on each major upgrade. MariaDB adds its own storage engines and vector indexing, which also need testing. Ask who installs and patches the pooler and which extensions the quote covers.

Enterprise Edition and commercial support

Paid features and vendor support are the only license-like costs, and they are priced separately from the database. MySQL Enterprise Edition adds features such as Transparent Data Encryption, Enterprise Audit and 24x7 Oracle support. PostgreSQL and MariaDB Server are free under liberal licenses, so any paid support comes from a third party. Ask whether the quote includes a support contract, which features it depends on and whether pricing renews each year.

Which application compatibility questions decide a migration

The compatibility question decides most migrations, and it has a different answer for each target. Moving between MySQL and MariaDB is usually the smallest change because MariaDB's README states that it keeps a high degree of MySQL compatibility, but that statement describes the project's intent, not a guarantee for your schema. Start with an inventory: list every stored procedure, trigger, view and event, every use of MySQL-specific syntax, and every data type your application reads or writes. Then run the application's test suite and its most important queries against a MariaDB build of the version you plan to deploy. Pay particular attention to stored routines, since MariaDB's Oracle SQL mode with PL/SQL-style routines is a separate dialect you must enable deliberately, and to features such as the native VECTOR type that exist only on one side.

Drivers and authentication are the next checks, and they fail quietly. MySQL Community Edition lists ODBC, JDBC and .NET connectors, and you should confirm that each client library in your stack has a supported build for your target server and that it negotiates the authentication method your users actually use. MariaDB's README lists ed25519, PAM and GSSAPI among its pluggable authentication options, so verify those in your own environment rather than assuming the same accounts will log in unchanged. Check TLS settings and certificate handling too, because connection strings and driver defaults often differ between products.

Migrating to PostgreSQL is a different exercise. Expect to test SQL dialect differences, identifier quoting, implicit type conversions, case sensitivity, date and time handling, and the data types your schema uses, and to rewrite any queries that depend on MySQL-specific behavior. Ask the application vendor or your development team to confirm each item against the real code path. For future upgrades within PostgreSQL, logical replication works between different major versions and, as the PostgreSQL upgrading documentation describes, allows a major upgrade with only several seconds of downtime. Confirm with your own workload that the tables you replicate and the objects you must recreate, such as sequences and DDL, are covered by your plan.

How a database selection and rollout typically runs

The sequence turns a database preference into a supported, recoverable production service. Each step produces a written decision or a tested artifact that the next step depends on.

Inventory application compatibility first
Your application and engineering team list every application that will use the database, the drivers and ORMs each one uses, the SQL features and stored routines it depends on, and any vendor-supplied database requirements. DeployOpen can run this inventory as a scoped discovery task if you want an outside read of the code and schema. The step is done when you have a signed list that marks each application as portable, portable with changes, or tied to one engine. That list usually decides the choice more than any feature table does.
Pick the license and support model
Using the inventory, your legal, procurement and platform leads compare the license terms, the release tracks and the support windows of PostgreSQL, MySQL Community Server and MariaDB Server. Confirm with each vendor whether any feature your team needs sits only in a paid edition, and get the terms in writing. The output is a decision record that names the engine, the release track you will run, and the owner of security patches. Revisit this record whenever a support window approaches its end.
Decide the high availability design
Choose how the database fails over and how reads are served. Options include streaming replication with an external failover tool on virtual machines, a Kubernetes-hosted operator, a built-in group replication or cluster product, or a single instance with restore-based recovery. Your platform team states the recovery expectations for each application, and DeployOpen can document the topology and failover runbook under a fixed scope. The step closes with an architecture diagram and a runbook that names who acts during a failover.
Test backup and point-in-time recovery
Before any production data arrives, restore a full backup to a separate environment and replay logs to a chosen point in time. Record how long the restore takes, which steps were manual, and whether the restored data matches the source. Your operations team owns the storage target and retention settings, and DeployOpen can script and verify the restore procedure under a written scope. The step is done when a restore has passed a documented check and the result is filed with the design record.
Run a pilot with representative data
Load a copy of production-shaped data, replay representative queries and writes, and run the application test suite against the chosen engine. Measure failover behavior, connection handling and replication lag under load, and capture each difference from the compatibility inventory as a tracked item. Your application owners decide which differences are acceptable and which require code changes. The pilot is complete when every open item has an owner and a disposition, and the application owners sign off on the result.
Plan the upgrade calendar
Map the chosen release track and its support dates onto your change calendar, and decide how minor updates and major upgrades will be applied. Confirm the upgrade method for your version pair, such as dump and restore, in-place upgrade, or logical replication, and rehearse it in a non-production environment. DeployOpen can prepare the calendar, rehearsal scripts and rollback steps as a fixed-scope deliverable, while your team keeps ownership of production change approval. The step closes with a dated upgrade plan that is reviewed each time the vendor publishes a new release.

Questions buyers ask before choosing and implementing a self-hosted database

How much does it cost to run PostgreSQL, MySQL or MariaDB yourself?

The software licenses for all three are free to use, so the cost sits in people, infrastructure and any paid support or enterprise features. PostgreSQL is released under the PostgreSQL License, MySQL Community Edition is available under the GPL, and MariaDB Server is GPLv2, so a self-hosted deployment has no license fee for the core server. The recurring costs are the servers or cloud capacity, the backup storage, monitoring, staff time for patching and upgrades, and any vendor support subscription you choose. Ask for a quote that separates one-time work (design, migration, hardening, documentation) from recurring work (upgrades, backup testing, on-call support) and states which database versions each line covers.

How much effort does a highly available database setup take?

Effort depends on the failover design and on who runs it, not on the license. PostgreSQL offers hot standbys with synchronous or asynchronous replication, but the PostgreSQL documentation notes that automatic failover needs external tools, so you add a manager such as Patroni or an operator on Kubernetes. MySQL Community Edition includes InnoDB Cluster and Group Replication with automated failover, and MariaDB offers asynchronous and semi-synchronous replication plus Galera clustering. The effort drivers are the number of nodes, the fencing and split-brain design, backup and restore testing, and the skills your team already has. Ask the implementer to describe the failover runbook and the test evidence for failover and restore before accepting a quote.

Can our own team run the database migration without outside help?

Yes, many teams do, provided they have the skills and time to test thoroughly. A same-engine upgrade is usually simpler than a change of engine, and PostgreSQL's documentation describes three major upgrade paths: dump and restore, pg_upgrade, and logical replication, which can cut downtime to several seconds. The work that tends to take longest is the application side: SQL dialect differences, stored logic, driver settings, and performance tests against realistic data. Keep in mind that a migration needs a rehearsal, a rollback plan and a reconciliation step. If your team has not run a major database migration before, ask a partner to scope the work in writing, with deliverables and test criteria agreed before work starts.

What does a MySQL to PostgreSQL migration require?

A MySQL to PostgreSQL migration is a change of engine, so it requires a schema and SQL review in addition to the data copy. Expect work on data type mapping, auto-increment and identifier handling, stored procedures and triggers, SQL functions that differ between the two engines, and the connection and ORM layer of the application. Plan for a test environment that mirrors production load, a cutover window, and a way to validate row counts and business results on both sides. The effort scales with the number of applications, the amount of database-side logic, and the number of integrations that read the database directly. Ask for an inventory of those dependencies in the scope document before agreeing a fixed price.

Which open-source database has the longest support window?

PostgreSQL has the most predictable window for the community project. Each major version is supported for five years after its initial release, and the current versions run to dates published in the PostgreSQL versioning policy, with version 18 supported to November 14, 2030. MySQL offers an LTS track with five years of premier and three years of extended support under Oracle's Lifetime Support Policy, while its Innovation releases are supported only until the next Innovation release. MariaDB publishes yearly LTS releases with three years of community support after GA and two more years for critical and security fixes. Check the dates for the exact version you plan to run, because a longer window on paper does not help if you are on a release that is near its end.

What does the work need from our staff after go-live?

After go-live, the database needs regular patch cycles, backup and restore tests, monitoring of replication lag and disk growth, and capacity planning. PostgreSQL minor releases come at least once every three months and do not change the storage format, so they are typically a replace-and-restart task, while major upgrades need a planned project. Your staff should be able to read logs, run failover drills, manage roles and certificates, and respond to incidents at the hours your service requires. Define who owns each of these tasks in a RACI table before go-live. If the team cannot cover the on-call hours, decide whether to add a retainer for upgrades, testing and support.

Do we need the paid enterprise features from MySQL or MariaDB?

Only if a specific requirement maps to a feature that the free edition lacks. MySQL Enterprise Edition adds features such as Enterprise Backup for hot backups, Transparent Data Encryption, Enterprise Audit and Enterprise Firewall, along with 24x7 Oracle support. MySQL Community Edition already includes InnoDB Cluster, replication and MySQL Router. MariaDB Server lists role-based access control, data-at-rest encryption, TLS and Galera clustering in its open-source distribution, so compare those requirements directly. For PostgreSQL, the authentication methods listed in its documentation include LDAP, GSSAPI, certificates and OAuth without a paid edition. Write down the audit, backup, encryption and support requirements from your compliance and risk owners, then check each against the edition you would run before deciding whether a paid tier is needed.

What should a quote for self-hosted database work include?

A useful quote lists the scope, deliverables, environments, database versions and timelines in writing before work starts. DeployOpen does not publish a price list, and most engagements are fixed-scope, so the quote follows from the written scope rather than a standard rate. Ask the proposal to cover the design of the high availability layout, backup and restore testing, the migration plan if one is needed, the application compatibility review, documentation and handover, and any recurring support or upgrade retainer. Ask which items are one-time and which recur, and which versions are covered after the support window closes. Ask for the test evidence each deliverable will produce, so you can check the work after handover.

Official sources for PostgreSQL, MySQL and MariaDB

Start with the primary pages for each database, because licence, support and release terms change over time and the answers you need are in the vendor's own words. For PostgreSQL, the PostgreSQL licence page confirms that the database ships under the PostgreSQL License, a permissive license similar to BSD or MIT, and the PostgreSQL versioning policy sets out the support window for each major version. For MySQL, the MySQL Community Edition page describes the GPL-licensed download, and the MySQL Enterprise Edition page lists the features that sit behind a paid subscription. For MariaDB, the About MariaDB Foundation page explains the Foundation's governance and its commitment to keep MariaDB Server GPLv2 licensed.

Use the release and high availability pages to test the support assumptions you will carry into operations. The MySQL releases section of the 8.4 reference manual explains the LTS and Innovation tracks, and the MySQL Community Server downloads page shows which series are currently offered. The MariaDB/server releases page records each published build, so compare its dates with the community support terms you find in the Foundation's materials. On the PostgreSQL side, the high availability documentation confirms that streaming replication and hot standbys are built in, while the failover documentation states that automatic failover needs external tools. Confirm that your chosen failover tooling is supported on the exact database version you deploy.

Record the dates and version numbers you rely on, then recheck them before signing a quote or a migration plan, since point releases and support windows move. Ask your DeployOpen scoping contact or your database vendor to confirm which version your applications need, whether the Enterprise features you expect are included in the Community build, and which support terms apply to your environment. Keep a dated copy of each page in your change record so that the licence and support position you approved is traceable at audit time.

How DeployOpen helps choose and implement a database

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For PostgreSQL vs MySQL vs MariaDB, we start from the application's compatibility needs, release windows and high availability requirements, then build and hand over the chosen engine in your environment.

How we scope

Written scope covering which engine, versions, hosting model and application workloads are in and out of the work.
Review of application SQL, drivers, ORM behavior and stored routines before any engine choice is treated as final.
Agreed list of which features you need, such as replication, backups or encryption, and which edition each requires.

How we build

Deployment of the selected database on your VMs, data centers or Kubernetes clusters, using your identity and network controls.
High availability design for replication and failover, including any external tooling needed for automatic failover.
Backup and restore configuration tested against a documented recovery target, with a runbook for each engine in scope.

How we hand over

Documentation of configuration, upgrade paths, supported release tracks and the end-of-life dates your team must track.
Knowledge transfer so your operators can run patching, minor upgrades and major version migrations without us.
Security testing and compliance evidence prepared for your assessors, while independent auditors issue any formal reports.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Scheduled reviews of supported versions, so migrations are planned well before a release reaches end of life.
Quotes follow from the written scope, so ask for line items covering design, build, testing, documentation and retainer hours.

PostgreSQL vs MySQL vs MariaDB