Alex Popescu pickes up my post to the NoSQL mailing list and seems to agree:

An interesting post on the NOSQL Group about what takes a storage to be considered NoSQL:

1. SQL-the-language vs. alternate query languages
2. A tabular model for data as opposed to one that is not (e.g. key-value, object, graph, …)
3. ACID vs. non-ACID
4. Centralized vs. distributed/decentralized

In case we agree with the author, Johannes Ernst, then we might be tempted to conclude as he does:

It’s interesting to observe that any “NoSQL” product could be “NoSQL” in any number of these dimensions. […]

Which would also explain why so many “NoSQL” products are so dissimilar to each other.

So, what makes it NoSQL?

Applying this to InfoGrid:

• InfoGrid does not use SQL-the-language. Otherwise, how could we do things such as blessing the same object with multiple types at run-time? (Example)
• InfoGrid uses a graph database model, not a tabular model, for the same reason Tim Berners-Lee decided that the entire world-wide-web could not fit into a relational database either.
• InfoGrid relaxes ACID. No truly distributed system that I know of has ever had ACID properties, nor wanted them. Too many things can go wrong.
• InfoGrid uses the “small pieces loosely joined” paradigm, not a top-down paradigm.

So if there are degrees of NoSQL-ness, InfoGrid scores high. (all while being able to run on top of a SQL database, if you wish — and no, that’s not a contradiction)