Live data from Hacker News

Looking Ahead to Postgres 19

snowflake.com

51–60 of 138 posts

Re: Looking Ahead to Postgres 19

#51
post #35

I am looking forward to the day it supports table access methods that enables variety of use cases out of box. Something like rocksdb as PG backend would be fantastic. Yugabyte does this but it's not PG.

OrioleDB seems interesting, not sure it's what you're after but worth a look.

It is, but it's not usable right now without some patches to postgres. At least that was the case as of PG17, and very likely 18 too.

Context: https://www.orioledb.com/docs#:~:text=OrioleDB%20currently%2...

Re: Looking Ahead to Postgres 19

#52
post #37
post #35

I am looking forward to the day it supports table access methods that enables variety of use cases out of box. Something like rocksdb as PG backend would be fantastic. Yugabyte does this but it's not PG.

Salesforce runs Salesforce on postgres with LSM: https://vldb.org/cidrdb/2026/a-multi-tenant-relational-oltp-...

Likely their own fork, not plain PG.

Re: Looking Ahead to Postgres 19

#53
post #38

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.

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.

Re: Looking Ahead to Postgres 19

#54

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…

I was about to post something similar.

There was a big fanfare about orioledb a while ago, and i think it got bought by people that wanted to push that into mainstream postgres?

Did it die somewhere along the road?

Re: Looking Ahead to Postgres 19

#55
post #24
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…

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.

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 ingestion went way faster.

Where we used it: While revamping a large scale sales program, we stored the warehouse in/out in one table, and several things like current stock were calculated using indexed views.

Bonus: Using Snapshot concurrency control, you can do many things concurrently, and only when they both updates to a certain product in the same store you'll get the second transaction failing (which could be retried on the backend).

The fact that they are completely in-sync with your data is amazing.

Re: Looking Ahead to Postgres 19

#56
post #21
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 am currently fighting my way off SQL Server towards PostgreSQL. Windows Server is a real pain to operate and the SQL Server ecosystem expects you to run a lot of add-ons on the server alongside your database. Those don’t translate to managed database services, so you lose a lot of functionality if you jump to RDS or similar. The first party tools are also aging poorly. SSIS and SSRS are not fun. SSMS is ok for what…

Agree about Windows Server. You can run SqlServer on Linux though. I'm not aware of your specific addons, but the Sql Server itself works perfectly well on Linux.

Re: Looking Ahead to Postgres 19

#57
post #29
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?

Don't know of anything wrong with MariaDB, but there used to be plenty wrong with MySQL. To give the most egregious example (THANKFULLY fixed in MariaDB, but was present in MySQL for the longest time), inserting the value 128 into a TINYINT column (signed 8-bit int) would clamp the value rather than returning an error. Which might be what you want... except if that was a primary key column. Marvel at the following, which used to be how MySQL behaved:

Note: the below taken nearly verbatim from https://sql-info.de/mysql/referential-integrity.html#3_5

  CREATE DATABASE foo;
  USE foo;
  CREATE TABLE one ( id TINYINT NOT NULL PRIMARY KEY ) TYPE=InnoDB ;
  CREATE TABLE two (
    id TINYINT NOT NULL PRIMARY KEY,
    INDEX (id),
    CONSTRAINT id_fkey FOREIGN KEY (id) REFERENCES one(id)
  ) TYPE=InnoDB ;
Now that we've created both tables, let's insert a record into table one:

  INSERT INTO one VALUES (127);
And now let's insert a record with a different primary key into table two:

  INSERT INTO two VALUES (128);
MariaDB will give you an error at this point (ERROR 1264 (22003): Out of range value for column 'id' at row 1), but MySQL (at least back when I tried this about ten years ago, which was the last time I was forced to work with MySQL — and I am so glad I never have to go back!) would return no error message and just say "Query OK, 1 row affected (0.009 sec)".

Now let's select the value we inserted into table "two":

  SELECT * FROM two;
And what do we see? The value 127, even though we inserted 128. Which has created a foreign-key relationship to table "one" that we never intended to put in there.

There are other reasons why MySQL was inadequate, but I no longer remember them. Probably MariaDB has fixed them by now. But I no longer have to use MySQL/MariaDB for anything, and I never want to go back. I have a VERY strong averse reaction, caused by past pain, when I think of using MariaDB. (I actually spun up a virtual machine to test what I wrote here, because there's no way I was going to install MariaDB on my primary work machine).

Re: Looking Ahead to Postgres 19

#58
post #38

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.

Postgres's whole origin story is basically to think outside the box and don't be constrained by existing thinking. Stonebraker thought existing databases were too limited in terms of their data types and expressiveness. He started Postgres as an evolution of Ingres (Postgres = Post Ingres) that added rich custom data types and a rewriting system based on rules.

Columnar and all the other fun stuff (JSON, GIS, inverted indexes, embedding vectors) is a natural progression of that thinking. With TimescaleDB, Hydra, Citus, pg_mooncake, etc. becoming very popular the last few years, there is a clear demand for an integrated experience.

(Stonebraker also thought one database shouldn't do everything, as described in his early 2000s "One Size Does Not Fit All" paper, and Stonebraker branched out into HStore/Vertica for columnar. In hindsight, I think that was appropriate for the time, but no longer a significant concern.)

Re: Looking Ahead to Postgres 19

#59
post #54

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…

I was about to post something similar. There was a big fanfare about orioledb a while ago, and i think it got bought by people that wanted to push that into mainstream postgres? Did it die somewhere along the road?

Supabase customers run it (marked alpha).

https://supabase.com/blog/orioledb-launch

And they continue to work on it.

https://supabase.com/blog/orioledb-patent-free

Re: Looking Ahead to Postgres 19

#60
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.

Age old product question. The Honda Civic is much larger today than the original, because the original targeted young people on a budget. As they aged and had kids, they needed more room in the car. Most peoples’ insinct is to buy a newer version of the car they love, so the civic grew to accommodate the aging market.

No real point here other than an observation about how the installed base’s needs change, across industries.

Post reply on HN