MariaDB vs PostgreSQL

Before comparing features, read your app's documentation. A growing number of self-hosted projects support only PostgreSQL: Immich, Authentik, Paperless-ngx, and many others assume it and use Postgres-specific features. Others, especially older PHP applications and WordPress, expect MySQL or MariaDB. Some support both and let you pick at install time.

If the app requires one, that is your answer and the rest of this is academic. The comparison below matters when an app supports both, or when you are choosing a database for something you are building yourself. Do not fight an app's recommended database to satisfy a preference; you will hit untested paths and thin documentation.

MariaDB is a fork of MySQL created by its original authors, and it stays largely drop-in compatible. If an app was written for MySQL, MariaDB almost always runs it unchanged, which is why distributions and self-hosted apps adopted it widely. It is the M in countless LAMP stacks.

Its strengths are simplicity and read-heavy web performance. For a WordPress site, a forum, or a typical CRUD app that reads far more than it writes, MariaDB is fast, light, and familiar, with a huge pool of documentation and tooling built up over the MySQL years. Setup is straightforward and the mental model is uncomplicated, which matters when the database is just a dependency you want to forget about.

PostgreSQL is not a MySQL relative; it is its own lineage with a reputation for correctness and depth. It is stricter about data types and constraints, which catches bad data at the door instead of letting it in. For anything where data integrity matters, that strictness is a feature.

It also carries more capability. JSONB stores and indexes JSON efficiently, so you get document-style flexibility with real query performance. Window functions, common table expressions, rich types (arrays, ranges, custom types), and extensions like PostGIS for geospatial data make complex queries and specialized workloads far nicer than on MySQL-family databases. As projects grow in data complexity, this is why so many standardize on Postgres.

For homelab-scale workloads, raw performance is rarely the deciding factor, because both are fast enough that your disk, your app code, or your query design will be the bottleneck long before the engine is. Benchmarks that show one beating the other usually reflect a specific workload and tuning, not a universal winner.

The rough generalization: MySQL-family databases have a reputation for very fast simple reads, while PostgreSQL shines on complex queries and heavy concurrent writes thanks to its mature concurrency control. Unless you are running something genuinely large, choose on features and compatibility, not on benchmark numbers you will never reach.

Both are well-supported and easy to run in a container, which is how most homelabs deploy them. Each app typically gets its own database instance in its compose stack, so you are not running one shared server. That keeps versions and backups isolated per app.

Back them up with the native tools: mysqldump or mariadb-dump for MariaDB, pg_dump for PostgreSQL, on a schedule, plus a copy of the dumps in your normal backup rotation. Do not just snapshot the data directory of a running database and assume it is consistent. A scheduled logical dump is the reliable, restorable approach, and it is worth testing a restore before you need one.