Live data from Hacker News

Bye Bye Mongo, Hello Postgres

theguardian.com

181–190 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#181

Earlier quoted context omitted.

When was the last "Goodbye X, Hello Mongo" article?

Not sure, but there was Goodbye MySQL, Hello Postgres and Goodbye Postgres, Hello MySQL (same company did it actually) for sure. It is kind of weird why engineers are so obsessed with tools though.

> It is kind of weird why engineers are so obsessed with tools though.

Would you say the same thing about programming languages?

I was actually listening to the Full Stack Radio podcast, and the latest episode talked about the power of moving more into the database. What struck me as a strong idea was that we can't treat databases as equivalent - different database servers have different strengths (for example, some have better JSON support or time evaluation functions).

I think it's particularly telling that you seem to be thinking of the database as a "tool", but if you're like most, you fight religious battles over your language of choice. In my experience, the database IS the application (and in many cases, the business) and is a far more important choice than the implementation language, the cloud provider, etc.

Re: Bye Bye Mongo, Hello Postgres

#182
post #62
post #42

Earlier quoted context omitted.

Fashion driven development and not understanding how to actually make use of SQL.

IMO there is still a place for schema-less document databases. It's just that Postgres's JSON columns mean you can get the best of both worlds, which makes Mongo look weak by comparison.

I would say that development of JSON fields in Postgres and MySQL was accelerated by the adoption of Mongo.

Speed to market/first version using JSON stores is attractive, especially when you're still prototyping your product and won't have an idea of exact data structures until there's been some real world usage.

Re: Bye Bye Mongo, Hello Postgres

#183
post #143
post #68

Earlier quoted context omitted.

I think you're asking the wrong question. The question should be: How did MongoDB become so successful? IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. MongoDB was the natural choice because they excelled at being accessible to devs who were already familiar with Javascript and JSON. Not only that, their marketing/outreach efforts were also…

Absolutely - if you don't know SQL and you do know JSON, postgres looks scary and Mongo looks familiar.

Saying "I don't know SQL so I will just use JSON" really misses the point though. SQL is easy. Data is hard. NoSQL products offer to get rid of SQL which includes an implication that SQL itself was the challenge in the first place. The problem then is that you have lost one of the best tools for working with data.

Re: Bye Bye Mongo, Hello Postgres

#184

Earlier quoted context omitted.

Exactly, I have moved companies from random web framework + random database to static site generators + CDN with high rate of success too. No point of using Rails/Django like stuff unless you have an extremely good case to, which is certainly not the Guardian use case.

Genuine question - because I'm currently doing CPR on an old Rails app with Mongo - what do you see as a "good use case" for Rails/Django and similar frameworks?

We used to use them internally for building a system management application that required talking to databases and an API that nodes could pull information from. This pre-dates system management tools like Chef, Ansible and it was just a tool like that. There is also workflow management tools that (like managing Hadoop jobs for example) that could be written in these. Generally, things where you need to deal with a lots of state (and state changes) from the outside world. I am pretty sure there are other use cases.

Re: Bye Bye Mongo, Hello Postgres

#185
post #175

Earlier quoted context omitted.

At "large financial news company" we had a "designed for the CV" tag that applied to stupid architectural decisions (of which there were many) One of the biggest and most expensive was using Cassandra to store membership details. Something like 4 years of work, by a team of 40, wasted by stupid decisions. They included: o Using Cassandra to store 6 million rows of highly structured, mostly readonly data o hosting it…

well Elixir might have being a good decisions :)

only if more than 0.3% of your workforce know it....

Re: Bye Bye Mongo, Hello Postgres

#187
post #143

Earlier quoted context omitted.

Absolutely - if you don't know SQL and you do know JSON, postgres looks scary and Mongo looks familiar.

You make it sound like learning SQL is like learning Assembler. It's not that hard. And ORMs exist in every language to abstract it all away. PostgreSQL looks scary because it is a swiss army knife. It has a million different features and data structures. MongoDB does only one thing.

Assembly language isn’t hard. It’s actually quite simple. The issue with learning assembly is the absolutely useless otherwise domain knowledge.

Document-based storage definitely fits the generalised use-case better than tabular storage.

Re: Bye Bye Mongo, Hello Postgres

#188
Standard disclaimer in database discussions involving NoSQL:

SQL is not RDBMS is not ACID is not NoSQL.

When comparing NoSQL to something you should really compare it to RDBMS which is what most people conflate with "SQL". This conceptual understanding gap is IMO what led to the huge growth and misuse of "NoSQL" for a decade.

Re: Bye Bye Mongo, Hello Postgres

#189

If anyone is considering doing something similar today, I'd suggest to take a look at the recent FoundationDB Document layer which speaks MongoDB v3 ( https://foundationdb.github.io/fdb-document-layer/ ). I haven't tried it yet, and there are some limitations at the moment, but I find it extremely promising.

I would advise not to use such a baroque technology unless IT is your main activity.

Most of the times a boring database is a better fit.

Not everybody can be an early adopter, especially on the software which stores what is arguably your most precious asset.

Re: Bye Bye Mongo, Hello Postgres

#190
post #143

Earlier quoted context omitted.

Absolutely - if you don't know SQL and you do know JSON, postgres looks scary and Mongo looks familiar.

You make it sound like learning SQL is like learning Assembler. It's not that hard. And ORMs exist in every language to abstract it all away. PostgreSQL looks scary because it is a swiss army knife. It has a million different features and data structures. MongoDB does only one thing.

Well, that and SQL has a somewhat undeserved reputation for being easy to learn, but also easy to screw up. Like you write a simple looking query and it turns out to have O^2 complexity and your system ends up bogged down in the database forever.

In practice people who fall into complexity traps are usually asking a lot more of their database engine than any beginner. It's usually not that hard to figure out the approximate cost of a particular query.

Post reply on HN