[galdosdi]

Weird, speed of development and execution is exactly why/when I would reach for Just using a SQL based RDBMS.

Whereas, going to a non-relational solution would be something I'd do when I needed to trade away simplicity and consistency in exchange for scaling/performance for specific cases where relational can't handle the write load. Losing the schema and ability to do joins and arbitrary queries and assume transactionality is a big loss that requires lots of work.

A dirty secret of NoSQL is that sure, part of their target audience is legitimate needs, but another part of their target audience is just new developers who don't have much experience with either SQL or NoSQL databases, and are easily mislead into buying the idea that NoSQL will be easier Because There's No Schema or Joins To Think About

[bunderbunder]

I'm starting to tune out whenever I hear someone saying "schemaless". There's always schema. The question is whether schema's enforced at write time, or if instead it needs to be dealt with at read time.

Schema on write is a hassle up front because you've got to start imposing a strict data model up front, possibly before you've even got a good idea what your information domain looks like. And every misstep will be immediately punished with a painful migration.

Schema on read is, IMO, a hassle in the long run because now any code that's consuming the data needs to be prepared to have the information come in any of the ways that it has ever been stored in the history of the database. If folks were being disciplined, then hopefully that's a small number. If they weren't, you may end up with either some sort of combinatorial explosion, or a situation where you've seriously got to null-check every little thing. Every misstep will forever be punished with a million tiny little if-statements nagging at you like endless paper cuts.

I suppose it's easy to guess where my crass sentiments lie.

[galdosdi]

Yeah, as for me you're preaching to the choir :-) But that's fun so I'll do it some more too

You don't get to just stop worrying about schemas, joins, and transactions in your database. If your database won't do those things for you, now YOU have to.

* No schema just means (as you nicely describe) your app deals with schema changes, not the database. Have fun.

* No joins just mean your app deals with the complex choreography of keeping denormalized tables up to date. You think that's easy? Have fun deciding what updates to make synchronously or asynchronously, what to compute where and when, making sure you don't screw up and either hose performance or end up with stale data in a dependent table... enough of this and you'll be dying to come back to a proper relational database where you can just CREATE MATERIALIZED VIEW and call it a day

* No transactions just means.... oh, who am I kidding, you're not going to bother to write your app carefully to deal with those consistency semantics (and if you do, you'll probably do it wrong), you're just going to ignore them, call it a day, and hope your product doesn't get popular enough that the race conditions start pissing people off.

* No SQL means instead you're probably going to use some protocol that's much newer, much less popular, and locks your app and your mental knowledge into a single specific database product. Have fun rewriting your whole database layer and relearning the whole API and data model when you realize FooDB might be a better fit than BarDB. And it's way easier to go from SQL to non SQL if you end up having to than the other way around