Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Looking Ahead to Postgres 19

snowflake.com

Post reply on HN
Print view View original

111–120 of 138 posts

Re: Looking Ahead to Postgres 19

#111

Post by CharlesW »

eatonphil wrote: post #10
breakingcups wrote: post #3

I can't decide whether this person writes in the type of style that was apparently overrepresented in LLM training, or whether they heavily used AI to spruce up their writing. I'm learning towards the latter.

Pangram says the text is entirely AI generated but I don't know how trustworthy Pangram is. (I would love to hear what others think about it.)

Favorable benchmarks for Pangram exist, and it is one of the better AI detectors. But it's never been trustworthy as proof of authorship/misconduct, and it's getting less useful as models (and people's ability to steer them) improve.

https://www.theatlantic.com/technology/2026/05/pangram-ai-de...

Re: Looking Ahead to Postgres 19

#112

Post by ktosobcy »

From more devops-ish perspective: I would love for PostgreSQL to finally have in-place upgrade between (successive) major versions.

Most distros can handle the annoying quirk of having older+newer version to run `pg_upgrade` but when using docker it's pure PITA to upgrade to newer (major) version :/

Re: Looking Ahead to Postgres 19

#113

Post by SigmundA »

rmunn wrote: post #66
ksec wrote: post #29

Earlier quoted context omitted.

>I do myself a favor and always avoid Oracle and MySql/MariaDB. So what's wrong with MySQL or MariaDB?

And although you didn't ask, I'll list what's wrong with Oracle. It's very simple. Oracle treats empty strings as being NULL . Anyone who's never used Oracle before in their life is probably wondering if I'm making it up. I'm not. In Oracle, inserting '' in a VARCHAR column is exactly the same as inserting NULL. And if there's a NOT NULL column, you're not allowed to store the empty string in there. Which means that…

Interesting I have definitely used the distinction between null and empty string quite a bit in MSSQL and matches most programming languages.

Another issue that used to exist was Oracle table name were limited to like 12 characters or something so I have seen horrible abbreviated table names to fit in the Oracle limitation even in other DB's due to some systems being able to run on both MSSQL and Oracle even though SQL Server has a 255 char limit for table names.

Re: Looking Ahead to Postgres 19

#114

Post by Grombobulous »

bob1029 wrote: post #83
colechristensen wrote: post #64

Earlier quoted context omitted.

Can you expand on what is better with MSSQL?

One of the biggest advantages is that a lot of people in the business are already comfortable with the ecosystem. I know that from the perspective of HN that SSMS, pgAdmin, DBeaver, DB Browser for SQLite, et. al. are mostly isomorphic, but from the perspective of everyone else in the business, these are substantially different things to think about. Whether the popularity of the MS ecosystem is good or not is a separ…

I don’t mean to be annoyingly contrarian or argumentative with this statement: I’m definitely not convinced by both of your comments on this subject.

“Comfort” is not really a tangible benefit.

For example, I am personally very comfortable with Chef software for configuration management of VM-deployed applications, but I am quite aware that my own comfort doesn't make it a superior solution versus containerizing applications. We just have Chef around because that’s what was chosen 10 years ago.

Obviously, developer/ops familiarity is still valuable, I don’t mean to say it’s not, but there is a point where the band-aid needs to be ripped off.

I have a hunch that all these great tools that make MS SQL convenient are more like band-aids to a mediocre experience. E.g., RedGate replacing multi-million dollar consultancies sounds great, but what’s even better is not needing a multi-million dollar consultancy in the first place.

I will also give you the context that I used to be a defacto DBA for MS SQL. That doesn’t necessarily mean I know what I’m talking about, but I do know that I personally do not miss SSMS or any of the Microsoft ecosystem.

The whole vibe of that ecosystem is “put your life in Microsoft’s hands and do everything Microsoft’s way and we hold your hand and make it easy, except that making everything easy for everyone causes everything to be massively complicated and brittle.”

I still occasionally get StackOverflow notifications for an answer I wrote which was just “try restarting Visual Studio” and even though the version I wrote it for is over a decade old I still get comments that say “this worked for me.”

Re: Looking Ahead to Postgres 19

#115

Post by kev009 »

khurs wrote: post #88
aljgz wrote: post #14

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player. These days, I do myself a favor and always avoid Oracle and MySql/MariaDB. Postgres is amazing, and the two big things I wished it had: 1. lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurre…

Postgresql is the better product, but doesn't have the horizontal scaling of MySQL/Maria though, so if you want an easy to setup cluster MySQL for high volume online retail store or similar has a use case still.

This hasn't been true for quite a long time, because it's domain of other products for both.

i.e. MySQL/Maria's MM is one of the worse options compared to anything else.. like TiDB or Aurora on AWS for MySQL compat and Yugabyte or CockroachDB for Postgres compat (or Aurora on AWS or AlloyDB on GCP).

Re: Looking Ahead to Postgres 19

#116

Post by roncesvalles »

brightball wrote: post #105
khurs wrote: post #88

Earlier quoted context omitted.

Postgresql is the better product, but doesn't have the horizontal scaling of MySQL/Maria though, so if you want an easy to setup cluster MySQL for high volume online retail store or similar has a use case still.

I think we take for granted how few databases ever outgrow vertical scaling needs. Usually there will be one or two tables that grow at a dramatically faster rate than everything else and I have always found that those belong in a separate data store.

You need replication for HA. Otherwise the only HA you have is the RAID setup on the one machine. The reason people go horizontal is rarely scale. And if you're doing that you might as well use the passive replica as a read replica.

Re: Looking Ahead to Postgres 19

#117

Post by munk-a »

switchbak wrote: post #78
aljgz wrote: post #55

Earlier quoted context omitted.

Indexed views are much faster than trying to achieve the same result with triggers. Triggers have serious concurrency limitations, and you do recalculations even when the fields you depend on are not touched. Indexed views are not much worse than indexes. Of course, when they refer to other tables there are underlying data lookups, but in our experience when we moved from triggers to indexed views, large scale data i…

PG has had incremental view maintenance on the horizon for many years. I expect it to remain on the horizon for a long time. What you're describing is amazing, and I wish I had it available to us. We've hand rolled far too many triggers to achieve the same thing, with all the expected problems you'd assume. I'm sure it could be abused/misused, but a batteries-included approach like that would be huge.

If you are hand-rolling them then I might suggest https://github.com/trickle-labs/pg-trickle#pg_trickle which at least reduces the labor involved in trying to get it up and running and appears to address a lot of the correctness concerns I've traditionally had (like a sync not firing correctly due to a mid-operation outage).

Re: Looking Ahead to Postgres 19

#119

Post by ballon_monkey »

eatonphil wrote: post #10
breakingcups wrote: post #3

I can't decide whether this person writes in the type of style that was apparently overrepresented in LLM training, or whether they heavily used AI to spruce up their writing. I'm learning towards the latter.

Pangram says the text is entirely AI generated but I don't know how trustworthy Pangram is. (I would love to hear what others think about it.)

At some point you're going to have to accept content is AI generated. There's heaps of stuff you probably read daily you don't even realise is AI generated.

Re: Looking Ahead to Postgres 19

#120

Post by timacles »

aljgz wrote: post #14

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player. These days, I do myself a favor and always avoid Oracle and MySql/MariaDB. Postgres is amazing, and the two big things I wished it had: 1. lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurre…

I think even Microsoft has abandoned SQL Server and spends more time improving their various Postgres Azure offerings. Their last major version release since 2022 added some AI features and thats it.

As a DBA, who does a lot of very heavy DBA like stuff, Postgres is in another league from SQL Server. Because Postgres is linux native and open source, its flexibility, introspection and operability, just doesnt have a comparison in SQL Server.

IMO, in the current tech landscape. SQL Server is essentially dead. Only companies using it are legacy windows shops which there are fewer and fewer of.

Post reply on HN