PostgreSQL Architecture — Complete Guide

PostgreSQL Architecture — Complete Guide: free step-by-step lesson with examples, common mistakes, and interview tips — part of PostgreSQL Tutorial on Toolliyo Academy.

8 min read Updated 8/18/2026

On this page

PostgreSQL Tutorial · Lesson 2 of 100

PostgreSQL Architecture

SQL → Advanced

SQL · 1 — Queries · ~6 min · PostgreSQL — Foundations

What is this?

PostgreSQL splits work into a postmaster (main process), background workers, and client sessions. Each connection gets its own backend process. Shared memory holds buffer cache and WAL buffers; data files live on disk under the data directory.

Why should you care?

When Swiggy traffic spikes, knowing that each app connection spawns a process helps you size connection pools and avoid exhausting RAM.

See it live — copy this example

Run in pgAdmin or psql.

SHOW data_directory;
SHOW shared_buffers;
SHOW max_connections;

What happened?

data_directory points to on-disk cluster files.
shared_buffers is RAM used for page cache.
max_connections caps how many simultaneous backends can run — a key tuning knob for production.

Practice next

Connect to PostgresVerse in psql.
Run each SHOW command above and write down the values.
Run SELECT pid, backend_type FROM pg_stat_activity WHERE backend_type IS NOT NULL LIMIT 10;
Run SHOW hba_file; and locate pg_hba.conf on disk.
Open two psql tabs and compare pid values in SELECT pg_backend_pid();

Remember

Postmaster forks a backend per client connection. Shared buffers cache table pages in memory. Background workers handle autovacuum, WAL, and replication.