Databases for DevOps — Overview

Almost every application stores data somewhere, and that “somewhere” is usually a database (a program that stores, organises, and retrieves data for your app). As a DevOps engineer you rarely design the tables or write the queries — that is the developer’s job. Your job is the part nobody else wants: installing the database, locking it down, tuning it, backing it up, and keeping it alive at 3 a.m. when it falls over. This page introduces the four databases this section covers — PostgreSQL, MySQL, MongoDB, and Redis — and explains what role each one plays so you know which page to read next.

What “operating a database” actually means

Developers think about schemas (the shape of the data — which tables and columns exist). DevOps engineers think about everything around that:

Install the database on the server (usually with apt on Ubuntu).
Secure it — set strong passwords, turn on authentication, and use ufw (Uncomplicated Firewall, Ubuntu’s simple firewall tool) so only trusted machines can connect.
Configure where it listens, how much memory it uses, and where it writes logs (often under /var/log).
Back up the data on a schedule, and — just as important — test that you can restore it.
Monitor disk space, connection counts, and slow queries so you catch trouble early.

A backup you have never restored is not a backup — it is a hope. The first time you test a restore should never be during a real outage. Schedule a restore drill at least once a quarter.

The two database families

Databases split into two big families, and knowing which family you are dealing with changes how you secure and back it up.

A relational database (also called SQL, pronounced “sequel”) stores data in tables with fixed columns, like a spreadsheet, and uses the SQL language (Structured Query Language) to read and write it. PostgreSQL and MySQL are both relational.

A NoSQL database (“Not Only SQL”) stores data in more flexible shapes — documents, key/value pairs, and so on — and usually trades some strictness for speed or scale. MongoDB (documents) and Redis (key/value) are both NoSQL.

Family	Stores data as	Examples here	Best for
Relational (SQL)	Tables with fixed columns	PostgreSQL, MySQL	Orders, users, money — anything needing strict structure and relationships
Document (NoSQL)	JSON-like documents	MongoDB	Flexible or fast-changing data, content, catalogs
Key/value (NoSQL)	Simple key → value pairs, in memory	Redis	Caching, sessions, queues — speed over durability

The four databases this section covers

PostgreSQL

PostgreSQL (often just “Postgres”) is a powerful, open-source relational database. It is the modern default choice for new applications because it is reliable, free, follows standards closely, and handles complex data well (it even speaks JSON). On Ubuntu its config and data live under /etc/postgresql and its logs under /var/log/postgresql.

When to use it: Pick Postgres when you need a rock-solid relational database and have no strong reason to choose something else. It is the safest default in 2026.

MySQL

MySQL is the other hugely popular open-source relational database. It powers a massive share of the web — WordPress, for example, runs on it. MariaDB is a drop-in community fork of MySQL you will also meet; the commands are nearly identical. Its config lives under /etc/mysql.

When to use it: Choose MySQL when an application explicitly requires it (lots of PHP and WordPress software does), or when your team already knows it well. For a brand-new project with a free choice, many teams now lean toward Postgres — but MySQL is a perfectly solid, battle-tested option.

MongoDB

MongoDB is the most popular document database. Instead of rigid tables, it stores documents (records that look like JSON objects), so the data shape can vary from record to record. This flexibility is handy when your data does not fit neatly into rows and columns.

When to use it: Reach for MongoDB when your data is genuinely document-shaped and changes often — content management, product catalogs, event logs. Do not reach for it just to “avoid SQL”; relational data (like financial transactions) still belongs in Postgres or MySQL.

Redis

Redis stores simple key/value pairs entirely in RAM (the computer’s fast working memory), which makes it blazingly fast. Because RAM is wiped on reboot, Redis is mainly used as a cache (a temporary fast copy of data) rather than as the only home for important data.

When to use it: Use Redis to speed up a slow app — cache database results, store user sessions (the data that remembers a logged-in user), or run a simple job queue. Do not use it as your only store for data you cannot afford to lose.

Choosing the right one — a quick guide

If you need…	Use
A reliable, standards-based default for new apps	PostgreSQL
To run WordPress or other MySQL-only software	MySQL
Flexible, document-shaped data	MongoDB
A fast cache, session store, or queue	Redis

It is completely normal to run several of these at once. A typical setup is Postgres or MySQL for the core data plus Redis in front of it for caching.

A note on installation method

You can install these databases two ways, and the choice affects everything that follows:

Directly on the server with apt and systemd (systemd is the Ubuntu service manager that starts, stops, and restarts background programs). This is simplest for a single dedicated database server.
In a Docker container (a lightweight, isolated package that bundles the database and its dependencies). This is great for local development and reproducible environments.

Whichever method you choose, never expose a fresh database to the public internet with default settings. Bots scan the entire internet for open databases with no password and wipe them within hours. Bind to localhost and open ports with ufw only for the specific IPs that need them.

Best practices

Secure before you connect anything. Set a strong password and enable authentication immediately after install, before you load any real data.
Bind to localhost by default. Only allow remote access through ufw rules scoped to specific trusted IP addresses.
Automate backups, then test restores. A nightly dump (pg_dump, mysqldump, mongodump) is useless until you have proven you can restore it.
Right-size, don’t oversize. Match memory settings to the server; the defaults are usually too low for production and too high for tiny test boxes.
Watch disk space. A full disk corrupts databases and crashes apps — alert before you hit 80% usage.
Keep credentials out of code. Store database passwords in environment variables or a secrets manager, never hard-coded in the repository.
Pin and patch versions. Run a supported major version and apply security updates with apt on a schedule.