On the 'eventually consistent' point, just wanted to point out that MarkLogic does NOT use the 'eventually consistent' model. Instead MarkLogic uses MVCC and is fully serializable when it comes to transactions. In addition, MarkLogic's indexes are updated within the transaction boundary, so as soon as the transaction commits, you know the journal has been updated and the indexes are updated too.

Combine this with MarkLogic's ability to save any arbitrarily complex search as an alert, and you can power many interesting mission critical information sharing applications.

I have a blog entry that describes this: http://adamfowlerml.wordpress.com/2013/11/25/marklogic-huh-what-is-it-good-for/

Also around Serializability: http://adamfowlerml.wordpress.com/2013/01/25/true-acid-compliance/

[Yes, I work for MarkLogic! I work here because it's an awesome piece of tech. ]

FoundationDB actually did a pretty good job of separating out the truth from the hype recently in their post about NoSQL and ACID Compliance: https://foundationdb.com/acid-claims#!

Doesn't mention neo4j specifically - don't think the article authors considered graph/triple stores in their article - but it's a good read nonetheless. The article mentions MarkLogic too. Added my comments on it here: http://adamfowlerml.wordpress.com/2013/11/17/foundationdb-joins-acid-transaction-crusade/

FWIW MarkLogic 7 also is a triple store (not graph store), including support for the W3C Graph Store protocol and SPARQL. http://www.marklogic.com/what-is-marklogic/marklogic-semantics/

[Yes, I do work for MarkLogic - and proudly so!]

As many have said, XML is here there any everywhere and so we need strategies to manage it. Some people use it purely as a data interchange format, which is fine. Others want to manage documents using an XML representation, which is fine too.

MarkLogic takes an XML document and stores a highly compressed binary tree representation of it. It doesn't store 'raw text', or even strings. This makes it storage efficient. MarkLogic also indexes the entire document's structure, values, words and phrases (and stems thereof) for search. The database and the search engine use the same indexes, rather than a set of indexes each.

Special range indexes can be created too. E.g. a geospatial co-ordinate pair appearing anywhere in the document. As the point's XML element could conceivably be anywhere in the document, creating a traditional schema for this is nigh on impossible. Storing the document itself, with indexes along side it, is actually quite an elegant solution.

I would agree with your statement if it were 'XML soo sucks for traditional relational db applications', because those RDBMS systems require shredding/rebuilding of the documents, or store the XML as 'dumb' column types. Thus you lose the flexibility of the XML. MarkLogic takes advantage of the fact the data is XML anyway.

Why not use a document database with built in support for XML to store data that is XML? Seems pretty straight forward to me.

More details here: http://adamfowlerml.wordpress.com/2013/11/25/marklogic-huh-what-is-it-good-for/