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

Bye Bye Mongo, Hello Postgres

theguardian.com

Post reply on HN
Print view View original

401–410 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#401

Post by vonseel »

magduf wrote: post #218
vonseel wrote: post #212

Earlier quoted context omitted.

I have seen so many critical articles of Mongodb. Even if I did have a use-case particularly well-suited for it, I would never consider using Mongo. As an aside, I did consider using SQL Server until I looked at the licensing fees. Why would someone choose SQL Server when options like Postgres or MySQL/MariaDB exist? Is there a specific SQL feature (MSSQL or Oracle SQL) provides which is not available elsewhere and w…

>Why would someone choose SQL Server when options like Postgres or MySQL/MariaDB exist? Because they're in an organization where they're already invested in Microsoft technologies, so it's much easier to just use MS's DB instead of something entirely different that doesn't integrate as well. It's similar to why many people use Apple software products that aren't as good as alternatives: if you already have an Apple p…

Understood, but I should have prefaced my question with “for greenfield / new development”.

Re: Bye Bye Mongo, Hello Postgres

#402

Post by zorga »

mmsimanga wrote: post #92
SonnyWortzik wrote: post #24

I never got around to using Mongo as my main doc db because it was incredibly hard to find a management tool. I now use json supported functions in SQL Server and do not have the need for a different type of database. SQL Server handles my small 'documents db' implementation with the infrastructure of a RDMS. Win win for me. To me Mongo just got popular by mistake way too early. It's like having a celebrity retweet y…

I don't have any links to prove my point but I suspect we need to thank Mongo for pushing the traditional SQL databases to support JSON.

Why? Seriously, JSON is lame, it's an idiotic trend, a fashion from the UI that's infected the back end for no gain whatsoever for anyone not using JavaScript. XML is better and we've just watch JSON slowly reinvent everything XML already had.

Re: Bye Bye Mongo, Hello Postgres

#403

Post by zorga »

kstrauser wrote: post #392
vincnetas wrote: post #378

Earlier quoted context omitted.

I'm pretty sure you can have one interface for YeSQL an NoSQL. * getUsers() * saveUser() * listUsers() * deleteUser() and implementation can implement it in specific way to take advantage of chosen technology. If you have some esoteric use cases they could be handled in special way separate from business code.

For that specific use case, maybe. Where it falls apart is in `searchUser`, where the methods (and performance characteristics) of digging through the respective databases are going to be radically different. In a newspaper's implementation, you're going to have to search by date, subject, keyword, body text string, reporter, etc. etc. In MongoDB, that generally involves creating an index on the combination of fields…

That objection doesn't make sense. Queries are nothing more than a tree of predicates, how the backend end uses those predicates is not relevant to the API of specifying the predicates. Things like indexes whether in Mongo or in SQL are implementation details that can easily be hidden and not infect the API. You can interpret the tree of predicates into a SQL where clause or into a Mongo index search.

The OP is correct, your app can speak to an internal API without the underlying database infecting your domain code. That in no way implies you can't take advantage of the best of each database.

Re: Bye Bye Mongo, Hello Postgres

#404

Post by philliphaydon »

Thaxll wrote: post #379
philliphaydon wrote: post #287

Earlier quoted context omitted.

Can you give an example of superior tooling or tooling that isn’t good in PostgreSQL compared to MySQL. Serious question. I’m curious cos I mostly use PostgreSQL.

All the Percona tool are for MySQL and there is nothing comparable for PG afaik. https://www.percona.com/doc/percona-monitoring-and-managemen... https://www.percona.com/software/database-tools/percona-tool...

It looks like Percona has partial support for PostgreSQL. It's not as detailed as MySQL.

https://www.percona.com/software/database-tools/percona-moni...

Re: Bye Bye Mongo, Hello Postgres

#405

Post by brianmcc »

nemild wrote: post #30

The Guardian example was heavily used by MongoDB as a case study to pitch their database to others in 2011: https://www.mongodb.com/customers/guardian https://www.mongodb.com/presentations/mongodb-guardian https://www.slideshare.net/tackers/why-we-chose-mongodb-for-... And reupping my previous, three-part series on MongoDB: On MongoDB NoSQL databases were the future. MongoDB was the database for "modern" web engineer…

A great series - thanks! Required reading for anyone preparing to "take a punt" at a technology they've not really done much actual work with.

Re: Bye Bye Mongo, Hello Postgres

#406

Post by int_19h »

zorga wrote: post #403
kstrauser wrote: post #392

Earlier quoted context omitted.

For that specific use case, maybe. Where it falls apart is in `searchUser`, where the methods (and performance characteristics) of digging through the respective databases are going to be radically different. In a newspaper's implementation, you're going to have to search by date, subject, keyword, body text string, reporter, etc. etc. In MongoDB, that generally involves creating an index on the combination of fields…

That objection doesn't make sense. Queries are nothing more than a tree of predicates, how the backend end uses those predicates is not relevant to the API of specifying the predicates. Things like indexes whether in Mongo or in SQL are implementation details that can easily be hidden and not infect the API. You can interpret the tree of predicates into a SQL where clause or into a Mongo index search. The OP is corre…

This is all rosy in theory. In practice, the way you write the query matters quite a bit. Often even between different SQL implementations.

And it's not just queries. Transactions often have important semantic differences that will be visible on application layer - again, even between different SQL implementations (e.g. MVCC vs locks).

Re: Bye Bye Mongo, Hello Postgres

#407

Post by dsirola »

int_19h wrote: post #364
dsirola wrote: post #331

Earlier quoted context omitted.

Why wouldn't you be able to take advantage of those systems? I think it's quite the opposite where you can take the advantages without even knowing about it / affecting other parts of the system.

Because of how different they are, taking advantage of them requires using them in specific ways that are also very different. If you have an abstraction layer that hides those differences, it's practically a given that it does so with the lowest common denominator approach, where you get all the flaws of both and none of their unique benefits. (Alternatively, people find ways to use the abstraction layer such that i…

It's not a common denominator. If I need a Customer aggregate or a Payment aggregate it doesn't matter if I get it from SQL or Document database as long as I get that aggregate. My code doesn't care about query implementation.

Re: Bye Bye Mongo, Hello Postgres

#408

Post by magduf »

abhishektwr wrote: post #192

Good read. Although I don’t quite understand why every few years media companies keep rewriting their content management layer which generally has no impact on company’s top line or bottom line whatsoever. How can these type of investments are justified when all you are doing is recreating exactly same APIs with same data. Am I missing something here?

Yes, you're missing something pretty big.

It's not just media companies rewriting something significant every few years; everyone in the tech industry does it. There's a very good reason for it: it provides interesting and high-paying work for tech employees.

Who wants to go to a company, set up a great system that doesn't need any more work except maintenance, and then just settle down into maintenance mode? No one who wants a rising career. "Maintained system using $oldTech" doesn't look good on a developer's resume, whereas "migrated critical system to $newTech" does.

And it's not just the developers: managers who oversee big teams of developers working on a big new project have more prestige and are paid more than managers who just oversee some boring already-done project that's in maintenance mode.

Now, in this case, there were probably very good genuine reasons for making a big change (I'm no fan of MongoDB), but many times if you look closely with a critical eye, you'll probably find that people padding their resume and making up a reason for their job to exist is the real reason something is being done.

Re: Bye Bye Mongo, Hello Postgres

#409

Post by magduf »

vonseel wrote: post #401
magduf wrote: post #218

Earlier quoted context omitted.

>Why would someone choose SQL Server when options like Postgres or MySQL/MariaDB exist? Because they're in an organization where they're already invested in Microsoft technologies, so it's much easier to just use MS's DB instead of something entirely different that doesn't integrate as well. It's similar to why many people use Apple software products that aren't as good as alternatives: if you already have an Apple p…

Understood, but I should have prefaced my question with “for greenfield / new development”.

My answer is still the same, and actually assumed that. No one is really "greenfield": everyone is already invested in some technology to some extent. If your organization is already invested in MS technologies, your managers only know MS, and your developers only know MS/.NET/etc., then the choice is pretty obvious: MS SQL Server. Switching to Linux/PostgreSQL would be a sea change for an organization like that (even though, IMO, it would be better in the long run).

Similarly, if your organization is already a Linux-based one, running Linux servers for everything, adopting SQL Server would be a huge PITA and would likely be laughed out of the room if suggested.

Re: Bye Bye Mongo, Hello Postgres

#410

Post by zozbot123 »

magduf wrote: post #408
abhishektwr wrote: post #192

Good read. Although I don’t quite understand why every few years media companies keep rewriting their content management layer which generally has no impact on company’s top line or bottom line whatsoever. How can these type of investments are justified when all you are doing is recreating exactly same APIs with same data. Am I missing something here?

Yes, you're missing something pretty big. It's not just media companies rewriting something significant every few years; everyone in the tech industry does it. There's a very good reason for it: it provides interesting and high-paying work for tech employees. Who wants to go to a company, set up a great system that doesn't need any more work except maintenance, and then just settle down into maintenance mode? No one…

> interesting and high-paying work

Busy-work is never interesting, and if it's "high-paying" someone is getting fleeced (and will do what they can so as not to get fleeced in the future). At some point, the constant rewriting will have to stop. In contrast, maintenance work on a well-engineered critical system can be quite interesting in its own right (and it's not like the "maintenance" doesn't involve writing some new stuff on occasion. Nothing is ever truly "done").

Post reply on HN