2.1. Process Architecture

PostgreSQL is a client/server relational database management system featuring a multi-process architecture that runs on a single host.

A collection of multiple processes that cooperatively manage a database cluster is referred to as a PostgreSQL instance, which includes the following types of processes:

  • Postmaster process: The parent process of all processes related to database cluster management. Note that the executable file itself is named postgres. See the glossary.
  • Backend processes: Each backend process handles all queries and statements issued by a connected client. The executable file itself is also named postgres.
  • Background processes: Various processes that perform tasks for database management, such as VACUUM and CHECKPOINT operations.
  • Replication-associated processes: Processes that perform streaming replication. Further details are provided in Chapter 11 and Chapter 12.
  • Background worker processes: Supported since version 9.3, these processes can perform any user-implemented logic. For more information, refer to the official documentation.

Communication between these processes takes place via standard Unix communication mechanisms, such as pipes and Unix-domain sockets, while data sharing is handled through shared memory, which is described in Section 2.2.2.

The following subsections describe the details of the first three process types.

Figure 2.1. An example of the process architecture in PostgreSQL.
Section Contents

2.1.1. Postmaster Process

The Postmaster process is the parent of all processes within a PostgreSQL instance.

The Postmaster process starts when the pg_ctl utility is executed with the “start” option.

Upon initiation, it allocates a shared memory area, launches various background processes, and starts replication-associated or background worker processes as required. It then waits for connection requests from clients. Whenever a connection request is received, the Postmaster process spawns a dedicated backend process to handle the client session.

A Postmaster process listens on a specific network port, with the default being 5432. While multiple PostgreSQL instances can run on the same host, each instance must be configured to listen on a unique port number (e.g., 5432, 5433, etc.).

2.1.2. Backend Processes

A backend process, also referred to as a postgres process, is started by the Postmaster process and handles all queries issued by a single connected client. It communicates with the client via a single TCP connection and terminates upon the client’s disconnection.

Each backend process can operate on only one database at a time; therefore, a specific database must be selected during the connection process.

PostgreSQL supports concurrent connections from multiple clients, with the maximum number governed by the max_connections configuration parameter (default: 100).

Info

Because PostgreSQL does not have a native connection pooling feature, frequent connection and disconnection cycles — common in applications like web services — can increase the overhead of establishing connections and spawning backend processes.

This overhead can negatively impact the overall performance of the database server. To mitigate this, connection pooling middleware such as pgbouncer or pgpool-II is typically employed.

2.1.3. Background Processes

Table 2.1 lists the primary background processes.

Unlike the Postmaster and backend processes, the functions of background processes cannot be easily summarized because they depend on specific features and deep PostgreSQL internals.

Therefore, this section provides only a brief introduction to each process. Detailed explanations are provided in the subsequent chapters.

Table 2.1: background processes.
Process Description Reference
background writer Periodically and gradually writes dirty pages from the shared buffer pool to persistent storage (e.g., HDD, SSD). (In versions 9.1 and earlier, it was also responsible for performing checkpoints.) Section 8.6
checkpointer Performs checkpoint operations in versions 9.2 or later. Section 8.6, Section 9.7
autovacuum launcher Periodically invokes autovacuum-worker processes for VACUUM and ANALYZE operations. (Technically, it requests the Postmaster process to spawn the autovacuum workers.) Section 6.5
WAL writer Periodically writes and flushes WAL data from the WAL buffer to persistent storage. Section 9.6.1
WAL Summarizer Tracks changes to all database blocks and writes these modifications to WAL summary files. This process was introduced in version 17 (2024). Section 9.6.2
statistics collector Collected statistics for system views such as pg_stat_activity and pg_stat_database.
Version 15 (2022) removed the separate statistics collector process and moved the cumulative statistics system to shared memory. 		 
logging collector (logger) Captures error messages and writes them into log files.  
io worker Handles read operations asynchronously to offload I/O tasks from backend processes. (Asynchronous I/O was introduced in version 18 (2025) to improve I/O performance.) Section 8.5.2.2
archiver Executes the log archiving process. Section 9.10

2.1.3.1. Replication-Associated Processes

Table 2.2 lists the processes associated with streaming and logical replication introduced in the list above.

Most processes start only when replication is configured and active, with one exception: the logical replication launcher starts by default on every PostgreSQL instance, regardless of whether replication is used. Further details appear in Chapter 11 and Chapter 12.

Table 2.2: replication-associated processes.
Process Description
logical replication launcher Launches and manages apply worker processes for each enabled subscription. This process starts by default whenever a PostgreSQL instance starts.
walsender Reads WAL data and sends it to a connected standby server (streaming replication), a logical replication subscriber, or a pg_basebackup client.
walreceiver Started on a standby server to receive WAL data sent by the primary server's walsender during streaming replication.
startup Replays WAL data during crash recovery. On a standby server in streaming replication, it continuously applies WAL data received by the walreceiver.
apply worker Started on the subscriber side in logical replication; receives decoded change messages from the publisher's walsender and applies them to the target tables.
leader apply worker When parallel application is enabled (streaming = 'parallel'), this is the apply worker that receives the streamed changes and dispatches them to parallel apply workers.
parallel apply worker Launched by the leader apply worker to apply streamed logical changes concurrently, before the transaction commits on the publisher.
Info

The actual processes of a PostgreSQL instance are shown below.

In this example, there is one Postmaster process (PID 6541), two backend processes (PIDs 8412 and 8482), and several background processes as listed in Table 2.1. See also Figure 2.1.

$ pstree -p 6541
-+= 00001 root /sbin/launchd
 \-+= 06541 postgres /usr/local/pgsql/bin/postgres -D data
   |--= 06542 postgres postgres: io worker 0
   |--= 06543 postgres postgres: io worker 1
   |--= 06544 postgres postgres: io worker 2
   |--= 06545 postgres postgres: checkpointer
   |--= 06546 postgres postgres: background writer
   |--= 06548 postgres postgres: walwriter
   |--= 06549 postgres postgres: autovacuum launcher
   |--= 06550 postgres postgres: walsummarizer
   |--= 06553 postgres postgres: logical replication launcher
   |--= 08412 postgres postgres: postgres testdb [local] idle
   \--= 08482 postgres postgres: postgres testdb [local] idle in transaction