MarkLogic Multi-Model Database: Enterprise Edition v. 11

MarkLogic serves as our enterprise-level database with multiple applications. We have numerous source systems that dump data into MarkLogic. DHF flows manage transformation, harmonization, mapping, and curation of this data, creating final records in MarkLogic. We have built REST APIs that consume data from MarkLogic and also accept data from external sources, allowing for both data modification and retrieval. We also have TDEs built in, which enable us to present existing data in MarkLogic in SQL tabular format for use by other systems like Qlik and Power BI.

Our team handles both data ingestion and API development while another team manages the UI and other tools. From our customer's perspective, MarkLogic is deployed at a manufacturing and processing plant facility. Data from different sources is ingested and stored in MarkLogic through DHF. Multiple customers interact with this data through the UI, and they can make changes or add new data by interacting through APIs.

MarkLogic's built-in search capability is its best feature. We can utilize both CTS search and standard search functions, both of which drive faster query results. MarkLogic also includes indexes that further enhance performance by allowing us to know exactly where to search the data.

The data indexes and search capability have a significant positive impact on our work. When we perform transformations, search for data, or retrieve data, the search capability is a primary feature that enables us to efficiently locate whatever data we need. Even with ten million data records in MarkLogic, using the search capability alongside indexes makes it easy to retrieve data from even billions of records. This capability saves us considerable time when searching for and retrieving data.

I have been using MarkLogic for approximately five years.

Customer support is excellent. They are available twenty-four hours a day, seven days a week, and provide quick responses when we raise queries.

We did not use a different solution before MarkLogic.

We do not have any relationships with this vendor beyond being a customer.

Compared to our previous approach, we are saving approximately two days per week. This represents a forty percent reduction in time spent discussing or trying to understand data. MarkLogic has delivered significant time savings.

MarkLogic's governance of data is excellent, and its security features are strong. However, there is very limited documentation about MarkLogic's AI capabilities. I would recommend that anyone considering purchasing MarkLogic should utilize the free format available to test it on their local machine before making a purchase decision. This review rates MarkLogic a nine out of ten.

My main use case for MarkLogic is that we have MarkLogic as an enterprise-level database. We have many source systems that dump data into MarkLogic. Then we have DHF flows, which handle transformation, harmonization, mapping, and curation of this data and create a final record in MarkLogic. We also have REST APIs built in, so these REST APIs can consume the data that is in MarkLogic and can also send data from outside to MarkLogic. This can change the data that is already present in MarkLogic, and users can retrieve the data in MarkLogic. We also have TDEs built in. We have data that is already in MarkLogic, and the NoSQL data can be presented in the form of SQL in a tabular format using TDE, and this can be used by other systems such as Qlik and Power BI.

MarkLogic fits into my daily workflow as we frequently deal with both data ingestion and the API. There is another team that takes care of UI and other tools. In my daily workflow, from a customer perspective, MarkLogic is used in a client who is a manufacturer and processing plant. Things are deployed on MarkLogic, and this data is stored in MarkLogic. Using DHF, the data is stored in MarkLogic from different sources. We get the data and store it in MarkLogic. Then from the UI, many customers can interact with the data that is present, and if they want to make a change or add new things into the data, they can interact using APIs.

The best feature of MarkLogic is the built-in search capability. There are two search capabilities available: CTS search and search:search. Both search capabilities drive faster query results in MarkLogic, and it is really fast. We also have indexes present in MarkLogic where we can make the performance of the query faster. Indexes allow us to know exactly where to search for the data.

The data indexes and search capability impact my work in a very positive way. When we do any transformation, when we search any data, and when we retrieve the data, the search capability is a main thing in MarkLogic that enables us to find what we need. Even if we have 10 million data entries in our MarkLogic, when we search using the search capability and utilize the indexes to make the search faster, it is really easy to get the data we need from even billions of data. This is really saving us time when we want to search and retrieve the data.

MarkLogic has impacted my organization positively because we have seen efficient results. Instead of keeping the data in a lot of databases and MDM databases with every source system trying to keep their data in some place and then fetch it and give results, now that we have started using MarkLogic, everybody wants to fetch the data from MarkLogic because this is the main place where the data is stored, it is easy for retrieval, and it is fast. The end-to-end applications in MarkLogic architecture are really fast when it comes to performance because MarkLogic gives responses in very quick real time. We have seen improved efficiency, and a lot of time is saved because we do not have to check with a lot of teams to get an understanding of the data. We can just check with MarkLogic and its relative data in MarkLogic itself.

MarkLogic can be improved by introducing a lot of languages to querying. Although I think it is self-sufficient if you know JavaScript and XQuery, for new people who want to onboard into MarkLogic, if Python, C, and these kinds of languages can be integrated and used on MarkLogic, then it will be a good product for everybody.

I have been using MarkLogic for about five years.

MarkLogic is stable.

MarkLogic is very good in terms of scalability. We can scale it horizontally as well as vertically.

The support resources and documentation for MarkLogic available on the website are really good, and I am satisfied. On a scale of 1 to 10, I will recommend 10 for the support.

We did not use any other solution before.

The setup process of MarkLogic is pretty straightforward. We have to install it and there are very few configurations to be made, and it is really easy if you have admin experience.

We have seen a return on investment with MarkLogic. We have saved 20% to 40% of time in data retrieval. Also, the discussions have been reduced when it comes to finding out how the data behaves because the data is stored in one place now.

As far as I know, I am not directly associated with pricing, setup cost, and licensing, but MarkLogic is a bit more expensive than other technologies available. However, the support is really good, and the product is really good.

We did not evaluate another options.

In comparison, for about one week, we are almost saving two days now. So two of five means we are saving 40% of time compared to discussing or trying to understand the data. So 40% of time is reduced.

The learning curve for new users or developers on MarkLogic is a bit tough at first, but afterwards it is really easy to understand for developers new to MarkLogic.

MarkLogic is very flexible when it comes to integrating with other tools or systems because they have a lot of authentication systems and connection systems available. We also have a lot of app servers with HTTP auth, OAuth 2.0, and basic digest authentication. MarkLogic is really flexible when it comes to integrating with other tools or systems.

MarkLogic is very good at handling larger data sets. As we already have billions of data, it is really handling it well. We just need to take care of the CPU, RAM, and storage.

MarkLogic handles heavy loads at peak times and performs well. It automatically manages itself with the configurations we can have, parallel processing, and load balancers in place. This takes care of the performance during heavy loads at peak times.

MarkLogic is also available in a free format, so you can deploy MarkLogic into your own systems and try it out to see how it works, how fast it is, and how it can solve your own data problems. It would be beneficial if you give it a try before purchasing.

Regarding MarkLogic's governance and security, I think data governance is really good. We can keep the data private to some roles, and we have user-based access control. We can give restrictions on the data and govern the data. Security-wise, MarkLogic is really good because without proper credentials, MarkLogic does not have any ways of getting hacked.

I would rate this review a 9 out of 10.

I used MarkLogic for a total of two years.

When it comes to main use cases, I used MarkLogic as a backend service for handling complex structured data such as XML or JSON. I have REST API services and modules using XQuery where the system needed efficient storage, query, and transforms of large volumes of data. Additionally, I worked with real-time ingestion pipelines where data from multiple sources were processed and stored in MarkLogic, enabling real-time access and updates.

MarkLogic is designed for multi-handle multi-model data, which means it can natively store and query XML documents, JSON documents, and unstructured and semi-structured data. Instead of normal database joins, MarkLogic works by querying inside a document efficiently using indexes. In one of my projects, we used MarkLogic to manage a large-scale document processing system, where we ingested data from multiple upstream systems in XML and JSON format, such as product or property-related data. As soon as the data was ingested, it became immediately searchable due to MarkLogic indexing. MarkLogic handles semi-structured data by storing it as a document, automatically indexing it, and allowing real-time query and updates using XQuery and strong consistency.

My experience with MarkLogic demonstrates how we leveraged its features beyond just data storage. For example, I worked on optimizing queries written in multiple modules, mostly related to searching with text and applying structured filters, which significantly improved query accuracy and performance. Apart from basic features, I have worked on performance tuning, indexing strategies, and combining full-text search with structured query. I also used MarkLogic as both a database and search engine, which helped to simplify our architecture.

In our use cases, MarkLogic's universal indexing and clustering have a direct impact on performance and scalability, and it has helped us significantly. In normal databases, we need to define indexes up front, and if a new query comes in, we often need a schema or indexes. In MarkLogic, all data such as XML and JSON were automatically indexed, and we did not need to pre-plan any query patterns. In real time, we had a dynamic search requirement with filters, pricing, location, and keywords, and instead of creating multiple indexes manually, we leveraged our universal index plus range index. For example, when a user searches with multiple filters plus keywords, queries are still fast because MarkLogic uses its internal index instead of scanning documents. Regarding clustering, we have our MarkLogic clustered environment. When multiple nodes work together, horizontal scaling is part of it, as we could add more nodes if data grew, ensuring high availability. For instance, if one node failed, another would handle that traffic. During high traffic, the system stayed stable, and we handled the large data volume without performance degradation. Universal indexing helps us avoid manual indexing management while still providing fast queries for dynamic searches, and clustering allows us to scale horizontally and handle high traffic with no latency and high availability.

MarkLogic offers several powerful features. First, there is universal indexing, in which it automatically indexes all the stored XML and JSON documents. Second, it can handle both XML and JSON unstructured data in a single database, which makes it flexible for complex and evolving data requirements. The third is the ACID property. Unlike many NoSQL databases, it provides strong consistency with ACID transactions, which is critical for real-time and reliable applications. It also supports horizontal scaling and clustering, which helps in handling large volumes of data and high traffic efficiently.

One feature that stood out to me in our project is its ability to combine search and database capability on a single platform. The tight integration of full-text search with structured query makes it very powerful for building real-time search applications without relying on any external tools. It simplifies our architecture and reduces system complexity. I also appreciate its flexibility with data models, especially handling both XML and JSON seamlessly, which can be very useful in our use cases with multiple data resources.

Using MarkLogic has had a significant positive impact on our organization, especially in terms of performance, flexibility, and reliability. With MarkLogic's universal indexing and built-in search, we have seen query response times improve noticeably. Complex searches dropped from a few seconds to sub-second response times in many cases. Users could perform combined keyword plus filter searches in real time, directly improving our application experience. Before implementing MarkLogic, we were using a relational database and NoSQL as separate search engines, requiring Elasticsearch and others. With MarkLogic providing a single platform for both storage and search, we reduced integration overhead, maintenance efforts, and failure points. The schema flexibility for XML and JSON allowed us to onboard new data sources faster. The ACID transactions that MarkLogic provides are crucial and something rarely supported by NoSQL databases. MarkLogic improved our system by enabling faster search, reducing the response time from seconds to sub-seconds, reducing architectural complexity by combining database and search, and improving reliability through ACID transactions and clustering.

While MarkLogic is powerful, there are areas where I feel it could improve. When I started with MarkLogic, I found that its learning curve and developer experience are not very comfortable for beginners. Technologies such as XQuery are less common compared to Java and Python, so new developers take time to get comfortable with it. Improving documentation and modern tooling would greatly aid onboarding. Second, the cost and licensing can be a concern for smaller teams and startups. MarkLogic's enterprise status makes it less likely to be the first choice for those teams. While it supports deployment in the cloud, the experience could be more seamless compared to fully cloud-native databases. Overall, MarkLogic is excellent for enterprise use cases, especially where search and structured data need to work together, but improving developer experience and ecosystem support would enhance its efficiency.

A couple of additional areas where MarkLogic could improve are around integration, performance tuning, visibility, and support experiences. While MarkLogic supports REST APIs well, integrating with the modern data ecosystem sometimes requires extra effort compared to other platforms, as out-of-the-box connectors are limited. Although performance is strong, understanding query behavior can be challenging, and debugging slow queries or analyzing indexing usage is not always transparent. Regarding support and documentation, response times can vary depending on the issue or server availability. More real-world examples and troubleshooting guides would enhance developer productivity. Improvements in integration and modern tools in XQuery, along with better observability, are necessary.

Beyond what I mentioned earlier, there are a few additional areas I can point to. While MarkLogic supports powerful querying via XQuery and JavaScript, many developers are more comfortable with SQL. An intuitive SQL-like query support or a better abstraction layer would enhance adoption across teams. Furthermore, migrating from other databases, whether relational or non-SQL, requires effort in data transformation. Better migration tooling with automated data mapping would also make transitions smoother.

In my current field, I have been working for the last three years.

MarkLogic is pretty stable in my experience. It is highly stable and reliable.

MarkLogic offers excellent scalability, especially for enterprise-scale applications. In our use case, as data and traffic increased, we were able to scale by adding nodes to the clusters without major changes to the applications, making the scaling very smooth and predictable.

MarkLogic has been generally good and reliable in my experience. When I connect with them, it is very responsive. I have gone through support tickets, and proper tracking is available, so overall, it is a good support system, and I would rate it slightly higher than average.

I would rate MarkLogic's customer support an eight due to its responsiveness, especially for higher priority issues. Support engineers demonstrate good product expertise, and the structure of the ticketing and enterprise support models work well. If someone inquires, I would suggest looking for alternatives if their team is small or they have cost constraints, but if there are no budget issues and their team is large, MarkLogic is reliable and comfortable, providing scalability.

Before adopting MarkLogic, we were using a combination of traditional relational databases such as Oracle along with a separate search solution, such as Elasticsearch.

The main reason for switching from Oracle and Elasticsearch to MarkLogic was simplifying our architecture by consolidating database and search into a single platform. With Oracle and Elasticsearch, we had two separate systems, and syncing between them was complex and error-prone. MarkLogic allowed us to manage these components on one platform. Given that our data was semi-structured, managing it in a relational database was tough, but MarkLogic's document model made schema evolution easier without extensive migration.

We did not purchase MarkLogic through the AWS marketplace.

We saw a clear return on the investment after implementing MarkLogic in terms of saving and personnel efficiency. Since we did not need a separate database and search system, we avoided building and maintaining integrations. This led to roughly a thirty to forty percent reduction in backend development effort. With flexible schema and universal indexing, new features and data sources were onboarded faster, reducing feature delivery time by around forty to fifty percent. In terms of infrastructure and maintenance, we also achieved twenty to thirty percent savings in infrastructure and maintenance overhead.

My experience with MarkLogic's pricing and licensing is that it positions itself as an enterprise-grade product. The cost is relatively high compared to open-source alternatives. We use enterprise licensing models, which gives us access to enterprise features and official support. The initial setup cost is moderate to high, mainly due to infrastructure provisioning, licensing costs, and initial configuration and onboarding efforts.

Before finalizing MarkLogic, we evaluated a few alternatives. We looked at MongoDB, which is good for flexible document storage but required a separate search solution for advanced queries. We also considered using Oracle, which is strong and reliable but less flexible for semi-structured data. Therefore, we selected MarkLogic because it uniquely provides multi-model support along with built-in search and ACID transactions with real-time indexing.

My experience with MarkLogic has been very positive. It is a powerful platform, especially for data-driven and search-driven applications where handling complex XML and JSON data and real-time querying is important. The combination of database and search capabilities along with strong consistency and scalability make it an excellent choice for enterprise use cases. However, there are areas such as developer experience, ecosystems, and the learning curve that could be improved to enhance accessibility. I would rate MarkLogic an eight overall.