On 22nd Jan Yuri I and had a discussion about our use of CouchDb.

The discussion was prompted by his earlier email that day which ended with: "I'll check these bugs with 1.0rc8-snapshot tomorrow and add to orientDb issue tracker, but to be honest after this test I think OrientDB is far far away from reliable solution now. "

I was reluctant to move away from OrientDb since I valued the following:

• REST plus Java interfaces (for easy integration/exploitation)
• Exploit REST to miss out middle-layer
• SQL-Like filtering (for easy to understand querying)
• Schemas (to maintain data integrity)
• Community (Luca has been very responsive)

But, we have encountered a series of bugs/shortcomings in the code, and our team may not be resourced sufficiently to adopt a 'bleeding edge' library (this is the first encounter with NoSQL for both of us).

Yuri had encountered some rudimentary bugs (requirement for specific white-space in SQL query) that made him fearful of encountering similar problems across the rest of the application.

Yuri mentioned that he was personally aware of CouchDb success stories.

During the discussion Yuri pointed out that CouchDb had validation functions, I spotted a set of Java drivers, plus the O'Reilly CouchDb book - in itself a persuasive reason for switching.

I had a mistaken recollection that CouchDb didn't have good REST support. It's a REST database, stupid. So, we can interpret that as "tier one" REST support - thorough, mature, reliable.

So, we're going to switch to CouchDb. Yuri has invested around 20 hours of time in OrientDb tests. But, I don't see that time as lost: we were doing the tests to establish if OrientDb was suitable, and we've found it wasn't. So, we've been relatively fail-fast.