Process vs Thread Model in PostgreSQL: Benefits, Drawbacks, and Future Proposal

Process‑oriented model is a database architecture where different services are assigned to separate processes that run independently and cooperate via inter‑process communication (IPC). PostgreSQL uses this model.

The model lets PostgreSQL allocate distinct processes for tasks such as query processing, concurrency control, and lock management, improving stability and reliability because a failure in one process does not affect the others.

It also enables handling many concurrent requests and horizontal scaling, but it brings higher management and maintenance costs, complex IPC coordination, and greater resource consumption.

In early June, Heikki Linnakangas published a proposal to convert PostgreSQL to a thread‑based model.

Thread model is similar in concept but assigns services to individual threads that share the same address space, resulting in lower communication overhead but introducing potential security concerns.

Advantages of the thread model include:

Lightweight execution: threads use system resources more efficiently and can run multiple instances within a single process, reducing system‑call and IPC overhead.

Higher response speed: lower communication cost between threads benefits high‑concurrency scenarios.

Reduced memory footprint: shared address space avoids duplicate loading of code and data across processes.

Disadvantages include:

Security risks: shared memory can lead to data races and lock contention.

Reliability concerns: a crash in one thread may compromise the entire process.

Increased programming complexity: synchronization and mutual exclusion are required for safe multithreaded code.

Andres Freund, PostgreSQL developer and EnterpriseDB senior architect, argues that the existing process model shows significant limitations on large‑scale hardware, especially the overhead of cross‑process context switches and TLB misses that cannot be avoided in a process‑isolated design.

The proposal remains tentative; because PostgreSQL is widely used in production, any transition to a thread model must be tested carefully to ensure stability and reliability, and it is unlikely to be completed in a single release. Current community feedback appears largely supportive.

Related link: https://lwn.net/ml/pgsql-hackers/[email protected]/