[PommeDeTerre]

I think it's more just a matter of most people coming to the realization (after several years, for those who didn't realize it right away) that relational databases are what they want, and what they need.

There are very, very few situations where NoSQL databases are truly of any use. For practically all other cases, any time or effort savings promised when using a NoSQL database don't materialize in reality.

Take the claim that not having a schema is a benefit. This claim quickly falls apart when a huge amount of time and effort is needed to track data format/type/availability/constraints/etc. in an ad hoc fashion throughout all applications accessing the database. This is a huge amount of effort, and often duplicated code, in anything but the simplest scenarios. It's much more effective just to use a relational database and its support for defining a schema.

We see the same when it comes to querying using JavaScript. Maybe it works for simple queries, but those often aren't what we encounter in practice. SQL is by far the best we've got today when it comes to writing complex queries, and relational databases offer the best support for it.

Then there's ACIDity. "Eventual consistency" just doesn't cut it in the real world. Relational databases make it far easier, more practical and much safer to work with data in a transactional manner.

Many of the supposed strong points of NoSQL databases, like their sharding support, becomes irrelevant when using the replication support offered by so many relational databases.

It's not that NoSQL databases have been declared "bad", but instead it's just people realizing that the relational databases being used all along are really the best choice in all but a handful of cases.

[gordaco]

Sorry if this comes out as a little irrelevant, but I'm so glad there is someone else out there who thinks like you. I' ve already given up on proselitizing about the advantages of good ol' relational databases at my office. We DO have a schema (which has been consistent from the start, i.e., we haven't used our database in a flexible way), even if it's not explicit, and enforcing it actively in our code is just going to result in more errors than letting any mature relational database do it. And, yes, we've had a few of those errors (of varying severity) that wouldn't have happened with a relational database.

Non-relational databases are good when the data is really mutable enough that each row may have fields of its own, or lack them. Maybe I'm naive, but I don't see it as that common, and it certainly isn't our case.

[onlyup]

Thanks for the post. I was about to start a project with CouchDB but was unsure why I was going to use it. I know relational databases/SQL better so I think I will stick with that.

Do you think there is benefit in using stuff like SQLAlchemy or should I write just SQL files/queries?

[pyre]

  | Do you think there is benefit in using stuff like
  | SQLAlchemy or should I write just SQL files/queries?

If you're just in it for the learning, then maybe drop SQLAlchemy to get your hands dirty and learn; otherwise just use SQLAlchemy. If you're getting into really complex queries and optimizations you're going to have to resort to SQL anyways, even with SQLAlchemy. An ORM just allows you to abstract away most of the mundane SQL tasks.

[onlyup]

Thanks. I know SQL and use it in work. I am starting a personal project that I plan on taking a long time so I don't want to have to go back to the start to change stuff. For what it's worth I am using Python with Flask.