2

I am rather comfortable writing concrete schemas with explicit primary keys, foreign keys, indexes, views and stored procedures. For queuing I use a NoSQL solution called: Redis.

Recently I heard a web-application development talk where the presenter said he used MongoDB and Node.JS (server-side) with AngularJS on the client-side.

This significantly minimises data conversion; as JSON is used natively across the board.

Are the performance gains from data consistency enough of a reason to develop in NoSQL, rather than relational?

PS: Should note that MongoDB uses BSON, so that could be interchanges for something like CouchDB (correct me if I'm wrong, but that stores as plain JSON)

  • Postgres 9.4 will be faster for JSON than mongodb. Also, reddit uses Postgres as their backend and they serve 1B pageviews a month. – Neil McGuigan Nov 7 '13 at 18:19
2

Are the performance gains from data consistency enough of a reason to develop in NoSQL, rather than relational?

I think your question presupposes a certain way of looking at things. Your fundamental tradeoff with NoSQL is a tradeoff between declarative ad hoc reporting and fast and loose inputs. This tradeoff is unacceptable for many (maybe most) businesses, and so "rather than relational" I think is the wrong way to look at it. Even folks like Martin Fowler advocate something different.

My recommendation is always to start relational and then add NoSQL adjuncts to the rdbms to handle velocity issues when those arise.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.