MarkLogic Server Reviews

The licence cost is HIGH.

The amount of space required to store the data seems high hence costly.

The compatibility with legacy system is not yet available. I feel this area needs to be improved very fast.

How to do complete data profiling on documents loaded in Marklogic database?

Customers need a tools which can be customized to suit their data profiling needs but currently the tools which MarkLogic provides fall short on this requirement.

Unit testing framework which is using only XQuery as the language is lacking some features.

The management and set up is "too" advanced. It is easy to get started but comes configured wrong out of the box for large stores.

The deployment framework is non-existent. We had to maintain our own framework through Puppet and other means to get it deployed ad-hoc. It's meant to be deployed once, but does not work well with the temporary environment mantra that DevOps aims to achieve.

There is absolutely no way to run tests or automate the testing of REST. We had to roll our own.

The community is lacking for open source. If we needed something we had to write it.

MarkLogic still has a long way to go in fostering the developer community. Many developers are gravitating to the simple integrations and do not delve into the deeper capabilities. They have made tremendous strides in recent months and I am sure this will improve over time.

Many of the best features are left on the floor by enterprises who end up implementing MarkLogic as a data store. MarkLogic needs to help customers find ways to better leverage their investment and be more creative in how they use the product.

Licensing costs become a major hurdle for adoption. The pricing model has improved for basic implementations, but the costs seem very prohibitive for some verticals and for some of the most advanced features.

MarkLogic is not cheap, either for the software itself, the hardware to run it on, or the investment in learning necessary to use it effectively. While MarkLogic has gone to great pains to add multiple interfaces so that a deep understanding of XQuery is theoretically not necessary, I feel XQuery is essential to understanding the product well enough to use it in production applications.

Specifically, it is my understanding that switching database contexts is expensive in terms of performance. There could be be a improvement in the ability to query across databases, or even across clusters, that could drive greater flexibility in design decisions.

The security model definitely could be improved to facilitate sharing users, roles, and permissions across clusters. Building your own security model to allow users access to data on different clusters is very complex and leads to a number of performance issues.

There is a steep learning curve to learn to use this tool, particularly the xquery and extensive associated API. The more recent releases and features have been responsive to this concern, but some of the core features still take some learning.

The javascript implementation is new and there are still some spots where it needs to be made fully compliant with standards and conventions, such as file extensions

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.