5 ms·
Postgres as we know it has only existed for about a decade, since the post-9.x era in 2010-2014 when many of its lauded features were added. Replication, heap-o
by tomnipotent 3y ago
Postgres as we know it has only existed for about a decade, since the post-9.x era in 2010-2014 when many of its lauded features were added. Replication, heap-only tuples, extensions, foreign data wrappers, JSON, leveraging multiple indexes, parallel index scans, reindex concurrently, JIT compilation, declarative partitioning, stored procedures, and major WAL improvements are all "recent".
I love Postgres and it's been my go-to default since 2014 and you can pry it from my cold dead hands, but it's more contemporary with Perl 6 than Perl 5 if we're talking grey beards.
- Sesse__ 3y agoExtensions and stored procedures are not; they've been around for longer. I do not actually use any of the others you listed (well, occasionally bitmap index scans, but it's not a killer). The main difference between 8.x and 15.x for me is the small stream of optimizer features and tweaks (e.g. at some point, it started being able to reorder outer joins).
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- tomnipotent 3y agoPostgres 8 supported functions capable of returning tuples (RETURN QUERY), but lacked transaction control and other features that CREATE PROCEDURE added in Postgres 11 (2018). Extensions in Postgres 8 (and earlier) were also half-baked compared to 9.1 (2011), which added CREATE EXTENSION and other quality-of-life improvements including standardization. The latest complete implementations are what most people have in mind when talking about them.
- Sesse__ 3y agoSure, there are improvements, but it's not like Postgres was a radically different beast back then. Would I pick Postgres 15 over Postgres 8? Yes, any day of the week. But I would also readily pick Postgres 8 over most of today's databases (including e.g. the latest MySQL and MongoDB versions), for most projects, if that was the choice I had.
- tomnipotent 3y agoI would not have risked my business (or budget) on Postgres 8, even with Slony-I. My appreciation for its well-written code and thoughtful architecture simply did not outweigh what it lacked for a reliable operations experience. MySQL foot guns were mostly under control by 2010, and it was operationally efficient to manage a cluster of MySQL servers in diverse configurations with mostly-known boundaries to what could go wrong. The Postgres foundations are the same today, but what you can build on top is very different today than it was pre-9.x.
- sph 3y agoI operated MySQL clusters in the late 2000s. I still am surprised how many hoops you have to jump through to set up replication in PostgreSQL than what you could do - out of the box - with MySQL 15 years ago.
- Sesse__ 3y ago> I would not have risked my business (or budget) on Postgres 8, even with Slony-I. This assumes you need replication, though. You can get pretty far without it, especially given how wide hardware you can get now. > MySQL foot guns were mostly under control by 2010 Eh. :-) I think you would have to specify which footguns in particular.
- turtles3 3y agoReplication can be for HA, not just for scale. All depends on your business requirements. Also replication can be good for other operational reasons, such as zero downtime major version upgrades. Again depends on the business need/expectations.