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…
Looking Ahead to Postgres 19
41–50 of 138 posts
Re: Looking Ahead to Postgres 19
#42Earlier quoted context omitted.
It's not about style or formatting, people are tired of reading slop.
These comments are worse than the slop.
I hope everyone keeps pointing it out. Even better, change the site guidelines to make AI generated articles a flaggable offense. It's already been done for comments.
Re: Looking Ahead to Postgres 19
#43Earlier quoted context omitted.
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
It's not about style or formatting, people are tired of reading slop.
Re: Looking Ahead to Postgres 19
#44SELECT 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 if it's fast. Row-level security is such a useful feature and yet only a fool would contemplate building anything serious with Postgres', as the planner goes haywire and does per-row-matching, nuking performance.
Re: Looking Ahead to Postgres 19
#45I'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?
My list:
No `explain (analyze,buffers)`. Instant DDL has some warts (e.g. fk, metadata locks). Query planning bugs (actually... query planning in general is disappointing). Exiting the repl doesn't stop queries. Implicit type casting. Replication lag from large DDL (e.g. creating an index). Lack of two phase DDL (creating constraints NOT VALID and then VALIDATE later). Lack of extensions (e.g. pg_vector). No safe access to inspect buffer cache. AWS Aurora seems to only add shiny new things to Postgres. And more.
Again, none of this is quite enough to migrate off of it for an established system, but certainly enough to avoid it on a new project.
Re: Looking Ahead to Postgres 19
#46Re: Looking Ahead to Postgres 19
#47Speaking 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.
Re: Looking Ahead to Postgres 19
#48I'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…
Care to share some examples where SQL Server's indexed views would shine? In my eyes they're similar to triggers, which incur a high performance overhead in OLTP systems and are shunned by developers. In OLAP systems custom ETL code will likely outperform them.
Stale MV is a thing you only ever burn your fingers on once. Like how "It's not DNS" is a common meme in networking.
Re: Looking Ahead to Postgres 19
#49Re: Looking Ahead to Postgres 19
#50No word that PostgreSQL 19 introduces native application-time temporal data support based on the SQL:2011 standard? https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...