1 link tagged with all of: postgres + crash-recovery + connection-pooling + database-architecture + wal
Links
Snowflake interviews Tom Lane, a core Postgres developer for 25 years, about the architectural decisions that have kept the database stable and reliable. He discusses why the process-per-connection model works, how the write-ahead log handles crash recovery, and the trade-offs the project continues to navigate.
- Postgres uses isolated OS processes per connection instead of threads, which simplifies code and improves crash resistance—if one session crashes, it doesn't corrupt shared state or require a full system restart.
- The write-ahead log (WAL) lets transactions commit as soon as log data hits disk, even though table changes may still sit in shared buffers; this batching approach reduces random disk I/O compared to writing scattered changes immediately.
- Connection pooling tools like PgBouncer solve the overhead problem of managing thousands of connections, though the core project hasn't fully integrated pooling into Postgres itself.
postgres
database-architecture
crash-recovery
wal
connection-pooling