PostgreSQL

The default relational database for self-hosted everything

Databases & Storage PostgreSQL Intermediate ★ 22,262 stars

What is PostgreSQL?

PostgreSQL is the database most self-hosted applications expect. Relational tables with strict types, JSON support when you want it, extensions for time series and vectors, and thirty years of reliability behind it.

Best for

The database almost every self-hosted app will ask for

Why choose PostgreSQL

PostgreSQL is the database that self-hosted software asks for by default, and that ubiquity is itself the strongest argument. Install it once and it will satisfy the requirements of most of the applications on your network, which means one database to learn, back up and secure rather than five. Beyond familiarity, it is genuinely capable: strict typing catches data errors at write time, JSON columns handle the documents that do not fit a table, and extensions add time-series, vector search and geospatial indexing without leaving the same engine. Its transaction handling is the standard other databases are measured against, and thirty years of production use mean the failure modes are documented rather than discovered.

Replaces

  • MySQL
  • MariaDB
  • Amazon RDS

Key features

  • Full ACID transactions and strong typing
  • JSONB for flexible document-style columns
  • Extensions for time series, vectors and search
  • Logical and streaming replication

What to watch out for

PostgreSQL is not self-tuning to the degree people assume. The default configuration is conservative and aimed at a small machine; a database given real memory without adjusting shared_buffers, work_mem and the connection limits will underperform and blame the application. Connection handling is a common failure: each connection is a process, and a PHP or Node application that opens hundreds silently exhausts memory until a pooler is added. Vacuum and bloat need to be understood rather than ignored, and long-running transactions can hold back cleanup indefinitely. Major version upgrades require a dump and restore or pg_upgrade, which is a scheduled operation rather than a container restart.

How to deploy

  • Docker with a named volume or host bind
  • Set a strong password and restrict the listen address
  • Configure pg_dump or physical backups on day one

Getting started

Install it as a container or package with a persistent data directory that is explicitly part of your backup routine — and test a restore, because a backup you have never restored is a hypothesis. Set the memory parameters to match the host instead of accepting defaults, and add a connection pooler once more than a couple of applications connect. Give each application its own database and user rather than sharing one superuser everywhere, and restrict network access to the hosts that need it. Do not expose the port to the internet. Pin the major version deliberately and treat upgrades as planned maintenance with a dry run.

Typical setup

A container or package with a persistent data directory that is explicitly included in the backup routine, and a restore that someone has actually performed at least once. Memory parameters are set to match the host rather than left at defaults, and a connection pooler sits in front once more than one application connects. Each application gets its own database and its own least-privilege user rather than sharing one account. The port is bound to an internal interface only. The major version is pinned deliberately, and upgrades are treated as scheduled maintenance with a dry run on a copy of the data.

Who should look elsewhere

Choose something else if you need a genuinely zero-configuration embedded database, because Postgres expects an administrator. It is also the wrong fit for very high-write append-only workloads where a time-series or columnar engine will be dramatically cheaper — using it as an event store works until the volume makes it painful. And if the application ships its own preferred database engine, running a second one just for that is usually more trouble than it is worth.

Project health

  • GitHub stars: 22,262
  • Last code push: 2026-10-02
  • Open issues: 0
  • Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.

More in Databases & Storage