What is PostgreSQL?

PostgreSQL (often just called “Postgres”) is a free, open-source relational database — a program that stores your data in tables made of rows and columns, the way a spreadsheet does, but built to handle millions of records safely and at speed. It has a reputation among engineers for being correct, dependable, and packed with advanced features, which is why companies from tiny startups to giants like Apple and Instagram run on it. If you are learning DevOps on a Linux server, Postgres is one of the most important pieces of software you will install and manage. This page explains what it is, why it stands out, and where it fits before you start installing and administering it.

What “relational” and “SQL” mean

A relational database organises data into tables, and those tables can be linked (“related”) to each other. For example, a users table and an orders table can be connected so each order knows which user placed it.

You talk to the database using SQL (Structured Query Language) — a text-based language for asking questions and changing data. A simple query looks like this:

SELECT name, email FROM users WHERE country = 'India';

Postgres reads that, finds the matching rows, and sends them back. SQL is a standard language, so much of what you learn here also applies to other relational databases like MySQL.

Why engineers trust PostgreSQL

The biggest reason is correctness. Postgres is fully ACID-compliant. ACID stands for Atomicity, Consistency, Isolation, and Durability — four guarantees that mean your data does not get corrupted or half-saved, even if the server loses power in the middle of a write. When money or important records are involved, this matters enormously.

Beyond safety, Postgres is famous for rich features that other databases charge money for or simply lack:

JSONB — a way to store flexible, document-style data (like JSON) inside a relational database. You get the structure of SQL tables plus the flexibility of a NoSQL document store in one product.
Extensions — small add-ons that bolt extra power onto Postgres. The most famous is PostGIS (for maps and geographic data). Others add full-text search, time-series tooling, and even AI vector search (pgvector).
Strong data types — arrays, ranges, UUIDs, network addresses, and more are built in.
Advanced queries — window functions, common table expressions (CTEs), and recursive queries for complex reporting.

Tip: Because Postgres handles JSONB so well, you often do not need a separate NoSQL database for flexible data. Reaching for one product instead of two means fewer servers to secure, patch, and back up.

PostgreSQL vs MySQL — when to use which

MySQL is the other hugely popular open-source relational database. Both are excellent and free, but they have different personalities.

Factor	PostgreSQL	MySQL
Reputation	Correctness, advanced features, standards-compliant	Speed, simplicity, very widely deployed
Complex queries	Excellent (window functions, CTEs, rich types)	Good, but fewer advanced features
JSON / document data	First-class via JSONB with indexing	Supported, but less powerful
Extensions	Huge ecosystem (PostGIS, pgvector, etc.)	Limited
Learning curve	Slightly steeper	Gentler for absolute beginners
Common use	Complex apps, analytics, geospatial, anything data-heavy	Simple web apps, WordPress, LAMP stacks

When to choose Postgres: your app has complex relationships, you need JSON plus SQL, you want geospatial or vector search, or you simply value strict correctness. This is the safe default for most new projects in 2026.

When MySQL might win: you are running software that explicitly expects it (WordPress, many older PHP apps), or your team already knows it well.

Where PostgreSQL fits in a DevOps stack

On a typical Linux server, Postgres is the data layer. Your application (a Node.js, Python, Java, or PHP program) connects to Postgres over the network, runs SQL queries, and gets data back. A common setup looks like this:

[ User's browser ]
        |
[ Nginx reverse proxy ]   <- forwards web requests
        |
[ Your application ]      <- runs your business logic
        |
[ PostgreSQL database ]   <- stores all your data

On Ubuntu, Postgres installs cleanly through the system package manager and runs as a background service managed by systemd (the tool Ubuntu uses to start, stop, and supervise services). After installing, you will find its files in predictable places:

Path	What it holds
`/etc/postgresql/`	Configuration files, organised by version
`/var/lib/postgresql/`	The actual data (your tables and rows)
`/var/log/postgresql/`	Log files for debugging

You can confirm whether Postgres is installed and check its version with a single command:

psql --version

Output:

psql (PostgreSQL) 16.3 (Ubuntu 16.3-1.pgdg24.04+1)

And once it is running, you check the service status through systemd:

sudo systemctl status postgresql

Output:

● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled)
     Active: active (exited) since Mon 2026-06-15 09:12:44 UTC; 2h ago
   Main PID: 812 (code=exited, status=0/SUCCESS)

If you do not have it installed yet, that is the next page — but it is worth understanding what you are about to run before you run it.

Gotcha: Out of the box, Postgres only listens for connections from the same machine (localhost). That is a deliberate, good security default. Do not change it to accept the whole internet until you understand authentication and firewall rules — opening a database to the world is one of the most common ways servers get hacked.

Best Practices

Treat Postgres as the safe default relational database for new projects unless something specifically requires MySQL.
Always note the major version you install (e.g. 16) — config paths and upgrade steps depend on it.
Keep the default localhost-only listening setting until you have a real reason and a plan to secure remote access.
Use JSONB when you genuinely need flexible data, but model the rest of your schema with proper tables and relationships.
Learn psql, the built-in command-line client — it is the fastest way to inspect and fix things on a server.
Plan backups from day one; a database without tested backups is a future outage waiting to happen.