It appears that JavaScriptDB just maintains indexes of everything, until you have over 2000 objects of a class and then it only updates the indexes of fields when you search on them. This saves you the trouble of initially specifying indexes, but by the time your DB gets big enough that they become important, you'll have to manage them explicitly anyway, and you don't get anything besides plain old lexical sort. Persevere looks great for rapidly developing small projects, but not particularly scalable. The automatic index thing might be handy for a multi-faceted search, which is a pain to do in CouchDB.
Are you claiming that you can't add a column on the fly to a table in a relational database? Because that my friend is complete gibberish.
That kind of usage works really well when the DB is a Entity-Attribute-Value tuplestore underneath. It's not so hot with tables, much less relational ones.
This gives you more power when your situation isn't ad-hoc attributes (by providing more guarantees) and lets you model the ad-hoc situation with a EAV model if you must. SQL maybe should provide some more sugar for accessing that EAV, but it's not a fundamental relational model issue.
What I meant was that different properties can be added to each object in the store without having to worry about the effect of the same properties on other objects in the same store. If you add "cellphone#" property to an object, it doesn't mean all objects in the store will now have a "cellphone#" property (defaulted to NULL). It means other objects will not even have a property "cellphone#" unless you go back to those objects and edit them.
This has nothing to do with the length of time it takes to add a column in whichever SQL database you use.
(Disclaimer: not a db guy.)
In Redis you can read or write ~100k operations a second. You can do set operations, add, rem, member, list .. way cool if you can stomach the memory use. Lazy sync to disk. Hard to think of anything that could beat it for collecting stats or totals etc for high volume data streams.
In CouchDB you can do M/R style indexed views, like word counts. You can access the DB directly from HTTP, no special drivers - the DB is implemented as a web server. You can authorise via OAuth (soon), secure via TLS and proxy through squid. You can access, and replicate, from the other side of the world.
Tokyo Cabinet is over 10 times faster than MySQL as a simple hashtable, like, say, a session store, which is the first place most sites start having trouble with their DB. Tiny, bare bones, drivers for all major languages, network accessible. A no-brainer for simple storage IMO.
And all of these are completely free, unlike the cripplingly expensive commercial alternatives you mentioned - especially important for startups.
So .. basically I completely disagree, there's a lot of good things about these alternative DBs. Don't discount them just because you heard a few dumb ill-informed comments on sites like this, most people involved in non-RDBMS DB implementations know exactly what they're doing.
CouchDB requires custom views for each field you want to optimally query. Persevere (using the JavaScriptDB) does that natively and smartly for all fields: http://www.sitepen.com/blog/2009/04/20/javascriptdb-persever... (see section: Adaptive On-Demand Concurrent Indexing)
The biggest benefit of NoSQL dbs is the ability to add properties (i.e. columns) on the fly. Querying these properties should not be an O(n) operation. Unless I am completely mistaken, it is in CouchDB unless you write a custom view. Persevere doesn't require that and supports most common methods of querying ( http://docs.persvr.org/documentation/jsonquery ) If you query a field, it will index it and if you query it often it will maintain the index and update it regularly.
I'm just starting on a project that uses Persevere and already I'm quite impressed by it. It may not be as famous as CouchDB/Cassandra yet but it offers a lot of very interesting features including transaction support and nested objects with referencing.