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

PostgreSQL 14

postgresql.org

Post reply on HN
Print view View original

281–290 of 293 posts

Re: PostgreSQL 14

#281

Post by AtlasBarfed »

kbenson wrote: post #253
AtlasBarfed wrote: post #244

Earlier quoted context omitted.

Jepsen test suite completely tore them a new one. I don't trust any allegedly distributed database that gets excoriated that badly by Aphyr. https://jepsen.io/analyses/mongodb-4.2.6 That's just a bit more than a year ago. Come on. MongoDB is like Mysqldb. I am so so so tired of hearing "that's been fixed, it's great now", doing a paper-thin dive into things, and seeing there are massive problems still. I used MongoDB…

Let's be clear, I definitely don't think it's great. It's just that my immediate response prior to six months ago was to laugh at the mere suggestion it be put into production. The only reason it actually was put into production is because we had a vendor requirement on it (and why they thought it was sufficient, I'm not sure). There's a difference between "not suitable for anything because it's so buggy and there's…

So did you do app-level code to verify writes? Double checking, etc?

Re: PostgreSQL 14

#282

Post by bmcahren »

jenny91 wrote: post #211
jd_mongodb wrote: post #200

Earlier quoted context omitted.

Posting old Jepssen analyses is like pointing at old bug reports. Everytime Jepsen finds a bug we fix it lickety-split. I know it's not cool to focus on that fact, but it is a fact. The Jepsen tests are part of the MongoDB test suite so when we fix those problems they stay fixed. I would love to hear your personal experience of MongoDB as opposed to reposting old Jepsen reports. Perhaps there is something that we can…

The latest "old Jepsen report" is barely a year old. It's not like digging up dirt from years ago. It also seems like there was quite a lot wrong even a year ago, quoting from there: > Roughly 10% of transactions exhibited anomalies during normal operation, without faults. It's just not a very reassuring response to say "when someone goes to dig a bit and finds a lot of show-stopping bugs, we address those specific b…

If you use MongoDB as a document store, arguably it's core functionality, you're not exposed to any of the shortcomings Jepsen rightly identified and exploited weaknesses in.

Transactions are new to MongoDB and they are not necessary for most. Structure your data model so you only perform single-document atomic transactions ($inc, $push, $pull) rather than making use of multi-document ACID transactions. It's possible, we're doing it for our ERP.

Sharding is something we've intentionally avoided opting for application-layer regional clusters. We specifically were avoiding other complexities related to shards that are not a concern for replica sets. Durability and maximum recovery time during emergency maintenance caused us to avoid them.

Re: PostgreSQL 14

#283

Post by bmcahren »

ggregoire wrote: post #185
bmcahren wrote: post #81

Earlier quoted context omitted.

We currently use MongoDB and while Postgres is attractive for so many reasons, even with Amazon Aurora's Postgres we still need legacy "database maintenance windows" in order to achieve major version upgrades. With MongoDB, you're guaranteed single-prior-version replication compatibility within a cluster. This means you spin up an instance with the updated version of MongoDB, it catches up to the cluster. Zero downti…

MongoDB and Postgres are like apples and oranges tho. I'm not gonna choose MongoDB if I need a relational model… even if it offers zero downtime upgrades out-of-the-box.

You might choose Postgres with JSON as an alternative to MongoDB though. There are plenty of people pushing the limits of MongoDB who are researching it if not just for access to a larger pool of DBAs who can work for them.

Re: PostgreSQL 14

#284

Post by bmcahren »

outworlder wrote: post #197
bmcahren wrote: post #81

Earlier quoted context omitted.

We currently use MongoDB and while Postgres is attractive for so many reasons, even with Amazon Aurora's Postgres we still need legacy "database maintenance windows" in order to achieve major version upgrades. With MongoDB, you're guaranteed single-prior-version replication compatibility within a cluster. This means you spin up an instance with the updated version of MongoDB, it catches up to the cluster. Zero downti…

> Edit: Possibly misinformed but the last deep dive we did indicated there was not a way to use logical replication for seamless upgrades. Will have to research. It is possible since PG10 https://severalnines.com/database-blog/how-upgrade-postgresq...

We seem to have been misguided by all of the Amazon RDS and Aurora documentation. It seems Amazon prefers to implement postgres logical replication through their database migration service. All upgrades are typically done through pg_upgrade which does require downtime.

Interesting. I can't wait to see how PG12 influences future offerings from the cloud providers for more seamless major version upgrades.

Re: PostgreSQL 14

#285

Post by burnished »

CRConrad wrote: post #277
burnished wrote: post #220

Earlier quoted context omitted.

What does SJP mean?

"Social Justice" something, probably, like in "SJW" = "Social Justice Warrior". Some people see politeness or compassion as weakness, and ttherefore use terms acknowledging it as pejoratives. The funny thing is, they think this makes objects of derision of their targets, and don't realise that it's themselves it does so.

Ah, I suppose that makes sense. Its weird to me how 'Social Justice Warrior' is derogatory.. because it puts you against people fighting for justice. I get the mind games (I think) you have to play to arrive at the conclusion that SJW is a good insult but its got this "are we the baddies?" energy, to me.

Re: PostgreSQL 14

#286

Post by kbenson »

AtlasBarfed wrote: post #281
kbenson wrote: post #253

Earlier quoted context omitted.

Let's be clear, I definitely don't think it's great. It's just that my immediate response prior to six months ago was to laugh at the mere suggestion it be put into production. The only reason it actually was put into production is because we had a vendor requirement on it (and why they thought it was sufficient, I'm not sure). There's a difference between "not suitable for anything because it's so buggy and there's…

So did you do app-level code to verify writes? Double checking, etc?

I wrote a few small test programs to run doing continuous inserts to the master, and tested shutting down, firewalling off, and killing the process of different members of the cluster and how it recovered and if data loss was experienced by comparing data sets.

It was sufficient for me to not feel like we were taking on undue risk by using it, and since our use case is not one where we're in major trouble if a problem does come about (restoring from daily backups should be sufficient) and we're not doing anything transactional, that's good enough. As I mentioned earlier, it was a vendor requirement, so we just wanted to make sure it wasn't something that was problematic enough to make us question the vendor's decision making.

Re: PostgreSQL 14

#287

Post by hodgesrm »

zozbot234 wrote: post #232
hodgesrm wrote: post #228

Earlier quoted context omitted.

> All in all, my impression of MongoDB now is that they're one of those "fake it till you make it" success stories, where they leveraged their popularity into enough momentum to fix most their major problems. That's not all bad. The same could be said of MySQL. Both DBMS prioritized ease of use over data integrity in the early going.

And yet PostgreSQL making the exact opposite choice has really paid off in the longer run. People used to dismiss it as simply a toy for academics to play with, and look where the project is today. It can easily surpass most NoSQL databases on their home turf.

To be fair PostgreSQL 15 years ago also had a lot of problems storing data reliability. Some of them manifested as performance issues. I also heard a fair number of war stories about corruption with "large" databases (e.g., 1TB+). PG replication lagged MySQL for many years as well. These seem to be non-issues today.

At this point there's effectively no difference in the durability of data stored in MySQL or PostgreSQL, so it's hard to argue that one or the other made a better choice. They just got there by different paths.

In fact, PostgreSQL is winning back share in part because of licensing. GPLv2 is limiting for a lot of applications, and there continue to be concerns about Oracle ownership. It's also absorbed a lot of features from other databases like JSON support. That's not special to PostgreSQL though. It's been a trend since the beginning for SQL RDBMS and explains why they have stayed on top of the OLTP market for decades.

Re: PostgreSQL 14

#288

Post by coded »

oauea wrote: post #141
tomhallett wrote: post #116

Earlier quoted context omitted.

Coming from the outside, with zero understanding of the internal details, my hunch is the same: lack of support for logical replication is more of a business decision than a technical decision. (But again, this a hunch -- partially based on how good heroku is from a technical perspective)

It's absolutely an evil business decision, and all the clouds are playing this game. Don't ever use a hosted database solution if you're thinking about storing any significant amount of data. You will not be able to get it out without downtime.

It looks like gcp supports logical replication now: https://cloud.google.com/blog/products/databases/you-can-now...

Re: PostgreSQL 14

#289

Post by bfelbo »

mixmastamyk wrote: post #275
bfelbo wrote: post #263

Earlier quoted context omitted.

Interesting, thanks! I wonder how easy it would be to write a VS Code plug-in using that.

If you can run a linter, you can run it as well.

Ah, good point! I might try to create an eslint rule that incorporates it.

Re: PostgreSQL 14

#290

Post by oauea »

coded wrote: post #288
oauea wrote: post #141

Earlier quoted context omitted.

It's absolutely an evil business decision, and all the clouds are playing this game. Don't ever use a hosted database solution if you're thinking about storing any significant amount of data. You will not be able to get it out without downtime.

It looks like gcp supports logical replication now: https://cloud.google.com/blog/products/databases/you-can-now...

The big question is: Can you enter arbitrary IP addresses, or do you have to replicate to another GCP instance? Azure does the latter.
Post reply on HN