Yeah, I realise there are quite a few nosqls around. But only a few have just recently started to gain momentum. It is still very easy to find developers who have never heard of anything but traditional relational databases (not sure if I would dare to say the majority of all developers). In most cases relational databases is the best option for what they are doing, but I think there are many situations where people choose the old sql just because they don't know better. So, although there might be a point in comparing and competing between different NoSQL technologies, I think all within the NoSQL movement can gain from better marketing to all these relational database users.

Anyway, I think what you are saying is I need to be very good at describing why my technology is better than others, which as a developer I find very difficult. It is easy to be technical about it, but how to describe something at a level that makes sense to the average guy is something I am still trying to learn.

What my solution does very well is integration with object oriented languages and where the data is described by complex inheritance structures and ownership relations (say a financial model with different types of financial instruments, different types of market data, static data, deal data, etc which would be described by a number of class hierarchies; and all linked together).

With the risk of getting too technical, if you are building a C++ application for example, you only create your C++ classes (with any inheritance structure which can be single/multiple etc), and you can use pointers to other objects (polymorphic pointers and cyclic graphs are ok), use standard collection classes etc. Basically what you would normally do when designing a C++ application. You use a minimum amount of declarative code as C++ doesn't have built-in reflection. You send your C++ classes to the database and receive the data as your C++ classes. It traverses your objects to find all linkages to other objects prior to sending and links objects together upon retrieval. In short, the solution tries to make life as easy as possible for an application programmer.

What my solution does in terms of CAP and ACID:
Atomicity - A transaction is either committed in full or not at all. A transaction may consist of one or multiple objects.

Consistency - No consistency checks in the sense that there are defined constraints on the member fields. However, all objects are versioned, and if two clients are trying to commit the same version of an object, the second client will fail and it would have to retrieve the most recent version before updating the object.

Isolation - All transactions are processed in isolation, i.e. all objects in a transaction are locked prior to being updated

Durability - Transactions are never overwritten, i.e. new transactions are always added to the end of the data store. If a transaction has completed successfully, you can be certain that the transaction will be completed even after a server crash.

Availability - Concurrency is handled by locking objects. Many clients can read simultaneously, but if you try to read an object that is locked for writing by someone else, you will have to wait (there is room for improvement here). If you try to write to an object that someone else is writing to, you will fail. I have not looked into performance of a large number of clients, however the simple answer is that consistency is prioritised above availability.

Partition Tolerance - None at the moment. I have not looked into distributing the database yet.