Open Source
10 items
10 items
The relational database that combines SQL standards compliance with extensibility, powering Instagram, Spotify, and the US Federal Aviation Administration
PostgreSQL is an object-relational database that has evolved over 35+ years from an academic project into the most feature-rich open source database. It combines rock-solid ACID compliance with advanced features like JSON support, full-text search, and extensibility through custom types and functions. The key architectural insight: MVCC (Multi-Version Concurrency Control) allows readers and writers to never block each other, enabling high concurrency without sacrificing consistency.
PostgreSQL uses Multi-Version Concurrency Control to maintain multiple versions of rows. Each transaction sees a snapshot of the database, so readers never wait for writers and writers never wait for readers. This is the foundation of PostgreSQL's high concurrency.
Every change is first written to a sequential log before modifying data pages. This provides durability (crash recovery), enables point-in-time recovery, and powers streaming replication. WAL is why PostgreSQL can guarantee your data survives crashes.
PostgreSQL lets you add custom data types, operators, index methods, and procedural languages. Extensions like PostGIS (geospatial), TimescaleDB (time-series), and pgvector (AI embeddings) transform PostgreSQL into specialized databases.
PostgreSQL began in 1986 at UC Berkeley as POSTGRES (Post-Ingres), led by Professor Michael Stonebraker. The goal was to build a database that could handle complex data types and relationships that the previous generation (Ingres) could not.
Key milestones: - 1986: POSTGRES project starts at Berkeley - 1996: Renamed to PostgreSQL, SQL support added - 2005: Native Windows support - 2010: Streaming replication - 2016: Parallel query execution - 2022: 64-bit transaction IDs (no more wraparound panic)
Today, PostgreSQL is the default choice for new applications that need a relational database. It powers:
Why choose PostgreSQL?
Each client connection gets a dedicated backend process. This provides isolation (one bad query can't crash others) but means connection pooling is essential for applications with many short-lived connections.
Beyond standard SQL types, PostgreSQL offers arrays, ranges, geometric types, and JSONB (binary JSON with indexing). You can query JSON documents with SQL, bridging relational and document models in one database.
PostgreSQL began in 1986 at UC Berkeley as POSTGRES (Post-Ingres), led by Professor Michael Stonebraker. The goal was to build a database that could handle complex data types and relationships that the previous generation (Ingres) could not.
Key milestones: - 1986: POSTGRES project starts at Berkeley - 1996: Renamed to PostgreSQL, SQL support added - 2005: Native Windows support - 2010: Streaming replication - 2016: Parallel query execution - 2022: 64-bit transaction IDs (no more wraparound panic)
Today, PostgreSQL is the default choice for new applications that need a relational database. It powers:
Why choose PostgreSQL?
| Aspect | Advantage | Disadvantage |
|---|---|---|
| Process-per-connection | Strong isolation - one bad query cannot crash others, simple programming model | Memory overhead per connection, requires connection pooling for many connections |
| MVCC with heap storage | Readers never block writers, excellent read concurrency, snapshot isolation | Dead tuples accumulate, requires VACUUM, table bloat possible |
| Write-Ahead Logging | Crash recovery, point-in-time recovery, streaming replication all from one mechanism | Write amplification (data written twice), WAL can grow large between checkpoints |
| Cost-based optimizer | Automatically finds good query plans, adapts to data distribution | Requires up-to-date statistics (ANALYZE), can make wrong choices with bad stats |
| Synchronous replication | Zero data loss guarantee, strong durability | Commit latency includes network round-trip, replica failure can block writes |
| Rich type system and extensibility | Native support for JSON, arrays, geometry, custom types, powerful extensions | Learning curve, can lead to over-engineering, some extensions have maintenance burden |
| Single-primary architecture | Simple consistency model, no write conflicts, easier to reason about | Write scalability limited to one node, failover requires promotion |