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

61–70 of 138 posts

Re: Looking Ahead to Postgres 19

#61

Post by chucksmash »

sega_sai wrote: post #53
tyre wrote: post #38

Earlier quoted context omitted.

You might be using the wrong database if that’s what you’re hoping for. Columnar databases are a separate category. It’s like saying that you’re getting worried Apple doesn’t sell washing machines.

PostgreSQL was a right tool for my task for many years. It is a question for PostgreSQL can adapt to a new reality of much bigger datasets or I have to switch to a new tool. And I am not the only user of Postgresql in this context. So it is easy to say in vacuum 'you are using the wrong database', but it's not something that can be easily changed with 100s of Tb of data, existing user workflows etc.

Just because it's easy to say doesn't mean it's wrong.

By the same logic, you could say Microsoft Access should have all the capabilities of Postgres because it's painful for small businesses to move off of it when it's no longer a good fit for their needs.

Re: Looking Ahead to Postgres 19

#62

Post by aeturnum »

iterateoften wrote: post #11
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.

These low effort constant comments about style or formatting are against Hackernews guidelines for discussions and something needs to be done to clean up the comment section. Getting to a ridiculous point

If comments about how "this blog post could have been a link to this github repo" are in-bounds, so are comments about how "this could have been a link to a LLM session." HN has always tried to work out if a submission is novel and interesting work or is just a slick coat of paint on mundane work (sometimes if good work is obscured by insufficiently clever presentation). Highlighting that content was generated by an LLM and asking if that impacts how to understand it is entirely in keeping with our culture and standards.

Re: Looking Ahead to Postgres 19

#63

Post by joinjune »

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…

Oracle = Pain, Suffering, High Costs, Litigation, and Human Misery. If it wasn't for non-technical middle management that likes the perks of buying high cost software from vendors that throw nice parties they'd be out of business.

Re: Looking Ahead to Postgres 19

#64

Post by colechristensen »

bob1029 wrote: post #31
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…

SQLite and MSSQL are my two solutions for relational storage problems. If I am going to use a "free" provider, SQLite is impossible to beat. They cover a majority of use cases today. SQLite starts to fall apart with backup, replication and tooling. If I am on the hook for things like system availability and disaster recovery, I don't have a problem spending money to cover my ass. If I am going to pay any amount of mo…

Can you expand on what is better with MSSQL?

Re: Looking Ahead to Postgres 19

#65

Post by SigmundA »

tyre wrote: post #38
sega_sai wrote: post #36

Speaking as long-term (>15 years) user of Postgres in science, I am getting worried about the lack of columnar type of storage in Postgresql. As the datasets become bigger and bigger, the limitations of PG's storage are becoming more and more significant. I know there are various extensions (i.e. cetus) that may offer such functionality, but then you depend on that extension being supported in the future, as well add…

You might be using the wrong database if that’s what you’re hoping for. Columnar databases are a separate category. It’s like saying that you’re getting worried Apple doesn’t sell washing machines.

I don't agree, a relational database is not required to have a particular storage engine or format, that is an implementation detail.

There are other relational databases that have both kinds of storage engines and some use both on the same table (row based insert with column based migration and secondary column store indexes: https://learn.microsoft.com/en-us/sql/relational-databases/i...

Just like you can have b-tree based table storage vs heap in the case of index organized tables / clustered indexes (which pg doesn't have) you can choose column based instead the logical data model is still the same relational model.

Re: Looking Ahead to Postgres 19

#66

Post by rmunn »

ksec wrote: post #29
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 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 in Oracle, you do not have any way of distinguishing "I don't know the person's middle name" vs. "I know what the person's middle name is: he/she doesn't have one".

There are apparently historical reasons for this, but I don't care. The empty string is NOT the same as NULL, and any software that treats them as the same IS BUGGY!

Sorry. Had to get that off my chest. I know I'm answering a question you didn't ask, but that has been bothering me for nearly 25 years (I first learned about this misfeature of Oracle's in 2002 or 2003), and I just had to vent to somebody who would understand.

Re: Looking Ahead to Postgres 19

#67

Post by hobofan »

mickeyp wrote: post #44

The graph database feature looks interesting, but I wonder... SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name)); That is _awful_ syntax; it is reminiscent of neo4j, which is surely not a tool anyone serious should copy from outright in 2026. And of course the final thing I am left wondering is…

That is not a homebrew sytax that Postgres came up with themselves.

It's SQL/PGQ, which was derived from the Cypher language for Neo4J and now is part of the SQL standard.

Re: Looking Ahead to Postgres 19

#68

Post by SigmundA »

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 also miss clustered indexes, datetimeoffest, plan caching and query hints from MSSQL.

Re: Looking Ahead to Postgres 19

#69

Post by khurs »

sega_sai wrote: post #36

Speaking as long-term (>15 years) user of Postgres in science, I am getting worried about the lack of columnar type of storage in Postgresql. As the datasets become bigger and bigger, the limitations of PG's storage are becoming more and more significant. I know there are various extensions (i.e. cetus) that may offer such functionality, but then you depend on that extension being supported in the future, as well add…

"As the datasets become bigger and bigger,"

I think the better way is to use Postgresql for new data and routinely archive off older data to data warehouse type database, to keep the Postgres one small.

(Many companies also now use a RDBMS alongside either a KV database or document store in main app)

Post reply on HN