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

221–230 of 293 posts

Re: PostgreSQL 14

#221

Post by threeseed »

outworlder wrote: post #196
kbenson wrote: post #156

Earlier quoted context omitted.

As someone that mostly shared that opinion for the last decade or more, I recently set up a cluster for work, and everything seems much more production level quality than I remember or what I assumed it was going to be like. I'm not the one using it for queries every day, but I did do a bunch of testing for replication and failed nodes to confirm that I understood (and could rely) on the claims of robustness, and it…

One thing that turned me away from MongoDB was their utter lack of care for your data integrity that they displayed for years. Some of those instances were even documented. Then there were some bad defaults - some could _also_ cause data loss. For any component that's viewed as a database (as opposed to, say, cache), data integrity is one of the most important metrics (if not THE most). In contrast, PostgreSQL data l…

Those defaults were changed a decade ago and were never an issue if you used a driver eg. Python.

And the Jepsen tests are part of the core test suite so do you some evidence they are still failing.

It’s so ridiculous and pointless to be rehashing the same issues a decade later.

Actually more a testament to the company that it’s still hugely successful and depended on by some very large applications.

Re: PostgreSQL 14

#222

Post by brightball »

why-el wrote: post #161
brightball wrote: post #159

Earlier quoted context omitted.

There’s a Ruby gem called strong_migrations that does this. It’s fantastic and I include it on all of my Ruby projects.

The gem does not solve these issues, merely tells you about them (and even then it can't catch all of them, only the ones that Rails defines).

It gives you mitigation strategies.

The mere presence of it on the dev workflow keeps your developers thinking about these types of issues as well, which goes a long way.

Re: PostgreSQL 14

#223

Post by dijit »

nix23 wrote: post #210
dijit wrote: post #208

Earlier quoted context omitted.

MySQL migrations are beyond a joke. It’s absolutely impossible that you’re not trolling with such a statement.

Copy/hardlink the data-files and start the new engine instead have to make a dump and import it? It's a joke that you have to make a offline dump and import for upgrades with pgsql.

Did you miss this? https://www.postgresql.org/docs/10/pgupgrade.html

Re: PostgreSQL 14

#224

Post by dralley »

kbenson wrote: post #156
TedShiller wrote: post #146

Earlier quoted context omitted.

The problem with MongoDB though is that you're on MongoDB

As someone that mostly shared that opinion for the last decade or more, I recently set up a cluster for work, and everything seems much more production level quality than I remember or what I assumed it was going to be like. I'm not the one using it for queries every day, but I did do a bunch of testing for replication and failed nodes to confirm that I understood (and could rely) on the claims of robustness, and it…

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

The downside being that their reputation is now somewhat charred.

Re: PostgreSQL 14

#225

Post by staticassertion »

The_Colonel wrote: post #203
mayankkaizen wrote: post #184

Earlier quoted context omitted.

That was sarcasm. But yeah, you can search for MongoDB and you'll come across many many posts criticizing it. It can be said Mongodb is hated ad much as Postgres is loved. Personally I have no opinion about mongodb.

Yes, and most of these love/hate memes are blowned out of proportion by people who don't actually have any real expertise in those technologies, but just parrot whatever they've read in some memes.

You're exactly correct. Tons of "XYZ is bad" because of some meme that they don't even understand or have context on that hasn't been relevant for years.

I have no idea if MongoDB is good or bad at this point, but the comments of "haha it's mongo" are completely devoid of meaningful content and should be flagged.

Re: PostgreSQL 14

#227

Post by dralley »

threeseed wrote: post #221
outworlder wrote: post #196

Earlier quoted context omitted.

One thing that turned me away from MongoDB was their utter lack of care for your data integrity that they displayed for years. Some of those instances were even documented. Then there were some bad defaults - some could _also_ cause data loss. For any component that's viewed as a database (as opposed to, say, cache), data integrity is one of the most important metrics (if not THE most). In contrast, PostgreSQL data l…

Those defaults were changed a decade ago and were never an issue if you used a driver eg. Python. And the Jepsen tests are part of the core test suite so do you some evidence they are still failing. It’s so ridiculous and pointless to be rehashing the same issues a decade later. Actually more a testament to the company that it’s still hugely successful and depended on by some very large applications.

Perhaps, but mongodb was responsible for something I have bookmarked as "the worst line of code ever".

Which decided whether or not to log connection warnings based on Math.random()

https://github.com/mongodb/mongo-java-driver/blob/1d2e6faa80...

Re: PostgreSQL 14

#228

Post by hodgesrm »

kbenson wrote: post #156
TedShiller wrote: post #146

Earlier quoted context omitted.

The problem with MongoDB though is that you're on MongoDB

As someone that mostly shared that opinion for the last decade or more, I recently set up a cluster for work, and everything seems much more production level quality than I remember or what I assumed it was going to be like. I'm not the one using it for queries every day, but I did do a bunch of testing for replication and failed nodes to confirm that I understood (and could rely) on the claims of robustness, and it…

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

Re: PostgreSQL 14

#229

Post by magicalhippo »

JohnBooty wrote: post #120
paulryanrogers wrote: post #24

Earlier quoted context omitted.

Pg docs are so good I reference them whenever I want to check the SQL standards, even if I'm working on another DB. (I prefer standard syntax to minimize effort moving DBs.) Otherwise maybe try it with a toy project.

I stick to standard SQL syntax/features whenever possible as well, but... Honest question: how often do you switch databases? I've never really found myself wanting or needing to do this. Only time I could really see myself wanting to do this is if I was writing some kind of commercial software (eg, a database IDE like DataGrip) that needed to simultaneously support various multiple databases. > MySQL It feels partic…

We got an application which has been developed for over 20 years with the mentality of "we're never switching db's".

Yet now we are, because some core customers demand MSSQL support...

Of course the db we're using supports all kind of non-standard goodness that has been exploited all over. Gonna be fun times ahead...

Re: PostgreSQL 14

#230

Post by ablekh »

zozbot234 wrote: post #217
ablekh wrote: post #214

Congratulations and thanks to all involved! Do I understand correctly that, at this time, while PG has data sharding and partitioning capabilities, it does not offer some related features found in Citus Open Source (shard rebalancer, distributed SQL engine and transactions) and in Citus on Azure aka Hyperscale (HA and streaming replication, tenant isolation - I'm especially interested in the latter one)? Are there an…

Streaming replication is supported as per https://www.postgresql.org/docs/current/warm-standby.html#ST... . You can likely build shard rebalancing and tenant isolation on top of the existing logical replication featureset. There are some groundwork features for distributed transactions (PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED), but they're not supported as such.

I see. Thank you for clarifications.
Post reply on HN