I didn't know about extension repositories like https://database.dev/ . What less-known extensions are people here using? I'm curious because there might be extensions that simplify common tasks in ways I'm unaware of.
Thoughts on PostgreSQL in 2024
41–50 of 53 posts
Re: Thoughts on PostgreSQL in 2024
#42> 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…
Heavily used authentication systems can be near that, as can things like a PG backend to Radius:
https://en.wikipedia.org/wiki/RADIUS
I was working with a proprietary Radius system a while ago that used PG for it's database backend. That system had been around for many years and had (smaller) national telcos/ISPs as customers.
When people's internet routers turn on and authenticate to their ISP, this is the kind of system it talks too.
The steady state load for this system just over 300k transactions per second (24/7), sometimes peaking to over double that during busy times.
The most memorable problem was pgBadger (reporting tool) often running out of memory on 256GB (ram) nodes because perl seems to have extremely poor (non-existent?) garbage collection. :(
Re: Thoughts on PostgreSQL in 2024
#43Confusing 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 Postgre…
As someone who has worked with Oracle, mssql and postgres: If it gets complex I tend to use a search engine for oracle or mssql, for postgres I go straight to their official docs. Postgres documentation quality is very good and honest.
Also, the number of postgres weird edge cases and ad hoc hacks in SQL feels lower.
If my experience generalizes, this ranking will score you higher the more support you need. Well working software generates less noise and is measured as less popular as a result.
Re: Thoughts on PostgreSQL in 2024
#44“The document discusses where PostgreSQL is heading in 2024 and beyond. It focuses on three key areas: availability, performance, and developer features. For availability, the author sees logical replication and reducing downtime for upgrades and maintenance as important goals. Performance improvements may come from asynchronous I/O, parallel recovery, and maximizing resource usage on large instances. On developer features, priorities include supporting more of the SQL/JSON standard and making migration from other databases easier. The author also notes opportunities around PostgreSQL extensions, community building, mentorship, and diversity/inclusion. Overall, the community is actively working to improve PostgreSQL in many dimensions.” –Kagi summarizer.
Re: Thoughts on PostgreSQL in 2024
#45[dead]
Re: Thoughts on PostgreSQL in 2024
#46Earlier 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…
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?
it isn't downtime he's as concerned about as it's about speed
he could build in behavior to retry/wait for several seconds before erroring out but his selling point is speed seemingly (with little risk of sale negatives/positives/theft)
Re: Thoughts on PostgreSQL in 2024
#47Earlier 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…
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?
That doesn’t have to incur actual downtime if you use pgbouncer in front of Postgres and pause the pool.
Re: Thoughts on PostgreSQL in 2024
#48Wondering 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 think the page features patch (which is a precursor to TDE, which Jonathan does mention) likely paves the way for better compression options.
Re: Thoughts on PostgreSQL in 2024
#49> building and managing an active-active system is extremely complicated Could Postgres yet evolve to become a Spanner-like multi-writer system?
It can be done like https://github.com/yugabyte/yugabyte-db/ has.
Re: Thoughts on PostgreSQL in 2024
#50[dead]