When faced with a very complicated software project, use what's been proved to work -> MarkLogic has been proven to work - its behind some of the largest and most complicated databases of information out there.

If you are equating NoSQL with unreliable, no transaction systems with no security then I can see your point. But as others have pointed out MarkLogic has ACID and scaling and flexibility as well as security and is pretty well proven out to be stable and scalable. So now it comes down to the data model -> complex ever changing data is a hard task for relational. You have to create the perfect model first and then transform all the data into that model. Several years later when that is done you can start again because the data has all changed. NoSQL brings schema flexibility and with that the whole process is changed -> you can load the data first, execute mappings and normalizations as needed and get up and running with reliable access much much faster. You still need a data model, you still need to understand the data, but the whole process takes much less time and, assuming you are using MarkLogic, is as reliable as any RDBMS system.

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. ]

Spike - its the data complexity that kills relational - you would have to design the perfect schema up front and then spend years transforming all the data feeds which by the time you are done would all have changed. Schema flexibility is a huge advantage for complex data of any kind. So the fact that MarkLogic works, scales, is ACID and has flexibility makes it a strong choice for complex data problems.

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!]

I certainly get where you're coming from with this, but a couple of points to address your concerns:

MarkLogic has been around since 2001, with features needed for enterprise deployments (ACID, HA/DR, security) baked in from the start; it's not just the new hawtness.

NoSQL systems aren't just for lots of data, they are for data with lots of variety. In those cases, a schemaless approach allows for much more rapid application development. And yes, many of those scenarios do require reliable storage. MarkLogic does ACID transactions. The MarkLogic customer page shows some of the customers who have found this helpful.

Regarding interoperability, MarkLogic has a REST API and a Java API, in addition to the ability to work with XQuery. Custom HTTP service endpoints can be built to fit into an existing environment. It still requires some learning -- a document store is different from relational, so that's unavoidable -- but with a little training developers can use a lot of their current skills.

SQL doesn't work well for complex DATA from multiple ever changing sources. You have to create the entire perfect model before you can even load data and by then, with any complex problem, the data has changed and you are in a refactoring death spiral.

there isn't any reason a NoSQL database can't be ACID and scale AND support a complex data problem. The problem is that most of the current systems were built for web scale (cough cough) and when you try to use them for a real project you have to make up all kinds of silly reasons to work around the lack of ACID.

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/

Yup and ML indexes that tree and largely uses search engine like indexes to resolve queries. What this gives you is schema flexibility and that is key for bringing together many complicated data sources. With a relational approach you would have to define the entire master schema up front.

Except of course that you CAN have actual transactions and simple scale out in NoSQL - just most of the NoSQL databases out there weren't designed to manage that. The database in question here, MarkLogic, has fully ACID transactions and horizontal scale out without any penalty to ingestion speed or query. Its all about the core design being right from the start and MarkLogic's architecture isn't complicated its MVCC with write forward over a shared nothing cluster.

MarkLogic has scheduled backups. You can also do a backup through the Admin UI, which is mentioned pretty early in the Administrator's Guide.

That's only a valid argument if the choice was in fact one of the NoSQL databases that has reliability and security (you forgot about that - its equally appalling in most NoSQL). But there is such as thing as enterprise NoSQL with real transactions and security and MarkLogic has been replacing Oracle for mission critical systems for over 10 years. The new generation of database with schema flexibility along WITH reliability is a killer combination for hard data aggregation problems.

It's actually really fast. The XML is indexed on ingest and many queries are answered just from the indexes.

Because for many kinds of data, once I became familiar with MarkLogic I found I could build complex applications more rapidly than I could with relational technologies. It scales out, it's schema agnostic, and it's ACID compliant. It has HA/DR features and a robust security model. Customers buy it because it solves their problems. For anyone interested in learning a bit about MarkLogic, the Enterprise NoSQL page is a good place to start. Disclaimer: MarkLogic employee.

MarkLogic is ACID compliant. http://www.marklogic.com/blog/can-you-pass-the-acid-test/