NoSQL pioneer: MarkLogic's battle for respect
This has been an eventful year for Marklogic, having unveiled a major release and securing a new shot of equity investment from a key global systems integration partner. The company has raised over $173 million in seven rounds, but that's over a stretch of 15+ years. In a market that segments databases by technology, Marklogic has always been the odd man out. It calls itself a NoSQL database, but details aside, it tends to compete more with Oracle rather than MongoDB.
That's attributable to several factors. First, MarkLogic has always positioned itself as an enterprise database. But as the term "enterprise" gets thrown around by virtually every major NoSQL player, it's easy to get lost in the shuffle.
MarkLogic was designed for ACID transaction support. It also promotes its scalability; high availability; and stringent levels of security (it meets Common Criteria certification, which is essential for the defense/intelligence communities). But so do others, although to different degrees. For instance, each of MarkLogic's NoSQL rivals tout their ability to scale out, so that's not a differentiator. But ACID is; for instance, MongoDB's ACID support is at document or collection level, not the item level that MarkLogic drills down to. Cassandra, on which DataStax Enterprise is based, was not designed for ACID period, while Couchbase employs a roundabout approach.
MarkLogic's biggest challenge is that of early mover. It began life well before the term NoSQL was invented. Its roots are as an XML database geared for a very different use case than for what NoSQL databases grew famous. As XML database, MarkLogic had plenty of company, but its niche was digital publishing. Emerging around the time that Google revolutionized search, MarkLogic applied a database approach to search that made it indispensable to digital publishers. That in turn placed MarkLogic on Oracle's radar.
Then a few funny things happened. The world moved beyond XML as the language was bulky, resource-intensive, and complex to use. More importantly, a grassroots movement among developers emerged, clamoring for the same freedom from rigid schema that non-relational databases like MarkLogic promised. But these new NoSQL platforms were targeted at use cases like online session management or user profile maintenance that didn't require gold-plated reliability, but did requirement absolute speed and ease of use. They grew popular exploiting the well-known JSON document model. The groundswell that gave rise to MongoDB and Cassandra was very much like the LAMP stack movement that birthed MySQL about a decade earlier, except this time, there was no need for relational schema.
Getting beyond its XML roots, MarkLogic embraced the NoSQL label (and stopped requiring XML for schema), but remained too heavyweight (and expensive) to appeal to this growing base of adopters that demanded simpler open source databases. Not surprisingly, MongoDB, which is about half MarkLogic's age, has raised roughly 40% more capital. The problem of course is that if you call yourself a NoSQL database, you're going to get compared to other NoSQL platforms regardless of which markets you or they actually address.
But if there was a watershed event that showed the world that MarkLogic was a different kind of database, it was the Healthcare.gov debacle. MarkLogic was chosen based on its ACID support for complex data types. While some accounts blamed the unorthodox choice of a NoSQL database, in actuality it was a failure of program management. For better or worse, the episode drew the spotlight that MarkLogic was indeed a platform suited for handling transactions involving complex data types that wouldn't easily fit into Oracle. And it has since drawn a broader array of use cases beyond its digital publishing foothold.
The new MarkLogic 9 release is a mixed bag comprising some features such as entity-level security and redaction that have been commonplace among the Oracles, Db2s, or SQL Servers of the world for years. On the other hand, bi-temporal support that provides before and after views of an entity or event is fairly unique. Then there is a new entity services feature that layers a business glossary atop an existing graph engine-based semantics capability. It provides tools to enable business analysts to craft applications that manipulate data that can be labeled with logical terms such as "customer" or "order." In so doing, MarkLogic rides the wave with other data platforms that are using graph engines, but what's notable is that each is using graph differently.
In an era with increased scrutiny on data security and personal confidentiality, data governance ultimately plays to MarkLogic's strength with its ability to address data at the entity level. With big data, MarkLogic won't be alone in having such granularity, but it is well positioned if it either develops its own capabilities for data stewardship or partners for it.
For now, MarkLogic claims that its customers are not clamoring for a cloud strategy. But even Amazon has built a secure cloud for federal agencies. So we don't expect that security is going to provide the justification for MarkLogic customers or prospects to buck the trend for demand of managed cloud database services that would otherwise free them from managing operations to focus on their applications.
RELATED AND PREVIOUS COVERAGE
MapR diversifies to cloud storage market
MapR has rebranded its file system to target the cloud storage business. It's part of an ongoing strategy to transcend its Hadoop heritage.
Has the Hadoop market turned a corner?
The recent numbers from Cloudera and Hortonworks show positive signs toward the path to profitability. But as they aim for the black, they are finding themselves in a much broader Big Data market where ease and accessibility will determine whether they sink or swim.