Can PostgreSQL Compete with Analytics Specialists?
summary
Argues PostgreSQL can handle most analytics if tuned, claiming 95% of cases PostgreSQL is good enough while admitting a real 5% need purpose-built engines; points out MVCC adds ~23 bytes per row and causes large IO waste on wide tables, and lists concrete PG18 fixes: io_uring, BRIN-like bitmap scans, and improved parallelism. Contrasts ClickHouse and DuckDB differences: ClickHouse = columnar, sorted parts, in‑RAM sparse indexes; DuckDB = in‑process vectorized chunks (~248 rows). Warns ClickBench favors columnar engines and hides operational costs.
AI-written summary · about
chapters (16)
- 0:00Introduction and setup
- 2:55PostgreSQL storage basics
- 5:27Sequential and index scans
- 8:20Bitmap scans and overhead
- 10:47PostgreSQL 18 improvements
- 15:30ClickHouse architecture
- 17:27ClickHouse trade-offs
- 20:22DuckDB overview
- 23:18ACID compliance comparison
- 26:12Benchmarking challenges
- 28:17ClickBench analysis
- 31:33PostgreSQL tuning and marketing
- 33:00Query examples and performance
- 37:22Workload relevance
- 38:26Making the right choice
- 40:56Q&A session
related talks
46mPostgreSQL Analytics: It's a Trap!
19mFrom OLTP to OLAP: Is PostgreSQL Eating Analytics Too?
34mAnalytics and AI with PostgreSQL - Mission Possible!
21mAnalytics in Postgres –A decade in the making
34mAnalytics and AI with PostgreSQL - Mission Possible!
21mWhat can Postgres learn from DuckDB?
58mSuper Jumbo Delux
51mHow Postgres is Different (read BETTER than) your database