MarkLogic Multi-Model Database: Enterprise Edition v. 10

My main use case for MarkLogic  involves running queries to check some of the jobs. I run batch jobs and then I want to check whether the batch jobs are running fine. I check the data on MarkLogic  by running the query on the query logic portal.

Regarding my main use case with MarkLogic, I find it very handy because every time I run a job, I go and run the query. I go to different databases and then see whether it's running fine. It is enjoyable working with MarkLogic.

A recent task where MarkLogic was especially helpful involved trying to check the number of batch jobs, DES or PDM jobs, and different jobs. We always check the number and then based on the number, we compare with other tools and then see whether it's matching. It is a comparison with multiple tools. If, for example, PG Admin was not working with PostgreSQL , but MarkLogic was working fine, we were able to fix the issue on the other tools which were not working.

In my opinion, the best features MarkLogic offers are that it is very easy to use and has a very fast response time.

The fast response time and ease of use help me in my daily work because it is really helpful since we have to run a lot of jobs at the same time and then we want to make sure everything is running as expected. It always helps us to check whether our jobs are running fine.

MarkLogic has positively impacted my organization as I think company-wise, it is one of the go-to tools for validating the jobs we are running. It is very helpful for us to deliver our products with quality and on time.

Using MarkLogic has resulted in specific outcomes, as we run jobs for a long time, sometimes for a couple of days, sometimes for ten hours or twelve hours. It helps us a lot.

I would say the features can be improved, as maybe the UI could be a little better. I am not sure if there are other options, but the one I am using is from the query console, so maybe I am not aware of other UI dashboards.

There are ways MarkLogic can be improved. I would like to add that a better UI with more features on it, something user-friendly, would be beneficial.

I think there is nothing else that could be improved about MarkLogic.

I have been using MarkLogic for two years.

If someone is looking into using MarkLogic, I would say MarkLogic is very helpful for providing the monitoring with detailed features. Running the query is very easy. I rate this product an eight out of ten.

I use MarkLogic  for performing many operations such as handling semi-structured data and building search-driven use cases. For example, I examined how it can handle and store XML documents and leverage its powerful indexing and search capabilities for fast querying. It is particularly useful in scenarios where you need flexible schemas along with advanced search capabilities including filtering, full-text search, and aggregations.

A task where MarkLogic  was central to my work was a travel search and filtering system, similar to a hotel listing use case. In this project, the data was semi-structured, with elements such as hotel details, amenities, and pricing that vary significantly across different entities. I used MarkLogic to store this data as JSON documents. What made MarkLogic central was its built-in indexing and search capabilities. I configured indexing on fields such as location, price range, and amenities and then used its query capabilities to perform fast filtering and full-text search. Instead of relying on a separate search system, MarkLogic handled both data storage and search efficiently, which simplified my architecture and improved query performance.

MarkLogic for the hotel listing and search use case compared to other approaches made things easier than a traditional approach. If I compare it with using MySQL  and Elasticsearch, typically you would need to maintain two systems: one for transaction storage and another for search. That introduces challenges regarding data synchronization, consistency, and operational overhead. With MarkLogic, since it natively supports both document storage and advanced search, I could avoid the dual-system complexity. It simplified the architecture because indexing and querying are built-in and tightly integrated. In terms of performance for semi-structured data and search-heavy queries, it was quite efficient because indexes are created automatically and queries are optimized around them. The schema flexibility was a significant advantage and it also helped reduce system complexity, improve development speed, and handle search use cases efficiently.

One thing I found particularly useful was that MarkLogic handles indexing by default, unlike a traditional system where you have to explicitly define and manage indexes. MarkLogic automatically indexes documents, which made it easier to get started and integrate quickly. Another advantage is that it can handle both structured and unstructured data together, which is very useful in real-world scenarios where travel data has a mix of fixed fields and dynamic attributes. The fact that it supports flexible querying over nested data without needing complex joins made development simpler and queries more intuitive.

Many features offered by MarkLogic are valuable. One of the standout features is its multi-modal capability. It can handle JSON, XML, and RDF data in a single database. That is particularly useful for applications dealing with diverse and evolving data formats. Another feature is the built-in search and indexing capability, along with schema flexibility since it is document-based. It handles semi-structured and nested data very naturally, which reduces the overhead of schema migration. An important feature is ACID transactions with NoSQL flexibility, so you can get reliability from a traditional database along with the scalability and flexibility of NoSQL.

MarkLogic's multi-modal capabilities make things easier in scenarios where JSON can be used for application-facing data such as hotel details, XML comes into play with external APIs, and RDF can be used for representing relationships. Instead of converting everything into one rigid format, MarkLogic allows you to store each in its native form and still query and access them. This opens up possibilities such as combining search data with relationships and searching in a single query, which would otherwise require multiple systems or a complex data pipeline. Overall, it reduces data transformation efforts, simplifies architecture, and makes it easier to build richer and more connected database models.

One thing that surprised me about MarkLogic is how it has so many built-in traditional capabilities. Features such as search, indexing, and even data integration are natively available, so you do not have to rely on multiple external systems. That was unexpectedly useful because it simplified the overall architecture significantly. Another interesting aspect was its flexible querying over deeply nested data. In traditional databases, handling nested or hierarchical data often requires complex joins. I found it interesting to design data platforms rather than just a database, especially with complex capabilities around search and integration.

MarkLogic has impacted my organization positively. Since my exposure to MarkLogic has been more on the exploration and evaluation side, I did not see full production-scale impact. However, even in the use case I worked on, a few clear benefits stood out. One was simplifying the architecture instead of thinking in terms of separate systems such as MySQL  for storage and Elasticsearch for search. MarkLogic allowed both in a single system, which reduced integration overhead and potential consistency issues. Another benefit was fast deployment and integration because of its schema flexibility and automatic indexing. It was easier to onboard new data fields and quickly test different query patterns without heavy schema changes. I noticed that the search-heavy queries on semi-structured data performed quite well, which really helped in reducing system complexity and speeding up development for search-heavy, semi-structured data use cases.

Regarding improvement, I have identified a few areas. MarkLogic is quite powerful, but some areas need enhancement. One thing I noticed was the learning curve. Compared to commonly used databases such as MySQL or even MongoDB, MarkLogic requires understanding concepts such as XQuery, server-side JavaScript, and its internal architecture, which can take time for new developers. Another area is community and ecosystem support; it is not as widely adopted as other databases, so finding resources can be challenging. Third-party integration can be relatively harder. Additionally, from what I have observed, cost and licensing can be a consideration, especially for smaller teams or startups compared to open-source alternatives. Finally, while it is very strong for search and document-based use cases, it might feel excessive for simpler CRUD-based operations, where a traditional relational or lightweight NoSQL database would work better.

Documentation is an area that could improve. Learning resources and documentation could be enhanced, as the official documentation is detailed but can sometimes feel dense for beginners, especially when getting started with concepts such as indexing or writing queries in XQuery. Additionally, debugging and troubleshooting can be slightly challenging compared to more mainstream databases, mainly because the ecosystem is smaller and there are fewer community discussions and examples available. The developer experience could also be improved; setting up, experimenting, and integrating MarkLogic in an existing setup felt less straightforward compared to commonly used databases. I think improving onboarding, simplifying documentation, and expanding community support could make it even more developer-friendly in the future.

I have been using MarkLogic for approximately half a year.

In my experience, MarkLogic is stable. It can be used in different environments and is designed for enterprise use cases involving large volumes of data and complex queries.

MarkLogic is designed to scale horizontally, which means you can add more nodes to the cluster to handle increased data and query load. It distributes data across units called forests, and these forests can be spread across multiple nodes. This allows both storage and query processing to scale out efficiently.

I have faced some situations where I needed help. While I have not interacted directly with MarkLogic support in a production environment, my understanding is based on industry feedback, which suggests it has enterprise-grade support, including ticketing systems and dedicated support channels for customers.

Before MarkLogic, I used a combination of MySQL for storage and sometimes Elasticsearch for search-heavy use cases. While exploring MarkLogic, the approach was not an immediate switch in production but more of an evaluation to see how it compared to the traditional approach of using MySQL and Elasticsearch.

Since my experience with MarkLogic is more focused on exploration, I have not seen production-level ROI metrics such as cost and team size reduction. However, even during the evaluation, I could see potential in reduced development effort. The performance of search and filtering queries on semi-structured data felt more efficient compared to a traditional approach using MySQL and Elasticsearch. While I cannot quote exact numbers since it was not in production, it definitely showed potential for reduced development time, simplified architecture, and fast search use cases. Ultimately, it reduced development complexity and effort noticeably, especially by eliminating the need to manage multiple systems.

Since my experience is more focused on exploration, I have not seen production-level ROI metrics such as cost or team size reduction. However, even during evaluation, I could gauge potential ROI in terms of what it generates and the additional benefits it provides.

Regarding pricing and setup cost for licensing, I have not worked on a production setup, so I have not been directly involved in handling pricing and licensing. However, my exploration indicates MarkLogic follows a licensing model that can be relatively higher compared to open-source databases, making cost an important factor for smaller teams.

Before choosing MarkLogic, I explored some alternatives, primarily comparing it with the combination of MySQL and Elasticsearch, and I also considered MongoDB since it provides document-based storage and schema flexibility. The key difference I found was that while MongoDB handles flexible data effectively, it does not offer the same level of integrated search capability as MarkLogic.

I would suggest first clearly evaluating whether your use case truly benefits from MarkLogic's strengths. It works particularly well for search-heavy and semi-structured data use cases where flexible and powerful querying is needed. At the same time, I would recommend comparing it with alternatives such as MySQL, MongoDB, and Elasticsearch for trade-offs. Additionally, it is important to plan for the learning curve, especially around concepts such as indexing and querying.

Overall, I think MarkLogic is a very powerful platform, especially when involving semi-structured data and advanced searches. I would rate this review an 8 out of 10.

My main use case for MarkLogic  is for a specific client where I handle XML data in the backend. I use XQuery, and we utilize MarkLogic  mostly for querying the data in the backend.

In one of my use cases, we stored customer policy records as an XML document in MarkLogic. Each document contained details such as policy number, customer name, and other metadata. A common requirement was that users often did not remember the full policy number, so they searched using partial input, such as part of the policy number or their name. I implemented XQuery-based search logic along with proper indexing, so MarkLogic could efficiently return the matching document even with incomplete input. This significantly improved search performance and user experience.

Apart from the search cases, one key advantage we leveraged with MarkLogic's schema flexibility was that since our data was stored in XML, we could easily accommodate changes in the structure without major migration. I also worked on optimizing query performance by configuring indexes properly, which reduced query response time significantly. Additionally, we used MarkLogic as a central data store, integrated with the backend service through APIs, ensuring fast and reliable data access. We also ensured that the queries were written efficiently and aligned with the index configurations to avoid full document scans, which is critical for performance in MarkLogic.

The best features of MarkLogic are its powerful search capabilities, flexible schema, built-in indexing, and high performance for XML or JSON data. MarkLogic provides a Google search-like capability, including full-text search, partial matching, and relevance scoring. Another feature is schema flexibility; since it is a document-based database, we can store XML or JSON without a strict schema constraint, which makes it easy to evolve data structures.

The third feature is built-in indexing, as MarkLogic automatically maintains indexes, and we can configure the range indexes to specifically improve query performance. MarkLogic's XQuery support, which is native to the platform, allows efficient querying and transformation of XML data, while it even supports ACID properties. Unlike other NoSQL options, MarkLogic supports full ACID property compliance, ensuring data integrity and consistency.

MarkLogic's built-in indexing allows queries to run directly on indexes instead of scanning documents, which significantly improves performance. MarkLogic uses a universal index that automatically indexes all the content in the database, both structured and text, without requiring manual indexing as a traditional database would. We can configure range indexes for specific fields, such as policy number or customer name, allowing faster filtering and sorting of the results. In my workflow, this has helped tremendously because queries execute directly instead of scanning the XML data. Search performance improved significantly for partial and filtered searches, and it also reduced response time for user queries, even with a large database.

MarkLogic has improved our system performance, enabled flexibility in data handling, and specifically enhanced search efficiency. It improved search performance, provided flexibility in data modeling, and since it supports XML and JSON without a strict schema, we could easily adapt to changes in business requirements without any major database alterations. It even reduced development effort, as features such as built-in indexing and search reduce the need for external search systems, simplifying our architecture. It resulted in a better user experience with faster query responses and flexible searches. For example, earlier search operations were slow and less flexible, but after using MarkLogic, we delivered near real-time results, improving both system efficiency and user satisfaction.

While MarkLogic itself is powerful, it can be improved in terms of ease of usage, cost, and the learning curve. MarkLogic is a very strong enterprise-level database, but there are areas for improvement. There is a steep learning curve for this technology; XQuery and internal concepts such as indexing and CTS queries take time to learn compared to more common databases such as MongoDB. It is also relatively expensive compared to open-source alternatives such as MongoDB, which can be a concern for small organizations. Compared to databases such as MongoDB or MySQL , the community is smaller for finding resources or solutions, which can sometimes make it harder. Even debugging and development tools could be more user-friendly and modern.

Documentation and learning resources could definitely be improved to make onboarding easier. While MarkLogic does have official documentation, it can sometimes be harder to navigate and not very user-friendly, particularly for developers new to concepts such as XQuery and CTS queries. In my experience, it sometimes took extra time to find the right examples or best practices; even practical real-world scenarios were limited. Compared to more popular databases, community-driven tutorials are very few. Better documentation along with improved tooling would make MarkLogic even more developer-friendly without compromising its powerful capabilities.

Our setup was managed by AWS  infrastructure, and my main focus was on development and working with MarkLogic from the application perspective. We saw a positive return on investment through improved performance, reduced system complexity, and better user efficiency.

I have been using MarkLogic for the last two years.

MarkLogic is very stable and reliable for enterprise applications. It supports ACID transactions, which ensure data consistency and reliability. Its clustered architecture ensures high availability.

MarkLogic is highly scalable and supports horizontal scaling through its clustered architecture. We can add more nodes to the cluster, and data is distributed across them using Forest, which helps in handling increasing data volume and traffic. Since we are utilizing AWS , we can scale resources up or down based on the load and manage large datasets efficiently without significant degradation in performance.

Customer support for MarkLogic provides strong enterprise-level assistance through direct interactions. It is usually handled by a specific team that is very responsive to a variety of issues we encounter.

I started only with MarkLogic. While I was aware of MySQL , I began working with MarkLogic when I joined the organization, so I did not use any different solutions.

MarkLogic is deployed as a cluster environment on the server, enabling scalability, high availability, and fault tolerance. My organization has MarkLogic deployed in a cluster setup, which helps with scalability and high availability.

We saw a positive return on investment through improved performance, reduced system complexity, and better user efficiency.

We evaluated other options such as MongoDB and Elasticsearch before choosing MarkLogic.

MarkLogic's built-in indexing allows queries to run directly on indexes instead of scanning documents, which significantly improves performance. MarkLogic uses a universal index that automatically indexes all the content in the database, both structured and text, without requiring manual indexing as a traditional database would. We can configure range indexes for specific fields, such as policy number or customer name, allowing faster filtering and sorting of the results. In my workflow, this has helped tremendously because queries execute directly instead of scanning the XML data. Search performance improved significantly for partial and filtered searches, and it also reduced response time for user queries, even with a large database.

My main use case for MarkLogic  is for storing data. A quick specific example of the kind of data I store in MarkLogic  is that we have a data warehouse, and we use it as a NoSQL database to store, manage and search complex heterogeneous data.

MarkLogic has positively impacted my organization by making our job easier, although we have yet to notice the full details. It made my job easier because we can store a large number of data, and the built-in search feature is great, including semantic data management.

The best features MarkLogic offers include multi-model flexibility, built-in search, data hub platform integration, and semantic data management. I personally appreciate the built-in search feature because it indexes all data immediately upon ingestion for rapid searching, so we can perform full-text, phrase, or geospatial searches.

MarkLogic has positively impacted my organization by making our job easier, although we have yet to notice the full details. It made my job easier because we can store a large number of data, and the built-in search feature is excellent for semantic data management.

I would rate this a nine because I think MarkLogic can incorporate some AI features that are emerging in other databases.

I have been using MarkLogic for five years.

MarkLogic is stable.

MarkLogic's scalability is impressive as it is scalable, and we can scale it to an unlimited number of data, allowing it to store unlimited data.

The customer support is good.

I did not previously use a different solution.

My experience with pricing, setup cost, and licensing was good.

I purchased MarkLogic through the AWS Marketplace .

I do not have metrics to share about return on investment as I am not the right person for this question; that is calculated by our Chief Financial Officer.

My experience with pricing, setup cost, and licensing was good.

Before choosing MarkLogic, we were evaluating other options in addition to Cassandra  DB. MarkLogic compared to Cassandra  is preferred because of the features and pricing.

MarkLogic is great, and my advice for others looking into using MarkLogic is that it is a great database with awesome features that you should consider. I would rate this product a nine out of ten.