NoSQL, meh
At this point I just can't quite get as excited about NoSQL as some people.
I'm not against it, I think it's pretty cool, it's just that with the ZODB I've been there and done it once before for about 8 years and I don't want to go there again in a hurry.
The Zope expert
In the past I used to come in as the Zope or Plone expert. That's what writing a damn book does for you. If a problem or a change needs happens in a Zope or Plone site chances are you have to alter some data and interact with the ZODB. But one thing you cannot easily do, is have a quick look at the records in the database.
The ZODB is a very sophisticated Python pickler. To get an object out of the ZODB you have to have the class of the object that went in so that you know how to unpickle it and get the object back. Something I remember Paul Everitt indicated as a problem to me many years ago and it took me a while to clue in.
So whenever a problem came up in the data, it was up to me to fix. It was considered too hard for other people to fix. It might "just be" a matter of writing a Python script that ran through some records and altered a string, but that was pushed to me.
Along came Rails
Then along came a Rails project. This is before we discovered Django and found out what Rails was really like. But for me there was a moment of pure joy one morning when an absolutely awesome colleague I worked with at the time said to me something like: "There's a problem with this invoice, I traced it down to this table in the database which has errors in these columns. I've written a SQL statement to correct, or should it be done at the model level?". Not only had he found and analyzed the problem, he was offering to fix it.
Praise the gods. To do similar in Plone, he would have had to learn Python, read up on all the classes. Write a script to get those objects from the ZODB and examine them. Not a small undertaking by any means.
What was going on
The tools for the ZODB just weren't there and it wasn't transparent enough. If there was a good object browser for the ZODB (and yes a few simple projects showed up that tried to do that) that did all the work and exposed things that would really help. But setting up and configuring such a tool is hard and I never saw one that allowed you to do large scale changes.
Perhaps if the ZODB was just a big JSON structure that you could easily build a browsing tool and hook up easily it would have been more transparent. Or at least if was presented that way... but for many its a black box.
Let's face it, everyone knows SQL. If you've got a complicated issue that occasionally pops up on some site - I can completely understand not wanting to spend a lot of time learning the relatively complicated answer on how to fix. Or to put it another way:
Of course I'm guilty of being a bit self interested here. I'm happy to do fixes, but if I'm the first line for every problem in a Plone site then the resource allocation is out of whack. And you are screwed when I get hit by the bus.
The future
I'm using App Engine and hence Big Table quite a lot these days and enjoying it. I think that's great. I've played with CouchDB and I'm impressed so far. There's lots of cool stuff there, but I'm still enjoying Django with a boring old fashioned RDBMs backend and recommending that (along with App Engine) to clients. If a client asks for something like Couch/Cassandra/Mongo we'll happily implement it.
But in the back of my mind is that worry, I've been down the NoSQL route before. And the result was a lesson learned. I'm going to be cautious this time around.