If you like XML, and you need an enterprise-grade database platform, MarkLogic towers above all others.
October 19, 2015

If you like XML, and you need an enterprise-grade database platform, MarkLogic towers above all others.

Richard Winslow | TrustRadius Reviewer
Score 9 out of 10
Vetted Review
Verified User

Software Version

7

Overall Satisfaction with MarkLogic

The technology department at Zynx Health uses MarkLogic as the primary database layer supporting an innovative analytics product for clinical decision support. We had concluded that we wanted an XML-based solution for hierarchically structured and semi-structured data, in part because of the ubiquity of XML-based formats in the healthcare space, but we also wanted enterprise-grade integrity and scaling features, so we decided on MarkLogic.
  • MarkLogic's implementation of the XQuery language is fast and versatile, and the additional language features and numerous libraries that they provide out-of-the-box really make it feel like a "batteries included" language, at least within the context of XML and JSON database management.
  • Despite its enterprise focus, MarkLogic is a very developer-friendly product. All of its administrative features, including provisioning servers, are available through APIs. Most of the functionality one uses from XQuery come in the form of source-included XQuery libraries. I am strongly inclined, generally, to favor open-source solutions, so the focus on freedom and capability for the developer was important to me in this proprietary platform.
  • MarkLogic is fast. It's much faster than the other XML-based database engines we looked at, and is certainly faster than XML layers bolted on top of relational database engines. The lockless write strategy is great architecture, and it enables the engine to smoothly scale up simultaneous reads and writes. MarkLogic's speed enabled us to perform significant updates on database structure and content as part of our continuous deployment strategy with minimal impact on stability and availability.
  • XQuery is a tough language for engineering teams to adopt; it's the world's weirdest pure functional programming language. Once you've crossed over and can see The Matrix, it's clear that the language design is aligned perfectly with the XML querying problem domain, and the fact that it's a Turing-complete programming language rather than just a query domain-specific language (like SQL) enables you to go wherever you need to go with it, which is empowering. But there are areas of obscurity and seeming inconsistency between MarkLogic's lockless write strategy, transaction management and XQuery semantics that all of our developers, at one time or another, ran into, and we only mastered these features after many months with the product and with the help of an expert consultant. It turns out that much of what we learned appears in the copious documentation, but the documentation is SO copious (and, in the area of transaction management, so dense) that none of us had the time to read all of it. This is an area of the product that the documentation should elevate and present, front and center, in a way that is more prescriptive, rather than just descriptive. Give examples showing how developers should solve real problems, and illustrate what the engine is doing.
  • MarkLogic's pricing, like its feature set, is enterprise-scale. One understands; they're like the Oracle of NoSQL. But the storage restriction on their "free" version basically means that the only way in is full retail, so there are wide categories of companies that would never consider adopting. I wonder if any kind of tiered model might be sustainable for them.
  • MarkLogic support was quite reasonable in their response time and their general knowledge of the product, but there were certain insights to problems that we really only gained by working with a very knowledgeable consultant that the company recommended for us.
  • MarkLogic reduced the amount of time that the DevOps team needed to dedicate to database updates, as the engineering team was mostly able to easily design and maintain database upgrades without requiring specialists such as database architects on the DevOps side. This capability flowed from the product's speed and the versatility of its XQuery language and libraries.
  • MarkLogic required significant education and buy-in time for the engineering team.
Once you've bought in and built an infrastructure and an application architecture around MarkLogic's feature set, there's really no alternative product that could replace it. Not without a big reengineering project, going well beyond the data themselves. Beyond this, of course, we were very happy with our investment in MarkLogic when last I was associated with the project, and we had every reason to continue.
If you're looking at MarkLogic because you need an enterprise-grade XML-based database (not just any document store, but specifically XML-based), then the choice is easy. If your needs are more general, and you're looking at MarkLogic as an "enterprise NoSQL" solution, then you should look carefully at the feature set, your current and anticipated needs, and what your options are for achieving "enterprise" goals with other solutions (and engineering investments of your own, including DevOps work).

If MarkLogic still looks good after such analysis, consider whether your team is ready for the investment. Is the team small enough and/or eager enough to buy in, intellectually, to an "exotic" platform like MarkLogic? Can they leave behind the relational mindset and take the time to deeply understand and become productive with XML and the XML ecosystem (e.g., XQuery, XSLT)?