Typically the hate comes from people being unprepared and not researching their database options enough before making choices. IMO the fact that it's so easy to get up and running with Mongo actually works against it because it seems like the database "just works" until you start needing something from it.
Ex[1]: Foursquare took their Mongo instances to bare metal recently, keeping everything else on EC2. Most people starting with Mongo aren't thinking "at some point I'll migrate my database servers to our new datacenter to run on bare metal".
That said, the recent MongoSV didn't instill much confidence in the platform. You could overhear the frustration of 10Gen's event sponsors all day. Personally, I'm trying to move to distributed, masterless systems so Riak fits in very nicely. Yokozuna is also promising as a riak-solr type deal[2] and Riak Core can be used as a framework for creating distributed systems.
[1] http://www.10gen.com/presentations/mongodb-foursquare-cloud-...
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.
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.
Do you think there is benefit in using stuff like SQLAlchemy or should I write just SQL files/queries?
| 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.