> building and managing an active-active system is extremely complicated Could Postgres yet evolve to become a Spanner-like multi-writer system?
Thoughts on PostgreSQL in 2024
21–30 of 53 posts
Re: Thoughts on PostgreSQL in 2024
#221. 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
#23Wondering 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…
Re: Thoughts on PostgreSQL in 2024
#24Earlier 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?
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> 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
#26Confusing 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
#27Wondering 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?
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
#28Earlier 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…
Re: Thoughts on PostgreSQL in 2024
#29Earlier 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.
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> 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…
Minor correction: Alec Baldwin shot and killed cinematographer Halyna Hutchins, and injured director Joel Souza. Baldwin himself wasn't harmed.