It seems to me that of all the advantages of NoSQL, schemalessness is probably the most minor and dubious. Most of the pain of dealing with SQL comes from the relational part, not from needing a schema.
The problem with SQL is that it's clever. To do things efficiently and reliably, you often must do very clever combinatorial operations on different tables, producing elaborate structures which are then winnowed down to a simple list of information. So right off the bat, you encourage programming logic that is difficult for future maintainers to wrap their heads around. Of course, most programmers aren't clever, so their queries end up being both difficult to understand and subtly wrong.
Then, of course, your data comes out as a list of rows. Well that's just great. If your needs involve a more complex data structure than that, well, you're going to need code to rebuild that outside the database.
Yes, and not even only this. The really big difference is the eventual consistency, used as a core concept in most horizontally scalable data stores. If you once design your application with heavy reliance on hard consistency, you will have a huge problem scaling it later on.
Very few applications need to scale past that point. I know plenty of business where if they would scale past the point of being able to run on a single SQL database instance they would make billions and be larger than their theoretical target market. Not everyone is building the next Facebook (which coincidentally uses MySQL for a lot of things).
It's not only about being able to serve lots of users. It's also about availability and geographical distribution. Even if you don't have millions of users, they will gladly benefit from you being split across several datacenters (serve everyone's requests from a location near to them).
It's quite easy to do this using traditional relational database technology, and various forms of replication. We've been doing it for many years, likely before many of today's NoSQLers were even born.
In the relational world, we don't really see such capabilities as anything special. They're merely one of the many basic features we've come to expect from any relational database system worth using.
Uhm, no. In MongoDB, you can decide for each query/operation how much consistency you need. You can fire and forget, you can wait for it to be journaled, wait for it to be flushed to disk, wait for it to be replicated to N number of slaves.
There aren't enough competent programers to automatize the entire world. Of course, if I was hiring for an IT company, I'd look for the best... But most of the world will have to content themselves with poor programers.
Anyway, poor programers work their best (less worst) in strong typed environments. That includes a very restricted schema on the database. It's much better having them write queries that nobody could read than having them insert data that nobody could read.
There's a difference between "clever" and "smart". Clever is rarely a good thing in programming. Code should be comprehensible, and clever code rarely is. The more proud you feel after writing a line of code, the more likely it is that you should rewrite it. The problem isn't that programmers aren't clever enough to write SQL queries. The problem is that programmers aren't smart enough to later read those SQL queries.
>I mean, they need to be able to deal with database logic just to graduate from a good CS bachelor's program, so that's a pretty low bar.
People manage to get through college without absorbing the basic requirements all the time, and being "able to deal" with database logic is not the same as being proficient with it. The problem with a system that demands cleverness is that maintaining clever code requires a high level of proficiency.
The problem with SQL is that it's clever. To do things efficiently and reliably, you often must do very clever combinatorial operations on different tables, producing elaborate structures which are then winnowed down to a simple list of information. So right off the bat, you encourage programming logic that is difficult for future maintainers to wrap their heads around. Of course, most programmers aren't clever, so their queries end up being both difficult to understand and subtly wrong.
Then, of course, your data comes out as a list of rows. Well that's just great. If your needs involve a more complex data structure than that, well, you're going to need code to rebuild that outside the database.