Our goal with these comparisons is to provide a framework for how to think about comparing data management solutions and also highlight how MarkLogic products fit into your existing architecture. There is no one perfect solution for all use cases and it’s important to think in terms of trade-offs and how your architecture will evolve over time.
To start, we picked some of the key comparisons that frequently come up when we talk to customers. As you read the comparisons, consider the following key question: “What’s your business goal?”. By starting there and not with a preconceived list of features to compare against, we think you will develop better requirements that are more oriented toward solving both your data problems and your business problems.
The below table provides a high-level overview of how MarkLogic Data Hub compares. Because it unifies many technologies into one data platform, our customers often compare it to the combination of other technologies that would be required to achieve similar functionality. And, it is not either/or — many customers use a data hub alongside other technologies. The central question as you consider your overall architecture is whether it is getting simpler or more complex?
| MarkLogic Data Hub | Data Warehouse + ETL | Managed Cloud Services | Data Lake + Open Source Components | |
|---|---|---|---|---|
| Data hub providing flexible data integration, management, and search for all enterprise data. Powered by MarkLogic Server. | Traditional Enterprise Data Warehouse (EDW) such as Oracle integrated with a traditional ETL tool like Informatica | Custom-built cloud data hub architecture using managed cloud service components from a large cloud provider.
For example, AWS provides DynamoDB (documents), NeptuneDB (graph), Elasticsearch Service (search), Amazon S3 (object storage), Glue (ETL), and Athena (query service) |
Data lake using Hadoop and various data model-specific databases, a search engine, and an ETL tool.
Many variations exist, but one example might include Cloudera with MongoDB (documents), Lucene (search), Neo4j (graph), and Talend (ETL) |
|
| Unified
Does it handle transactions and analytics? Is it multi-model? |
Yes Proven results |
Maybe Not for OLTP. Not truly multi-model. Non-relational data is a poor fit (slow, expensive) |
No Every component must be individually deployed, integrated, monitored, secured, and paid for |
No Patchwork architecture optimized for Data Scientists. Similar problems with needing to manage and integrate each tool separately |
| Agile
How long does it take to complete the project? |
Yes 10x faster at integrating data than alternatives |
Not Agile Long ETL timelines, everything must be modeled upfront |
Maybe Only quick for small projects. Exponentially more complex for large projects |
No Long implementation schedules, even for data science work |
| Enterprise Ready
Secure? Reliable? Proven? |
Yes Proven reliability and advanced security for mission-critical environments |
Yes |
Getting There Individual components are secure. Problems arise when they are integrated |
No Cannot be governed at scale |
The below table provides a summary of how MarkLogic Server—our multi-model database—compares directly with other popular database technologies according to their ability to power a data hub architecture.
| MarkLogic Server | Oracle | DynamoDB | MongoDB | |
|---|---|---|---|---|
| Multi-Model |
Yes Proven multi-model flexibility |
Maybe Supports industry standard non-relational types, but not adequately |
No AWS has a different DBMS per data model |
No Document only, stores documents as non-standard BSON |
| Security |
Yes Certified security controls and proven reputation |
Yes |
Maybe Limited granularity and lineage tracking. Pushes responsibility on developers |
Maybe Limited granularity and lineage tracking. Pushes responsibility on developers |
| Distributed Transactions |
Yes ACID transactions proven at scale. All ANSI levels supported |
Yes |
Maybe Simple ACID transactions, not proven |
No MongoDB 4.2.6 failed independent tests for ACID compliance, showing read skew, cyclic information flow, duplicate writes, and internal consistency violations |
| Scalability |
Yes Proven scalability and elasticity with superior performance to price ratio |
Maybe Scaling Oracle often requires forking data to new silo. Scale-out is expensive |
Yes |
Maybe Difficult but less expensive than relational, often requires downtime and refactoring |
| Cloud Neutral |
Yes Proven cloud neutrality |
Yes Though may require re-licensing |
No Only runs in AWS |
Yes |
See how MarkLogic simplifies complex data problems by delivering data agility.
Register Now
