MariaDB vs. PostgreSQL for Self-Hosted SMBs

If your mid-sized business runs its own applications — Nextcloud for the team, GitLab for development, Mailcow for communication, maybe a self-hosted ticketing system on top — sooner or later the question comes up: MariaDB or PostgreSQL? Both are mature, open source and run without licensing cost inside an LXC container or VM on your Proxmox cluster. The real difference is not synthetic benchmarks — it is daily operations, feature set, and which applications you actually deploy.

This article is aimed at SMB IT decision-makers who want to make a deliberate choice rather than “we have always used MySQL”. We look at typical self-hosting stacks, the characteristic strengths of each database, backup strategies and the most common migration pitfalls.

Where MariaDB is still the right pick

MariaDB is the community-maintained MySQL fork and has established itself as the de-facto standard in the PHP ecosystem. If your stack is built on classic web applications, MariaDB is often the frictionless choice: Nextcloud is optimised for MariaDB/MySQL and most tuning guidance is written against it. WordPress multisite installations, Kimai for time tracking, older ticketing systems such as OTRS Community Edition or Zammad in default configuration — all of these run “as expected” on MariaDB.

Practical benefits we see:

• Resource footprint: A MariaDB instance for a 30-user Nextcloud is very comfortable inside a 2-vCPU/4-GB LXC.
• Backup tooling: mariabackup delivers consistent hot backups without heavy preparation; mysqldump remains the pragmatic solution for small databases.
• Operational familiarity: Almost every Linux admin has typed mysql -u root -p before. For small teams without a dedicated DBA this noticeably lowers the entry barrier.
• Compatibility: Classic PHP applications expect the MySQL dialect. Prepared statements, AUTO_INCREMENT, ENGINE=InnoDB — works out of the box.

Our current version recommendation is MariaDB 11.4 LTS (support until May 2029). The 10.11 LTS branch is still running on some legacy systems in the field, but new installations we deploy on 11.4.

Where PostgreSQL clearly pulls ahead

PostgreSQL is the right pick as soon as your application wants more than “write data into tables”. GitLab runs on PostgreSQL only — MySQL support was removed back in 2019. Modern DMS and ERP solutions such as Odoo, Metabase for BI dashboards, Discourse as a community forum, most Python/Django applications and practically anything in the GIS space either require Postgres or strongly recommend it.

The technical advantages that are genuinely noticeable in SMB projects:

• JSONB: You can store structured JSON documents in a column and still query them via indexes. For applications with semi-flexible data structures — configuration objects, API responses, log aggregation — this is a real game changer and a common reason development teams pick Postgres.
• PostGIS: A fully featured geographic extension. If you store locations, routes or zones, PostGIS is unbeatable. MariaDB has GIS functions, but the feature scope is well behind PostGIS.
• CTEs and window functions: Both databases handle these by now, but Postgres has the head start — complex analytical queries are more readable and the optimiser handles them more confidently.
• Extensibility: pg_stat_statements for query analysis, pgvector for embeddings in AI applications, pg_cron for scheduled jobs inside the database.
• Stricter standards: Postgres insists on data types and constraints. That protects against garbage data but requires a shift in thinking if you come from the MySQL world.

Current recommendation: PostgreSQL 17 for new installations, PostgreSQL 16 as a fallback if your application does not yet officially support 17.

Typical self-hosting stacks compared head-to-head

To make the decision more tangible — here is an overview of common applications and our pragmatic recommendation:

Application	Support	Our recommendation	Note
Nextcloud	MariaDB, PostgreSQL	MariaDB	Docs and community knowledge are MariaDB-heavy
GitLab	PostgreSQL only	PostgreSQL	no choice — Postgres 14+ required
Mailcow	MariaDB (hard-wired)	MariaDB	the Docker Compose stack ships MariaDB
Odoo	PostgreSQL only	PostgreSQL	typically Postgres 15/16
WordPress	MariaDB/MySQL	MariaDB	pure PHP ecosystem
Zammad	PostgreSQL recommended	PostgreSQL	MySQL support has been discontinued
Bookstack, Kimai	MariaDB/MySQL	MariaDB	LAMP classics
Metabase, Grafana	both, often SQLite/Postgres	PostgreSQL	for reliable production use
Vaultwarden	SQLite default	PostgreSQL if needed	worthwhile for teams >20

The practical rule: run both systems in parallel if your stack demands it. Two LXC containers on a Proxmox host with clean resource limits are not a problem and cleanly separate operational responsibility.

Backup strategies for the worst case

A database backup is only as good as your last successful restore test. Both databases offer robust tooling, but the details differ.

MariaDB — pragmatic combination:

# Daily logical backup, ideal for <20 GB databases
mariadb-dump --all-databases --single-transaction \
  --routines --triggers --events \
  | zstd -T0 -19 -o /backup/mariadb-$(date +%F).sql.zst

# Physical hot backup for larger instances
mariabackup --backup --target-dir=/backup/mariabackup/$(date +%F) \
  --user=backup --password="$BACKUP_PW"
mariabackup --prepare --target-dir=/backup/mariabackup/$(date +%F)

PostgreSQL — baseline strategy with point-in-time recovery:

# Daily logical backup in custom format for selective restore
pg_dump -Fc -Z 9 -f /backup/pg-$(date +%F).dump databasename

# Physical base backup + WAL archiving for PITR
pg_basebackup -D /backup/pg-base/$(date +%F) -Ft -z -P -X stream
# WAL archiving via archive_command in postgresql.conf

For both databases the same rule applies: store backup dumps on a TrueNAS dataset with ZFS snapshots, replicate them via zfs send | zfs recv to a second system, and test a full restore in an isolated LXC environment at least once per quarter. Without a tested restore, the backup effectively does not exist — a lesson we unfortunately confirm fresh in client projects on a regular basis.

To protect the entire database host, we additionally recommend a Proxmox Backup Server job over the full LXC/VM container. We are happy to discuss the details of our backup architecture in the context of your specific project.

Migration and typical pitfalls

Migrations between the two systems are feasible but rarely “just a quick job”. The most common topics we see:

Data types: TINYINT(1) used as a boolean stand-in in MariaDB becomes a real BOOLEAN in Postgres. DATETIME in MariaDB versus TIMESTAMP WITH TIME ZONE in Postgres — the latter is stricter and surfaces time-zone bugs that were previously hidden. That is a good thing, but can produce surprises initially.

Case sensitivity: MariaDB treats table and column names as case-sensitive on Linux but not on Windows — Postgres normalises unquoted identifiers to lowercase. Application code that writes SELECT * FROM Users suddenly stops working.

Auto-increment: MariaDB’s AUTO_INCREMENT becomes GENERATED ALWAYS AS IDENTITY in Postgres (standard since Postgres 10) or the classic SERIAL. When you migrate data, sequences must afterwards be set to the correct starting value.

Tooling: pgloader is our preferred tool for MySQL/MariaDB → PostgreSQL migrations. It reads MariaDB directly, maps data types sensibly and transfers data in one go. For the opposite direction there is no standard tool — Postgres → MariaDB is significantly rarer and mostly manual work via pg_dump --data-only followed by data type conversion.

Our general advice: migrate only when there is a concrete reason (feature requirement, application switch, consolidation), not on principle. Porting a productive system that has been stable for five years is a project with real outage risk.

Conclusion — the right basis for a decision

There is no universally “better” database. MariaDB remains the right choice for PHP-heavy stacks, Nextcloud, Mailcow and everything in the classic LAMP space. PostgreSQL is the pragmatic pick as soon as you run GitLab, Odoo, GIS functionality, JSONB-based data models or AI-adjacent applications with pgvector. In practice, most of our clients end up running both systems in parallel — matched to the respective application.

More important than the choice of engine: a documented backup strategy with tested restores, clean separation into dedicated LXC containers on Proxmox, up-to-date monitoring (Zabbix, Netdata or Grafana with mysqld_exporter or postgres_exporter), and a realistic upgrade plan for major versions.

---

DATAZONE supports you in selecting, building and operating your self-hosted databases — from initial consulting through migration to the ongoing backup concept on Proxmox and TrueNAS. Get in touch: contact us.