Live data from Hacker News

Thoughts on PostgreSQL in 2024

jkatz05.com

21–30 of 53 posts

Re: Thoughts on PostgreSQL in 2024

#21
post #11

> building and managing an active-active system is extremely complicated Could Postgres yet evolve to become a Spanner-like multi-writer system?

Is spanner really practical for most people? From my narrow understanding it relies on some specialized clocks and networking

Re: Thoughts on PostgreSQL in 2024

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

Re: Thoughts on PostgreSQL in 2024

#23

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…

so, why wouldn't you use btrfs or zfs?

Re: Thoughts on PostgreSQL in 2024

#24

Earlier quoted context omitted.

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…

On the theme of downtime, how do you handle durability of your SQLite db’s? What if one of the devices goes down?

As a primary last resort there should be a printed paper backup of the database, but it's a snapshot of ticket sales that at this point would be an hour old, and there's always a rush of last minute writes to the database.

The better organised venues write those changes down with a pen, so it's at least up to date, but modern venues have several entrances to get people through the doors faster, so most people won't have the up to date paper backup.

Our system uses a cross platform app on ordinary smart phones to scan tickets. So if a device goes down, you just need to get your hands on another phone.

There's a limited feature set version of the QR code scanner (scan code, screen flashes red or green) that just runs in a web browser on any device with a half decent camera. All you need is the secret URL for the tonights event — which we also expose via a QR code.

Re: Thoughts on PostgreSQL in 2024

#25
post #21
post #11

> building and managing an active-active system is extremely complicated Could Postgres yet evolve to become a Spanner-like multi-writer system?

Is spanner really practical for most people? From my narrow understanding it relies on some specialized clocks and networking

cocroachdb probably better example

Re: Thoughts on PostgreSQL in 2024

#26

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.

That confused be a bit at first too, but that ranking seems to be for how widely they are used (not sure the exact metric), not the ranking of how good they are (which is the dbms of the year page)

Re: Thoughts on PostgreSQL in 2024

#27

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…

so, why wouldn't you use btrfs or zfs?

Because compression is robbing Peter to pay Paul. It saves money on storage, but costs money in compute.

And a lot of data is already compressed (images, etc) so might increase your compute cost without any storage savings.

Filesystems are often the wrong level in the stack to do compression. You want individual control over what data is compressed.

Re: Thoughts on PostgreSQL in 2024

#28

Earlier quoted context omitted.

I think I understand the use case, and effectively you're sharding the data with SQLite. This approach is applicable with multiple databases/datastores. However, would you really change your approach if PostgreSQL could be upgraded by a minor version without any downtime? > One second of downtime will absolutely cause a measurable, and large, cost to your company profits. I want to believe, but I really am not convic…

> However, would you really change your approach if PostgreSQL could be upgraded by a minor version without any downtime? Dunno. I wasn't so much answering the "who wouldn't use Postgres" question, I was more answering "who could possibly care about 1 second of downtime" question. I seriously considered Postgres, and I will reconsider that choice regularly. There are things we have in SQLite right now that would abso…

Right, the local internet can always be an issue too. I think you have a good example of something with high uptime requirements. I get that, but I was kind of wondering specifically why Postgres's downtime would have any significant impact, if it was 1 second. That's hard for me to imagine. I also work in some high resiliency environments but I handle it with queues. No system I ever worked with had a requirement on the DB to have such availability.

Re: Thoughts on PostgreSQL in 2024

#29

Earlier quoted context omitted.

so, why wouldn't you use btrfs or zfs?

Because compression is robbing Peter to pay Paul. It saves money on storage, but costs money in compute. And a lot of data is already compressed (images, etc) so might increase your compute cost without any storage savings. Filesystems are often the wrong level in the stack to do compression. You want individual control over what data is compressed.

> so might increase your compute cost without any storage savings.

I agree with this point, but I think those online compression algorithms add very little overhead, so it is mostly about if Postgres adds enough other benefits compared to your current DB.

The bigger issue potentially is that ext4 is faster than zfs and btrfs itself regardless of compression.

Re: Thoughts on PostgreSQL in 2024

#30
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

Minor correction: Alec Baldwin shot and killed cinematographer Halyna Hutchins, and injured director Joel Souza. Baldwin himself wasn't harmed.

Post reply on HN