Actually, they do. A lot of the people interested in and writing code for these new databases are the ones who have seen first-hand the failures of the traditional DBA view of the world. If you look at where a lot of these projects are coming from and who are sponsoring them you will see that they are some of the companies that are at the leading edge of internet scaling and deployment. The advantage they have which you seem to ignore is that they can look back at the wrong turns in the development of the current crop of RDBMS and avoid those particular dead-ends.

What it is Not

A relational database. A replacement for relational databases.

(http://couchdb.apache.org/docs/intro.html)

Obviously, CouchDB is a cool thing for the cool crowd, and doubtlessly many of the cool crowd are going to shoot themselves in the foot by using CouchDB when they should be using a lame boring RDBMS, which they can't bring themselves to do because that would be like wearing a polo shirt with their company's logo on it. That doesn't mean CouchDB is a bad idea. It's just a very sexy idea that will break a lot of hearts.

Arguing that DBAs 'require' the complex features in the other relational database is like saying that Macs 'require' more complex interfaces so IT people can work with them.

Backwards, and wrong.

I hate to break it to you, but for any complex data representation you will have to make abstractions to work with it efficiently and consistently.

Both of them are enterprise tools for working around stupid schemas and bad code.

There are more complex systems out there than your blog. It doesn't have to even be near enterprisey before having solid schemas and relations are indispensable for working reliable and efficiently with your data.

Arguing that DBAs 'require' the complex features in the other relational database is like saying that Macs 'require' more complex interfaces so IT people can work with them.

I've heard worse analogies and will let this one slide. However your argument, in its essence, basically boils down to "lets just ditch databases, all their optimization features and just use unrelational, standalone files as records". You promote simplicity over rigidness and predictability, which is required for any processing and optimization.

If you for a second believe this naivé approach to data-access is going to give you better results in any non-trivial case, I'll challenge you to prove it. As for any trivial case: Performance doesn't matter, you might as well use XML.

Amen! Some operations necessary on our site would be so slow as to make it unusable were it not for stored procedures and multiple indices per table. It would also be incredibly slow were it not for a well-configured PostgreSQL install. And all we do is aggregate ticket listings.

I've seen people fight with barebones MySQL installs over even more data than I deal with and it's simply depressing. Sometimes "stupid schemas and bad code" have nothing to do with it; you just need to process a lot of damn data. And for that, if using an RDMS, you need one that is mature, rock solid, and has a sufficient feature stack.

End PostgreSQL advertisement.

The idea that all databases need all features is a mistake, once one free open source project has everything and the kitchen sink it's time to start solving other problems.

I was using MySQL back in the 90s, and I remember their documentation. You didn't need transactions, they were slow - do it in your own code if you had to. You didn't need foreign keys, they were slow, enforce integrity in your code if you had to. You didn't need stored procs... You get the picture.

Baked deep into MySQL's culture is "if we don't have it, you don't need it" - even now. Feature-wise MySQL is probably 15 years behind Oracle - yet somehow its legions of fans are convinced it's on the cutting edge!

The sad thing is that these people use MySQL of all things as a reference point as what a relational database can do, and hence to them it seems all reasonable.

That part's not new. I worked in a Notes shop back in the 1990s, and the inevitable result of this was that every database was littered with documents created and updated by so many different versions of the apps that not even the developers really knew whether any fields could be relied on and which features would work for a given document without unpredictable failures.

Nothing stops people from creating retarded schemas for RDBMS's either.