MarkLogic Multi-Model Database: Enterprise Edition v. 11

Our main use case for MarkLogic  is harmonization for a lot of data.

We have a framework that is DHF 5 and it is based on Java. It helps us gather the data from many source systems and then put it into one system that is MarkLogic . We have control over this data coming from many sources. We do not have to wait for many source systems and be dependent on many source systems. We have accomplished this where all the important data is placed at one place and MarkLogic is that place. MarkLogic will be syncing the data every day, and it will help us keep the data in one location. My main use case is harmonization, and then data is available for all the other source systems, whichever want to use this data.

MarkLogic has become a central piece for us now. We use APIs, TensorFlow , and many other things that MarkLogic provides. We also take help of AWS  to store the data and then use MLCP to ingest it into MarkLogic.

The best feature of MarkLogic is its search capability. It is really fast. It uses indexes and things are stored in document format. Whatever you want to query in the document, particular elements or properties are indexed by MarkLogic and we can then retrieve them. It is really quick in the way that we want to have it retrieved.

This speed helps us in many places because we are retrieving the data and somebody else is trying to consume it. Other source systems are waiting for our response from MarkLogic. If the response from MarkLogic is really fast and we are able to provide a response within quick time, the other source systems will be using this response and getting the end result in a very quick fashion. This is really helpful in making the customer user experience very fast.

I think data is really secure in MarkLogic, and we can govern the data as well.

MarkLogic can be improved.

An AI assistant would be good if it fits into a query console where we write our code.

There is no AI involved in MarkLogic as of now, so I have not used it. It may be present, but I have not seen any AI implemented into MarkLogic.

I have been using MarkLogic for about six or more years.

MarkLogic is pretty stable. I believe it is really nice.

Scalability-wise, I think it is acceptable. We have to add a lot of cost when we want to scale it because it is really hard to buy a new cluster. The costing is really high for scalability, but we can do it. There are no issues.

Customer support is really good. I think they are very reachable and they provide a solution whatever we need. We mostly use their support for issues with recovering data, and they tell us how we can recover.

I would rate customer support 10 out of 10, but we did not have much conversation. It is just one time we needed help, otherwise MarkLogic itself is good. There is a lot of documentation.

We did not use another solution before.

Pricing is a little high, but in terms of the features it provides, I think it justifies the cost. It is really good. It is not very hard to set up.

We do not have any relationships with the vendor other than being a customer.

We have definitely seen a return on investment. The end customer really felt that things are going fast and they are able to make more work and get more work done because MarkLogic is fast and they are able to search within the system or everywhere. They are able to get the data very fast. They are able to retrieve, change it, transform it, and merge or discard many things they want to do in MarkLogic. It is really helpful for them to have MarkLogic in the system that they use. In metrics, I think they save three or four hours now daily because we have really enabled them to have the data in real time instead of waiting for another day.

We did not evaluate other options before choosing MarkLogic.

About the features, there is also graphs, but we have not used it.

There are features in MarkLogic that are really fast and really good. It takes care of all of the things. It is an enterprise-level database which is helping us eliminate the need of purchasing other tools. It is really good.

My advice for others would be to try to purchase it first. They can try to learn and get experience on how to work with MarkLogic and then they can buy.

I would rate MarkLogic nine out of 10.

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.

Our main use case for MarkLogic  is as a data hub for integrating and managing data from multiple sources. I mostly work on ingesting data from different systems and transforming it and storing it in a structured way so it could be used by downstream applications. For example, in one of our projects, we were pulling data from a couple of legacy systems and normalizing it into a common format using a MarkLogic  pipeline. I also use it for writing queries, mainly XQuery or JavaScript, to fetch and process data based on day-to-day business needs. Sometimes, it is about building APIs on top of MarkLogic to expose that data to other services. Overall, it is a mix of data ingestion, transformation, and querying, making that data usable for applications.

When considering that use case, the biggest difference I notice with MarkLogic compared to traditional approaches or manual processes is how much it reduces the effort of handling different data formats. Before this, in some projects, we had to write separate pipelines or scripts to process XML, JSON, and other formats. This became quite fragmented. With MarkLogic, we could handle both structured and unstructured data in the same place, which simplified things a lot. For example, in one use case, we were getting data from two systems, one sending XML and another JSON. Instead of building separate transformation layers, we ingested both into MarkLogic and then harmonized them into a common model. That saved a lot of development time and also reduced complexity. Another thing that stands out is how quickly we could query and retrieve data. Since everything is stored in a flexible document model, we did not have to redesign schemas every time whenever requirements changed. That made iterations much faster compared to traditional setups. It is not always simple. There is a learning curve, especially with data modeling and writing efficient queries. Once the team gets comfortable, it becomes a very powerful platform for data integration.

One thing I did not expect initially was how useful MarkLogic is for tracking data lineage and debugging data issues. When something looked wrong in the final output, we could actually trace back how the data was ingested and transformed step-by-step. Since everything is stored as documents and transformations are applied in stages, it became easier to identify where things went wrong. Regarding one of the cases I remember, a field was getting overwritten during harmonization, and instead of digging through multiple systems, we tracked it directly within MarkLogic and fixed it quickly. The flexibility of the data model helped a lot. When requirements kept changing, it really helped. Instead of redesigning schemas, we could adjust the document structure and update transformations, which made our workflow more adaptable. Overall, it helped with debugging and maintaining data quality, which was a nice advantage.

A few features really stand out for me, especially when working on data integration projects. One of the most valuable ones is its ability to handle both structured and unstructured data in a single platform. For example, we deal with XML, JSON, and some semi-structured data from different systems. MarkLogic allows us to store and query everything together without needing separate pipelines. That simplified our architecture quite a bit.

Another strong feature is the flexible document model. Unlike relational databases, we do not have to strictly define schemas upfront. In one project, requirements kept changing and it was dynamic. Instead of redesigning tables, we could adjust document structures and just continue with that. That saved a lot of rework. I also found the search and indexing capabilities very powerful. Even with large datasets, we could retrieve data quickly. We had use cases where we needed to search across multiple kinds of fields and documents, and MarkLogic handled that efficiently without much tuning.

One feature I personally relied on a lot is the built-in support for XQuery and JavaScript. It gave us flexibility in how we query and process data. For some transformations, XQuery worked really well, while for others we used JavaScript, depending on the complexity. Overall, what stands out is how all these capabilities are available in one platform, which reduces the need for multiple tools.

The flexible document model probably had the biggest impact on our projects. I can share a good example from a project where we were integrating customer data from multiple systems. Each system had a slightly different structure: some had extra fields, some were missing fields, and formats were not consistent at all. If we used a relational database, we would have had to keep altering schemas or creating multiple tables to handle those variations. But with MarkLogic, we could store each record as a document and gradually harmonize it into a common model. At one point, the business added new attributes to customer data midway through the project. Instead of redesigning anything, we just updated the transformation logic and started storing the new fields in the document. That change was handled pretty smoothly without impacting existing data. That flexibility saved a lot of time and avoided rework. It also made our system more adaptable to changing requirements, which happens quite often in real projects.

One small but really useful feature is the built-in transaction and consistency handling. In one scenario, we were ingesting data in batches and there was a failure midway due to a data issue. MarkLogic handled it in a way that partial data was not left in an inconsistent state, which saved us from a lot of cleanup work. Additionally, the security and role-based access control is quite granular. We had cases where certain data needed to be restricted to specific roles. We managed that at a document level, which was really very helpful. These are not things you notice immediately, but in real-world usage, they make the system much more reliable and easier to manage.

MarkLogic has had a strong impact, especially in how we handle and use data across teams. Earlier, data was scattered across different systems, and getting a unified view required a lot of manual effort and coordination. With MarkLogic acting as a central data hub, that process became much more streamlined. Instead of pulling data from multiple sources every time, we had a consolidated dataset available, which made development and reporting faster. It reduced a lot of back and forth between teams and saved a few hours every week during development and testing stages. I think it also improved data quality. Since we had defined ingestion and transformation steps, inconsistencies were caught earlier rather than later in the pipeline. Overall, it helped improve efficiency, reduced duplication of work, and made it easier for teams to rely on consistent data.

In terms of metrics, we did see measurable improvements over time. Earlier, when we had to pull and reconcile data from multiple systems manually, it used to take a few hours for certain use cases. After moving that into MarkLogic pipelines, the same process became almost near real-time or at least reduced to minutes in most cases. In terms of development effort, we saved around 20 to 30 percent of time on data handling tasks, mainly because we did not have to build separate transformation layers or repeatedly fetch data from different sources. We also saw fewer data-related issues during testing since data was being standardized during ingestion, so inconsistency reduced. Improvements were noticeable in faster data access and also reduced manual effort and better data consistency.

One area where I feel MarkLogic can improve is the learning curve. When I first started, concepts like data modeling, indexing, or writing efficient XQuery were not very intuitive. It took some time to understand how to structure data properly to get good performance. More beginner-friendly guidance or simplified onboarding would help new users. Another thing is tooling and debugging experience. While it is powerful, debugging queries or transformations can sometimes feel less straightforward compared to more modern developer tools. In a few cases, we spent extra time figuring out why a query was not performing well. Better integration with modern development ecosystems and more lightweight setup options would make it easier for teams to adopt quickly. It is a strong platform, but improving ease of use and developer experience would make a big difference.

One small thing I have noticed is around monitoring and visibility. When things are running fine, it is great, but when something slows down, such as a query or ingestion job, it is not always very easy to quickly pinpoint the issue. We sometimes had to dig through logs or try different things to understand what was happening. Having more intuitive monitoring dashboards or clearer, cleaner insights into query performance and pipeline stages would be really helpful. Small improvements in documentation with more real-world examples would make a difference, especially for new developers trying to understand best practices. Nothing major, but these small things would make day-to-day usage smoother.

I have been using MarkLogic for around two years.

In my experience, MarkLogic has handled scalability quite well, especially as our data volumes grew. For example, in one project, we started with a relatively small dataset, but over time it scaled to millions of documents. We did not have to redesign the system; we mainly scaled by adding more resources and adjusting indexes. The platform handled that transition smoothly. On the user side, as more services started consuming data from MarkLogic, we did not see major issues in terms of performance. Query response times remained fairly consistent as long as indexing and data modeling were done properly. Overall, it scales well, but getting the best performance depends on how well you design and configure it.

Regarding customer support for MarkLogic, in our experience, we did not rely heavily on customer support on a day-to-day basis because once the system was set up, it was quite stable, and most issues could be handled internally. That said, there were occasions, especially early on, where we needed help around configuration and performance tuning. In those cases, the support team was helpful and guided us in the right direction, although it sometimes took back and forth to fully resolve the issue. Overall, the support is considered above average, with good responsiveness and helpful guidance when needed. We mostly relied on internal expertise and documentation and reached out for complex issues.

Before moving to MarkLogic, we were mainly using a combination of relational databases and some custom ETL scripts for handling data integration. The challenge with that setup was that it became quite complex as the data volume and variety increased. For example, handling both XML and JSON data required separate processing logic, and maintaining those pipelines took a lot of effort. We switched to MarkLogic because it offered a more unified approach, allowing us to handle different data formats in one place and reducing the need for multiple tools and scripts. The flexibility of the document model and built-in capabilities for ingestion and querying made the overall system simpler and easier to manage compared to what we had earlier.

We evaluated a few other options before choosing MarkLogic. We looked at traditional relational database solutions as well as a couple of NoSQL options like MongoDB. Relational databases were strong for structured data but did not handle changing schemas or mixed data formats well for our use case. MongoDB was closer to what we needed in terms of flexibility, but when it came to advanced search, indexing, and built-in support for both XML and JSON, MarkLogic had an edge.

I suggest starting with a clear understanding of your data use case before adopting MarkLogic, especially if you are dealing with multiple data formats or large volumes of data. That is where it really adds value. From our experience, it is important to invest time early in data modeling and indexing. We initially underestimated that, leading to performance issues later. Once we optimized indexes properly, things improved a lot. Also, make sure your team gets comfortable with the basics of XQuery or JavaScript in MarkLogic. There is a learning curve, but once you get past it, development becomes much smoother. I recommend starting with a smaller use case or pilot project, which helped us understand how to structure data and pipelines before scaling it across the system. It is a powerful platform, but you get the best results when you plan the foundation properly and gradually build on it.

Regarding additional thoughts on MarkLogic, one additional thought I would add is how MarkLogic fits as a long-term solution. From my experience, it is not just a tool you use for a short-term project. Once it is set up properly, it becomes a core part of your data architecture. More teams gradually started relying on it once they saw the value of having centralized and consistent data. It is important to have the right expertise in the team. It is a powerful platform, but to get the best out of it, you need people who understand how to design data models and optimize queries properly. It is a strong platform for enterprise use when you treat it as a long-term investment rather than just a quick solution.

My overall rating for MarkLogic is 8 out of 10.