For most Linux workloads, PostgreSQL is the right default database, and the honest reason isn't its feature checklist. It's that when Postgres breaks at 3am, its logs, error codes, and source are legible enough to actually tell you what went wrong. That legibility matters more than any benchmark. Among the linux databases worth knowing, pick MySQL or MariaDB only when their replication or ecosystem earns it, use SQLite when the database lives inside one process, and treat every other name on the popularity lists as a niche tool you choose on purpose. Linux runs about 63.1% of the world's servers, so the database question is really a Linux question.

Last updated: 2026-07-21

What actually counts as a Linux database

Three different things get called a database, and confusing them is where bad decisions start. A server daemon like PostgreSQL or MySQL runs as its own process, listens on a socket, and lets many clients connect at once. An embedded engine like SQLite is a library your program links against; there is no server, no port, no separate process to babysit.

The third thing people mean is a client or driver, the code your app uses to talk to the daemon. When someone searches for a linux db or a database for Linux, they usually mean the first kind, a server they install and run. So that is where I'll spend most of the words, with SQLite as the deliberate exception.

Why does this split matter? Because a server database and an embedded one fail in completely different ways. A daemon fails on connections, memory, and disk I/O. An embedded engine fails on file locks and permissions inside your own process. Knowing which shape you have tells you which logs to read first.

How do you pick among linux databases instead of copying a ranking list?

Start with workload shape, not install counts. The top ten lists rank by popularity, and popularity tells you nothing about whether a tool fits your job. I ask three questions before I touch a package manager.

1. How many writers at once? One process writing means SQLite is on the table. Many clients writing concurrently means you want a server daemon.
2. How much do you care if a crash loses the last transaction? Strict durability points you at Postgres with proper fsync and write-ahead logging. Looser needs open up more options.
3. Who debugs it at 3am? Pick the engine whose logs and internals your team can actually read. A "better" database nobody on your team understands is worse than a plain one they do.

That last question is the one the ranking lists never ask, and it is the one that saves you. The right database is the one you can diagnose, not the one with the biggest logo wall of users like Facebook and Google. Those companies run everything; their use of a tool does not mean it fits your ten-person shop.

PostgreSQL is my default, and here's why

I reach for PostgreSQL first for general relational work, and I do it because its failure modes are readable. When a query hangs, pg_stat_activity shows you every running statement and what it's waiting on. When something is slow, EXPLAIN ANALYZE prints the real plan, not a guess. When it crashes, the server log in /var/log/postgresql/ names the reason in plain text.

Postgres ships a new major version every year, so don't hardcode a version number in your head. Run the check against the official PostgreSQL documentation for the current release instead of trusting a stale blog. The object-relational features, real constraint checking, and honest transaction handling are the reason it's my default for anything that has to be correct.

Here is what I do when Postgres misbehaves: read the log first, then pg_stat_activity, then the query plan. Only after those do I touch config. The mistake I see most is people tuning shared_buffers blind before they've read a single log line. Understand the failure or it comes back.

When MySQL or MariaDB wins

Choose MySQL when you're running a multi-user server app with a huge surrounding ecosystem, and the PHP-and-MySQL web stack is the obvious case. MySQL has been around since May 23, 1995, so the tooling, hosting, and hiring pool are enormous. That maturity is a real reason to pick it, not marketing.

But understand its replication before you depend on it. MySQL's default replication is asynchronous, which means a replica can lag behind the primary, and a failover at the wrong moment can lose the last few writes. That is not a bug; it is the model. Read how it works before you build a high-availability plan on top of it.

MariaDB is the right pick when you want MySQL compatibility without Oracle's ownership of MySQL. It forked from MySQL and stays largely drop-in compatible, with its own storage engines and a more open governance model. What MariaDB is not is automatically "better" than MySQL. Pick it for the licensing and independence, and test your specific workload rather than trusting a benchmark someone posted to prove a point.

When to reach for SQLite instead of a server

Use SQLite when the database lives inside a single application and does not need a separate process. It is the most widely deployed database engine on earth, with over one trillion copies in active use, because it ships inside browsers, phones, and countless desktop apps. There is no server to run, no port to secure, and no user accounts to manage.

The moment SQLite stops being the right tool is concurrent writers. It uses a single-writer lock, so one write transaction blocks all other writes across the whole database file. For a local app or a read-heavy cache that's fine. For a busy web backend with many users writing at once, you'll hit SQLITE_BUSY errors and lock contention fast.

I've watched people try to scale past this with tricky timeout settings and retry loops. That's papering over the model. The SQLite documentation is refreshingly honest about this: it's built to replace fopen(), not to replace a server database. When you need concurrent writes, move to Postgres and stop fighting the lock.

Where Firebird and Ingres actually fit

Firebird earns a look for one specific reason: its trigger and stored-procedure model. If your application logic needs to live inside the database with strong procedural support, Firebird does that well in a small footprint. It is not a general-purpose contender against Postgres, and I wouldn't reach for it as a default. Pick it when its procedural features are the actual requirement.

Ingres is a legacy enterprise and government-grade database. Choose it only when your organization already runs it and has the institutional expertise to keep it running. Adopting Ingres fresh, in a new project, with nobody who knows it, is a support ticket waiting to happen. The value here is continuity, not features you can't get elsewhere. If you're starting clean, these two are not the answer; Postgres almost certainly is.

Open source or closed source?

This is a real decision axis, and it's separate from which engine you pick. Postgres, MySQL, MariaDB, and SQLite are all open source, which means you can read the source when the docs run out. That matters more than it sounds. The Linux kernel itself ships under the GPL-2.0 license, and the same freedom to read and patch applies to most of these databases.

Closed-source and commercial databases buy you a support contract and someone to call. That's genuinely worth paying for in some shops, especially where regulation demands a vendor on the hook. What you give up is the ability to strace the binary, read the source, and understand a failure yourself. For most Linux teams I'd keep the code open, because when something breaks, the source is the last reliable manual. If you're weighing where to run any of this, our guide to deploying a Linux app on cloud hosting covers the hosting side.

How do you diagnose a database problem on Linux instead of guessing?

Run this first when a database daemon won't start or acts wrong: journalctl -u postgresql -b -p err (swap in mysql or mariadb as needed). That pulls only errors for that service from the current boot, and nine times out of ten the daemon already logged the reason. Read it before you change one setting.

If the service starts but connections fail, the problem is usually not the database. Check whether it's even listening with ss -tulpn | grep 5432 for Postgres. No listener means a config or bind-address issue, not a query problem. That one check saves you an hour of poking at SQL.

When a database process hangs or spins, strace -p <pid> shows you the system calls it's stuck on. If you see it blocked on fsync or read, the real problem is disk I/O, not your query. Confirm with dmesg -T | tail, which surfaces filesystem errors, out-of-memory kills, and disk timeouts the database log never mentions.

The OOM killer is the classic one nobody checks. If your database "randomly" dies, dmesg | grep -i oom will often show the kernel killed it to reclaim memory. That tells you to fix memory limits, not to reinstall the database. Understand which layer failed, then fix that layer.

Installing and configuring it right the first time

Use your distribution's package manager, not a source build, unless you have a specific reason. On Debian or Ubuntu, sudo apt install postgresql gives you a version the distro patches and a systemd unit already wired up. Building from source is for when you need a feature the packaged build lacks, and it means you own every future security update yourself.

Put your data directory somewhere deliberate. The default lands under /var/lib/postgresql/, and that's fine until /var fills up and takes the database with it. For anything serious, I put the data directory on its own volume so a runaway log can't starve the database of disk. Set it in the config, not with a symlink you'll forget about.

After install, confirm the service is actually managed by systemd:

systemctl status postgresql
systemctl enable postgresql

The enable line is the one people skip, and then the database doesn't come back after a reboot. Set a real password, restrict the listen address, and lock down pg_hba.conf before you expose anything. For choosing which distro to run underneath, our roundup of Linux distros for a home lab is a good starting point.

FAQ

Is MongoDB a good default database on Linux?
Not as a default. MongoDB Community Edition is free and fine for genuinely document-shaped data, but too many teams pick it to avoid schema design, then rebuild relational logic in application code. Choose it when your data is truly documents, not because you want to skip thinking about structure.

Do I need a lot of RAM to run a database on Linux?
It depends entirely on the engine and workload. SQLite runs happily inside a small app with almost nothing. Distributed stores are hungrier: Apache Cassandra, for instance, wants at least 2 cores and at least 8GB of RAM as a floor. Check your specific engine's requirements before you size the box.

Can I run several databases on one Linux server?
Yes, and it's common. Give each its own systemd unit, its own port, and ideally its own data volume so one can't starve the others of disk. Watch total memory, because two databases each sized as if they own the machine will trigger the OOM killer.

What's the fastest way to see why a database won't start?
Read the service log with journalctl scoped to that unit and errors only, then check dmesg for disk or memory problems the database itself never logged. Between those two you'll usually find the cause without guessing or editing config blind.

Should I learn PostgreSQL internals or just use it?
If it's a hobby project, just use it. If you'll run it in production, learn where its logs, pg_stat views, and source live, because that knowledge is what turns a two-hour outage into a ten-minute fix.

Related on this blog

• How to Contribute to the Linux Kernel: A Guide