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

Thoughts on PostgreSQL in 2024

jkatz05.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Thoughts on PostgreSQL in 2024

#31

Post by chuckadams »

abhibeckert wrote: post #7
Demiurge wrote: post #5

> I’ve even talked to users who have workloads that can only be unavailable for 1s – and while I was initially skeptical, when I heard what the workloads were for, I did agree that 1s was a reasonable requirement for them! What could this be? Some crypto exchange is based on PostgreSQL? I generally don't understand this kind of a requirement. Downtime, to me, is inability to have an end to end transaction. During dow…

I run a service that sells theatre tickets and, far more critically, a service to check if a ticket is valid or not. Tickets are checked, by scanning a QR code, as people walk though the door. Not only do people hate sitting in their seat waiting (or worse, standing in line waiting)... you also need to pay a couple hundred employees to stand around and do nothing while waiting - ballpark cost of wages might be $5 for…

> Alec Baldwin was shot and killed by a "prop" gun

Alec Baldwin is alive and well and is the guy who shot someone with a REAL gun, which had nothing to do with anyone’s lunch breaks.

Re: Thoughts on PostgreSQL in 2024

#32

Post by philippemnoel »

mrj wrote: post #4
jurgenkesker wrote: post #3

Wondering why nothing is said about compression? For MySQL you have Rocksdb with high ZSTD compression. Is the Postgres solution to just use compressed filesystem like ZFS? I could not find much info when researching Postgress, except for Toast compression, which didn't seem very strong. I have a huge DB which would take many TB but now runs on a 500GB footprint. Thanks to Rocksdb/MySQL. Pondering a move to Postgress…

I'm not familiar with Rocksdb but if it's just a KV store you want, I'd probably just use Redis with compression. It is hard to beat. Otherwise, Timescaledb offers compressible table chunks using table inheritance. It's really pretty slick, depending on your use-case.

I think bringing RocksDB into Postgres as a Table access method would really be a powerful feature, as an alternative to heap

Re: Thoughts on PostgreSQL in 2024

#33

Post by brvsft »

abhibeckert wrote: post #7
Demiurge wrote: post #5

> I’ve even talked to users who have workloads that can only be unavailable for 1s – and while I was initially skeptical, when I heard what the workloads were for, I did agree that 1s was a reasonable requirement for them! What could this be? Some crypto exchange is based on PostgreSQL? I generally don't understand this kind of a requirement. Downtime, to me, is inability to have an end to end transaction. During dow…

I run a service that sells theatre tickets and, far more critically, a service to check if a ticket is valid or not. Tickets are checked, by scanning a QR code, as people walk though the door. Not only do people hate sitting in their seat waiting (or worse, standing in line waiting)... you also need to pay a couple hundred employees to stand around and do nothing while waiting - ballpark cost of wages might be $5 for…

> Alec Baldwin was shot and killed by a "prop" gun...

RIP Alec Baldwin

Re: Thoughts on PostgreSQL in 2024

#34

Post by hn_throwaway_99 »

ThinkBeat wrote: post #22

Confusing https://db-engines.com/en/ranking 1. Oracle. 2. Oracle MySql 3. Microsoft SQL Server 4. Postgres. The ranking has been constant over Jan 2024, December 2023 and January 2023. So no change. Postgres did have the biggest increased score in Jan 2023, yet the change did not change its position in the ranking.

Their methodology is here: https://db-engines.com/en/ranking_definition

A lot of it is highly suspect in my opinion. First off, they don't specifically say how they consider Postgres for some of their factors. E.g. in their "Mentions on system websites" section they say

> In order to count only relevant results, we are searching for together with the term database, e.g. "Oracle" and "database".

But I'd expect Postgres mentions to be split a lot between "Postgres" and "Postgresql", and it's not clear they included both terms.

More importantly, the vast majority of these factors are trailing indicators. Even if no same person would use Oracle for a new installation, their existing giant (and very difficult to migrate) install base means you'll see tons of Oracle mentions in LinkedIn profiles and job reqs for decades.

Re: Thoughts on PostgreSQL in 2024

#35

Post by philippemnoel »

This is a great post. As an extension developer myself (pg_bm25), seeing more native support for search-related functionalities that extensions can harness would be really great.

I'm surprised nothing was mentioned around pgBouncer/connection pooling. Having more native support for general connection pooling has been a requested feature in Postgres for a while, and many popular DBMS have it built-in. Just how some of what Patroni offer should be better bundled in (as the author argues), I think the same could/should be true for pgBouncer

Re: Thoughts on PostgreSQL in 2024

#36

Post by [deleted] »

abhibeckert wrote: post #7
Demiurge wrote: post #5

> I’ve even talked to users who have workloads that can only be unavailable for 1s – and while I was initially skeptical, when I heard what the workloads were for, I did agree that 1s was a reasonable requirement for them! What could this be? Some crypto exchange is based on PostgreSQL? I generally don't understand this kind of a requirement. Downtime, to me, is inability to have an end to end transaction. During dow…

I run a service that sells theatre tickets and, far more critically, a service to check if a ticket is valid or not. Tickets are checked, by scanning a QR code, as people walk though the door. Not only do people hate sitting in their seat waiting (or worse, standing in line waiting)... you also need to pay a couple hundred employees to stand around and do nothing while waiting - ballpark cost of wages might be $5 for…

[deleted]

Re: Thoughts on PostgreSQL in 2024

#37

Post by ses1984 »

abhibeckert wrote: post #18
subarctic wrote: post #12

Earlier quoted context omitted.

Doesn't 1 second of database downtime just mean that a ticket that is scanned during that 1 second window will take 1.5-2 seconds to scan instead of, say, 500ms? Why would that result in 10 minutes of troubleshooting?

Because when it doesn't work, they'll get an error message, and then they will try to figure out how to fix the error message. These aren't tech savvy people. You don't hire an IT person to stand at a door scanning a thousand QR codes for 20 minutes three nights a week.

Why would you immediately show an error message instead of some kind of background retry?

Or at the very least the message should tell the operator to retry.

Re: Thoughts on PostgreSQL in 2024

#38

Post by tristenharr »

hinkley wrote: post #2

> Logical replication allows the real-time streaming of changes from a database into any system that can understand the PostgreSQL logical replication protocol. My Christmas wish for 2024-2025 is that we have an industry standard format for replication. A simple transform (hopefully) of either WAL or logical replication, that we can feed into backup software, search, analytics, whatever. There's something out there t…

This would be amazing. Anybody who plugs into the PostgreSQL replication protocol is on my watchlist. I’ve been playing with https://github.com/turso-extended/pg_turso which lets you replicate PostgreSQL tables into SQLite on fly.io using Turso.

I’m still predicting we’re getting a Kafka clone in Rust at some point. No idea who or where from but I’m predicting/hoping.

The world is moving to events. I’d be surprised if 2024 was “the year of events” but I’m sure it’ll be that year sometime in the next 5 years or so.

I want to speak WAL everywhere I go. Let me talk WAL to my vector database, and my OLAP, I want to talk WAL to NoSQL, so what if the schema isn’t enforced, I still want a logical representation of it.

Re: Thoughts on PostgreSQL in 2024

#39

Post by tristenharr »

tristenharr wrote: post #38
hinkley wrote: post #2

> Logical replication allows the real-time streaming of changes from a database into any system that can understand the PostgreSQL logical replication protocol. My Christmas wish for 2024-2025 is that we have an industry standard format for replication. A simple transform (hopefully) of either WAL or logical replication, that we can feed into backup software, search, analytics, whatever. There's something out there t…

This would be amazing. Anybody who plugs into the PostgreSQL replication protocol is on my watchlist. I’ve been playing with https://github.com/turso-extended/pg_turso which lets you replicate PostgreSQL tables into SQLite on fly.io using Turso. I’m still predicting we’re getting a Kafka clone in Rust at some point. No idea who or where from but I’m predicting/hoping. The world is moving to events. I’d be surprised i…

Also, sidenote although pg_turso is experimental I added text, varchar, uuid, timestamp, timestamptz, json and jsonb to the supported types ~1 month ago for anyone who saw it in the past but that was holding them back, don’t let it be what stops you from hacking on it.

I tested it on the chinook music db, I was able to fully replicate a table, although I admit it’s barely functional as a cache because it doesn’t handle relationships or primary/secondary keys and I don’t think it does anything with unique constraints either, but with that said it is functional. It will take a table from Postgres and put it into every region supported by Fly.io and with embedded replicas you can just push it through onto the users device if you want. I jumped out of my chair and was laughing like an idiot the first time I got it to stream the entire chinook music DB from a Postgres creation script straight into SQLite all over the world, all while running postgresql on localhost inside Docker. I can taste the future. XD

Re: Thoughts on PostgreSQL in 2024

#40

Post by alberth »

ThinkBeat wrote: post #22

Confusing https://db-engines.com/en/ranking 1. Oracle. 2. Oracle MySql 3. Microsoft SQL Server 4. Postgres. The ranking has been constant over Jan 2024, December 2023 and January 2023. So no change. Postgres did have the biggest increased score in Jan 2023, yet the change did not change its position in the ranking.

SQLite being 11th seems extremely low on the chart.

Then again, the methodology isnt measuring what you’d expect. Like usage.

https://db-engines.com/en/ranking_definition

Post reply on HN