Live data from Hacker News

Goodbye MongoDB, Hello PostgreSQL

developer.olery.com

81–90 of 388 posts

Re: Goodbye MongoDB, Hello PostgreSQL

#81

As a greying developer I am most amused by people discovering that 'old' technologies like SQL databases work really well. The only useful piece of advice I can give a younger developer is... be careful when drinking the newtech koolaid. And one more thing: star = Sequel.lit('*') User.select(:locale) .select_append { count(star).as(:amount) } .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percen…

Wait... does preferring to write SQL (and knowing how) make me old now?

Dang.

Re: Goodbye MongoDB, Hello PostgreSQL

#84

It's very tiring to read things like this. And that is not meant as support for Mongo, quite the contrary in fact.

It's interesting that if you search for MongoDB vs Postgres, you won't find any articles suggesting you should go from P to M.

Supposedly WiredTiger for M 3.0 will be more everything, including faster and better.

We'll see.

Re: Goodbye MongoDB, Hello PostgreSQL

#85

As a greying developer I am most amused by people discovering that 'old' technologies like SQL databases work really well. The only useful piece of advice I can give a younger developer is... be careful when drinking the newtech koolaid. And one more thing: star = Sequel.lit('*') User.select(:locale) .select_append { count(star).as(:amount) } .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percen…

It's not so much about not wanting to write/understand SQL (both are still very much required), but about composability. If you want to re-use bits of a SQL query written as a string literal your only option is string concatention or using some kind of string builder/template system. In both cases there's little validation of the query's correctness (syntax wise) until you actually run it.

While I agree that many ORMs go too far or even worse, not implement certain powerful features, Sequel (and similar tools I imagine) strikes a nice balance. The particular examples I gave on their own are not super useful, but we already have quite a few queries that are composed/re-used without having to concat strings.

So tl;dr: it's about composability, not being "lazy" or "ignorant" to SQL.

Re: Goodbye MongoDB, Hello PostgreSQL

#86
post #58
post #36

Earlier quoted context omitted.

The real issue isn't "newtech koolaid" it is the definition of the problem. I find that people that don't understand the problem like MongoDB for the ability to be "flexible" in designing and modifying down the road. Though I like to argue you have flexibility in SQL also.

I agree, I've read a few 'screw Mongo, I'm going to SQL' type blogs, it really seems like they either didn't grasp how to architect Mongo correctly and tried to do things that don't work well with it, or they had a problem that was better solved by SQL in the first place. SQL does many things very well that noSQL stuff won't. Also vice-versa.

I couldn't agree more with you. I love SQL for when I have a concrete data model, when I don't I love NoSQL. I could use both if I really wanted to, but you need to know when to force a square peg into a circle. Mongo has a good how to on it here. http://blog.mongodb.org/post/72874267152/transitioning-from-...

Re: Goodbye MongoDB, Hello PostgreSQL

#87

Is there anybody here who has run MongoDB at moderate scale with good results? As in a few terabytes of data, >10k ops/second territory. I've been really disappointed with its reliability and performance in situations where I've been around that.

I've been using mongo on 39M+ records (tracking financial tick data) across 73 assets (collections) and my queries take anywhere between 2-3mins depending on complexity. You can always run db.currentOp() in the mongo shell to see what process is taking forever as well. Let me clarify why though, there methods of optimizing a query by adding another field, but since I have to traverse my records with the sort() cursor…

Jesus Christ!

I remember querying databases with 100 tables and millions of records in foxpro a century ago and it took less than a second.

What has happened to the world while I was in cryogenic state? Take me back to the nitrogen pool!

Re: Goodbye MongoDB, Hello PostgreSQL

#88
post #58
post #36

Earlier quoted context omitted.

The real issue isn't "newtech koolaid" it is the definition of the problem. I find that people that don't understand the problem like MongoDB for the ability to be "flexible" in designing and modifying down the road. Though I like to argue you have flexibility in SQL also.

I agree, I've read a few 'screw Mongo, I'm going to SQL' type blogs, it really seems like they either didn't grasp how to architect Mongo correctly and tried to do things that don't work well with it, or they had a problem that was better solved by SQL in the first place. SQL does many things very well that noSQL stuff won't. Also vice-versa.

I honestly don't think I've ever seen a valid use case for Mongo. If you're going to query your data, you have to know what fields you're looking for, right? So why not create a schema that has those fields?

Re: Goodbye MongoDB, Hello PostgreSQL

#89
post #28

As a greying developer I am most amused by people discovering that 'old' technologies like SQL databases work really well. The only useful piece of advice I can give a younger developer is... be careful when drinking the newtech koolaid. And one more thing: star = Sequel.lit('*') User.select(:locale) .select_append { count(star).as(:amount) } .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percen…

I agree, using ORMs and such hide the real SQL and make it much harder to optimize by using explains etc.

Just have Rails dump the query and stick "EXPLAIN" before it.

Re: Goodbye MongoDB, Hello PostgreSQL

#90

This post reflects an interesting technical narrative of companies switching off MongoDB to more traditional relational databases as they grow. Importantly, I don't think that's an indictment of MongoDB. Instead, it highlights the key advantages of NoSQL: ease of use and rapid iteration. When you're first working on a project, MongoDB is very easy to slap in. You don't even have to create tables/collections. As you i…

Really, you can't spend the 10 minutes designing a table structure in a SQL database? And now you have to spend months re-inventing the wheel because you wanted an easy out? This post reflects on developers being lazy, instead of doing it right the first time around. Oh no, you have to log in to the db and run a CREATE TABLE statement every few months when you need to scale. Cry some more. And even then, 'lazy' is su…

You don't even need to design the schema, just add the bits you need as you go (updating the schema takes about 20 seconds with rails for instance).
Post reply on HN