The term "NoSQL" has always been misleading. The various "NoSQL" systems have very different underlying models, and defining them by their lack of SQL makes discussions about tend to develop an adversarial, "us vs. them" tone. It adds way too much noise.
I don't care about "NoSQL" - I like Postgres and SQLite. What makes the individual "NoSQL" databases interesting, though?
Redis is in a design sweet spot, IMHO. The pure key-value stores seem way too low-level to me, but the support for atomic operations on lists, sets, etc. in Redis is very handy. It also works well as a cache for other databases, and newer commands like BLPOP are very cool.
While I haven't used CouchDB much, its model is also interesting, and I can see its trade-offs being an excellent fit for certain problems (just not mine).
Some say NoSQL = "Not Only SQL", implying that there are alternatives to purely relational DB's. I think this definition fits better than the implied purely unrelational DB.
Agreed, but that's just damage control, after a whole bunch of "Death to relational databases!!!" hype. Of course there are alternatives to RDBMSs. What are filesystems if not hierarchial databases?
"NoSQL" is about as useful as rallying behind "languages without camel-case" (NoCC!).
I don't care about "NoSQL" - I like Postgres and SQLite. What makes the individual "NoSQL" databases interesting, though?
Redis is in a design sweet spot, IMHO. The pure key-value stores seem way too low-level to me, but the support for atomic operations on lists, sets, etc. in Redis is very handy. It also works well as a cache for other databases, and newer commands like BLPOP are very cool.
While I haven't used CouchDB much, its model is also interesting, and I can see its trade-offs being an excellent fit for certain problems (just not mine).