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

31–40 of 138 posts

Re: Looking Ahead to Postgres 19

#31

Post by bob1029 »

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 money at all, I am going all the way. The developer experience around MSSQL is untouchable. SSMS and VS with sql projects runs circles around contemporary entity framework crap. Sprinkle in 3rd party tools from vendors like RedGate and you can replace multi-million dollar consulting packages.

I wouldn't ever advocate for standing up a new Oracle or DB2 machine, but if one was already in place I'd probably die on the hill of not trying to refactor it away. These databases typically come with multi-volume ghost stories attached. Reinventing all those weird effects on a new engine will typically kill the business if there are no other options available.

Re: Looking Ahead to Postgres 19

#32

Post by hotsauceror »

pbronez wrote: post #21
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 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…

What are some of the add-ons that you run on the server? We run ours in a pretty bare-bones manner so I'm interested to hear what you're doing.

Re: Looking Ahead to Postgres 19

#33

Post by asah »

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…

two techniques I use with pg:

1. "materialize" the view as a full table, then index that. Any reasonable pipeline/ETL tool can provide incremental updates between tables. Obviously, anything materialized requires considerations around storage, replication, backup/restore, I/O, etc.

2. use a regular VIEW and index (precisely) the underlying expressions mentioned in the view, i.e. so when the view is used, then the indexes get used.

Both require rewriting SQL, though I've used VIEWs to make the change transparent.

Re: Looking Ahead to Postgres 19

#34

Post by Jysix »

I'm dreaming of block compression in Postgresql, instead of only row compression, too limited to be effective. I know you can store your data on a Zfs pool with block compression, but having it native would remove the burdain of setting this up and maybe better perf.

Re: Looking Ahead to Postgres 19

#35

Post by tehlike »

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.

Re: Looking Ahead to Postgres 19

#36

Post by sega_sai »

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 additional complexity.

Re: Looking Ahead to Postgres 19

#37

Post by prpl »

tehlike wrote: 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-...

Re: Looking Ahead to Postgres 19

#38

Post by tyre »

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.

Re: Looking Ahead to Postgres 19

#39

Post by chuckadams »

cwnyth wrote: post #19
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…

What's wrong with MariaDB?

Last I looked, MariaDB still implemented JSON columns as LONGTEXT under the covers, making it a non-starter for any serious use of said type.

Re: Looking Ahead to Postgres 19

#40

Post by Guillaume86 »

tehlike wrote: 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.
Post reply on HN