A database feature matters economically when it changes the work users must do to get a reliable result. PostgreSQL 12, released October 3, 2019, puts that question on several fronts: query planning, indexing, and maintenance. The release is a set of options, not a promise that every installation becomes faster. [shared-03ed6acce83a0bacef917af69439e5eb384487f7733b6a8e76f1e7e88de9f19a]
One change lets PostgreSQL inline a WITH query only when it is nonrecursive, side-effect-free, and referenced once. That can give the planner more room to optimize eligible queries; queries outside those conditions do not receive that path. The release also reports a 40% average reduction in B-tree index space use in its TPC-C benchmark, alongside a query-performance gain. That is a benchmark result, not a forecast for another workload. Partitioned-table improvements similarly matter most in the described case of many partitions with queries touching a limited subset. [shared-03ed6acce83a0bacef917af69439e5eb384487f7733b6a8e76f1e7e88de9f19a]
For operators, REINDEX CONCURRENTLY can rebuild indexes without blocking writes, potentially reducing one source of downtime. But checksum changes through pg_checksums require an offline cluster, so integrity work still carries an availability cost. JIT is enabled by default only in installations built or packaged with LLVM. These choices may lower some costs or make PostgreSQL more usable against proprietary alternatives; the release alone cannot show whether entrants gain, workloads improve, or operating costs fall. Real workload tests and maintenance costs decide that. [shared-03ed6acce83a0bacef917af69439e5eb384487f7733b6a8e76f1e7e88de9f19a]