41–50 of 452 posts
> Postgres 17.0 has been out for a bit and ... No. It's been released in September 2024. That's not "quite a bit". Now as to why people aren't all on 17 and not even on 16 yet, here's an acronym for you: LTS [1] Debian 11 Bullseye is the current LTS. It came out in 2021. [1] https://en.wikipedia.org/wiki/Long-term_support
Earlier quoted context omitted.
I've always wondered why Postgres is so insanely popular. I mean it has some nice things like very powerful support for a very comprehensive subset of SQL functionality, but most apps don't need all that. It really feels like early 1990s vintage Unix software. It's clunky and arcane and it's hard to feel confident doing anything complex with it.
> It really feels like early 1990s vintage Unix software. It's clunky and arcane and it's hard to feel confident doing anything complex with it. How software "feels" is subjective. Can you be more specific?
Earlier quoted context omitted.
What's the alternative? MySQL? No transactional DDL, immediate fail.
I worked for a company that migrated from mysql to postgres, but then got big enough they wanted to hire fulltime database experts and ended up migrating back to mysql because it was easier to find talent
> Postgres 17.0 has been out for a bit and ... No. It's been released in September 2024. That's not "quite a bit". Now as to why people aren't all on 17 and not even on 16 yet, here's an acronym for you: LTS [1] Debian 11 Bullseye is the current LTS. It came out in 2021. [1] https://en.wikipedia.org/wiki/Long-term_support
Databases tend to be "stickier" than other parts of any large software system. Largely because database migrations are costly. You can't just tear down an old database and rebuild a new one, you have to figure out how to move all that data across too. The consequence is that things in database-land tends to move slower than other types of software. This I think is the major reason why we still use SQL.
Earlier quoted context omitted.
> It really feels like early 1990s vintage Unix software. It's clunky and arcane and it's hard to feel confident doing anything complex with it. How software "feels" is subjective. Can you be more specific?
The command line experience is old school style i.e. to show tables. \c database \dt Versus: use database show tables
Today I use CLIs like usql to interact with MySQL and SQLite so I can continue to use those commands.
At first glance they may be less obvious, but they are significantly more discoverable. \? Just shows you all of them. In MySQL it always feels like I need to Google it.
Earlier quoted context omitted.
I've always wondered why Postgres is so insanely popular. I mean it has some nice things like very powerful support for a very comprehensive subset of SQL functionality, but most apps don't need all that. It really feels like early 1990s vintage Unix software. It's clunky and arcane and it's hard to feel confident doing anything complex with it.
What's the alternative? MySQL? No transactional DDL, immediate fail.
Earlier quoted context omitted.
Have postgres updates actually been requiring users do migrations? Or is this just a fear that something will go wrong?
Well if it's self-hosted you have to do it yourself. You can either backup your databases from the old version and restore it to the new version once installed, or you can use pg_upgrade to upgrade/copy a old version data directory to the new version. I don't think this is done automatically when you simply install a new postgres version, but I'm not certain of that.
Earlier quoted context omitted.
UTF-8 is what made me switch. It’s insane MySQL has something called UTF-8 that isn't really UTF-8, but do have a type UTF8MB4 that actually is correct. This means if you use UFT-8 in MySQL, you can’t use emoji for example.
And the fact that adding real utf-8 support limited (limits?) the length of strings that can be indexed
That said, when using utf8mb4 in an index key, MySQL uses the "worst case" of each character being 4 bytes. So it effectively limits the max key size to 3072/4 = 768 characters, when a column is using the utf8mb4 character set.
For practical purposes, this doesn't cause much pain, as it's generally inadvisable to use complete long-ish strings as a key. And there are various workarounds, like using prefixes or hashes as the key, or using binary strings as keys to get the full 3072 bytes (if you don't need collation behaviors).