MarkLogic Reviews

MarkLogic's primary use case in my experience is handling semi-structured and hierarchical data that does not fit neatly into traditional relational tables. In my particular project, I work with NoSQL data, meaning I handle semi-structured and hierarchical data. For example, in one of my insurance projects at ValueMomentum, I worked on an initiative where I had policy and claims data in XML format coming from different legacy systems. I used MarkLogic to ingest and normalize the data and integrate it with our Hive data warehouse for reporting and analytics. A specific example I would share is that I created a 360-degree view of customer policies and claims using MarkLogic, which allowed me to merge XML claim documents with relational customer information, perform queries across different nodes, and feed clean aggregated data into the ETL pipeline for downstream analytics.

This significantly saved time compared to flattening everything manually into SQL tables.

Working with XML and integrating that with my ETL processes is quite interesting, as MarkLogic makes it far easier to handle hierarchical data instead of attempting to force it all into relational tables. The built-in support for XML and JSON, combined with the indexing and searching capabilities, allows me to query deeply nested structures without writing extensive custom parsing code. The challenging part is mostly around integration with our existing ETL pipelines, ensuring that transformed data flows correctly into Hive and matches the relational schemas. Sometimes I have to be careful with data types and schema evaluation because MarkLogic is schema-flexible, but the downstream systems are strict. Overall, though, it speeds up handling complex semi-structured data and reduces manual transformation work significantly. I would say it is easier than many other XML handling approaches I have tried.

I would add that I really appreciate how MarkLogic handles hierarchical relationships naturally, especially in insurance data where nested information such as policies contain multiple coverages, each with different claims and documents. This aspect of the insurance domain is really cumbersome, and MarkLogic allows me to query across these nested structures directly without having to flatten everything at the beginning. Its search and indexing features make it easier to identify anomalies or missing information in the semi-structured data before it reaches the ETL pipelines, saving considerable time during validation and reconciliation. Overall, I find it a very practical tool for bridging legacy data formats with modern data warehouses.

In my experience, the best features of MarkLogic include its native support for XML and JSON, which makes working with hierarchical or semi-structured data easier than flattening it into relational tables. Additionally, its flexible schema and indexing capabilities allow me to index anything, including nested elements, which speeds up queries and reduces the need for custom code. Other significant aspects include built-in search capabilities that allow for full-text searches and complex queries directly on documents, and data integration and harmonization, which combines multiple sources into one logical view, simplifying manual processes.

Finally, ACID transactions on semi-structured data give me confidence that updates, merges, and data integrity remain intact even in large or complex datasets.

The flexible schema, indexing, and search capabilities of MarkLogic are incredibly useful for me. For example, the flexible schema and indexing mean I can load all the XML or JSON policy and claims data without having to predefine rigid table structures, saving considerable time during ingestion, especially since different legacy systems may have slightly different formats. I can simply map the fields I need and let MarkLogic handle the rest. The search capabilities are also very helpful; I can run queries across nested elements to find specific claims, policies, or attachments quickly. Previously, doing this in a relational database would require multiple joins and a great deal of transformation logic.

MarkLogic has had a tangible positive impact on our organization. Thanks to its flexible schema and indexing capabilities, we ingest semi-structured and hierarchical data from multiple legacy systems 30 to 40 percent faster than before, which leads to faster ETL cycles and quicker delivery of analytics-ready datasets to downstream systems. Using MarkLogic's search and query capabilities, I also reduced the time to reconcile and validate policy and claims data across systems by approximately 35 percent, helping business teams gain insights much faster. This highlights the positive impact MarkLogic has made in our organization.

There are several things I have observed regarding MarkLogic's improvement areas. One challenge I notice is the learning curve and setup; it can be complex for someone new, especially when integrating with other systems or setting up indexing strategies for large datasets. I occasionally spend extra time fine-tuning indexes or query performance for really large documents. Another observation concerns tooling and ecosystem support, as it does not feel as rich as mainstream databases such as Hive or SQL servers in terms of connectors and integration or community resources.

Sometimes I need to build custom scripts to bridge these gaps. Finally, monitoring and debugging distributed queries can be tricky; while it has built-in tools, deeper performance profiling or tracing is not always intuitive. Overall, these are not deal-breakers, but improvements in onboarding, ecosystem connectors, and monitoring would enhance the experience.

I have been using MarkLogic for approximately two to three years, primarily during my enterprise projects where I handle structured or semi-structured data, build integration pipelines, and ensure it works well with other data sources such as Hive and SQL server. I would not call myself a hardcore MarkLogic expert, but I am comfortable navigating its database features, writing queries, and integrating it into larger workflows.

It has been practical experience rather than just academic work. I have done several things in that area, but I am not very hands-on with it.

MarkLogic is generally quite good, and in my experience, it is very stable and reliable. I have not faced any major downtime; there have only been occasional minor glitches during cluster configuration or heavy indexing, but nothing that significantly affected production. The built-in replication and failover features also help maintain uptime, ensuring the system stays operational even during maintenance or updates.

Overall, I find it trustworthy for enterprise workloads, especially regarding the semi-structured and hierarchical data I work with.

MarkLogic's scalability is quite solid; scaling up and out as data needs grow does require some planning. I have scaled both vertically by upgrading nodes and horizontally by adding nodes to clusters as my data volume increased. The system handles this increase in XML workloads well, and flexible indexing helps maintain query performance even as datasets expand. However, planning the cluster layout and indexing strategies carefully is crucial. If I just throw the data in without a strategy, performance can degrade, but once set up properly, scaling out is smooth.

Overall, it is definitely enterprise-ready for growing data needs.

Before MarkLogic, I primarily relied on relational databases such as SQL servers and some Hive-based data warehouses to manage my data. The reason for switching or adding MarkLogic into the mix is that a great deal of my incoming data is semi-structured, such as XML or JSON from legacy systems, which was cumbersome to flatten into relational tables. It was slow, prone to errors, and complicated ETL pipelines.

MarkLogic made it much easier to ingest, query, and integrate semi-structured data directly without all that extra transformation overhead. It was not a complete replacement but rather a specialized tool for a specific pain point in my data flows.

From my perspective, there has definitely been a return on investment with MarkLogic, even if it is not always easy to quantify in exact dollar terms. For example, by using MarkLogic to handle semi-structured data directly, I have reduced ETL prep and transformation time by roughly 30 to 40 percent, freeing up engineers to focus on more value-added tasks instead of manual data cleaning.

Additionally, faster validation and reconciliation of policy and claims data mean business teams can generate reports and insights 35 percent faster.

I do not actually deal with pricing, setup costs, or licensing because I work for an organization, but I believe the pricing and licensing are definitely on the higher side compared to open-source alternatives, based on what I have heard from managers.

I evaluated multiple options before choosing MarkLogic, including alternatives such as MongoDB, Couchbase, and PostgreSQL with JSON support. While MongoDB excels in JSON handling and NoSQL flexibility, it lacks ACID compliance across complex transactions. Couchbase is good for key-value and document storage but did not fit my hierarchical XML-heavy use cases. PostgreSQL with JSON support could handle some semi-structured data, but its performance on large nested XML datasets was not great, and ETL complexity remained high.

Ultimately, MarkLogic's native XML support, ACID compliance, and built-in search and indexing made it the best fit for my insurance project.

MarkLogic is solid for its main features such as handling XML, flexible indexing, search, and ACID compliance on semi-structured data. However, the learning curve is steep, integration with other systems can be tricky, and the community and tooling are not as extensive as mainstream platforms. It is strong, but I would not say it is perfect.

My advice for others looking into using MarkLogic is three-fold: First, understand your data upfront. If you have a great deal of semi-structured or hierarchical data such as XML or JSON, MarkLogic can save you a great deal of time, but you need to understand your indexing and querying strategies. Second, plan your cluster and indexing strategies carefully as it pays off in performance and scalability later. Third, take full advantage of built-in search and ACID features, which are real-time savers for validation, reconciliation, and governance.

Additionally, do not underestimate the importance of training and onboarding; there is a learning curve, so make sure your team becomes comfortable with queries, transforms, and integrations before relying on it in production. If used correctly, it is a very strong tool for bridging legacy semi-structured data with modern analytics pipelines. I would rate MarkLogic at a seven on a scale of one to ten.

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.

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.

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.

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.

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 primarily for health and insurance companies, and secondarily for publishers who maintain a large set of books online and any company that deals with big data. We keep high volume of data in MarkLogic because it provides a good search engine to query data in large datasets.

A specific example of how a publisher company would use MarkLogic in their workflow is maintaining data of a book, including who published that book, what the author name is, and how many editions exist. You can imagine that there are billions of books across the world, and we want to keep that digitized information in MarkLogic. If you want to search for a particular author, find how many books are published by a particular publisher, or discover editions of a particular book, you can get that information very quickly.

The best features MarkLogic offers include the ability to store unstructured data. You really don't need any particular schema, although it does support storing documents according to a particular schema, but that is not mandatory. You can store your data in XML and JSON format and you can store even binaries, JPEGs, PDFs and that kind of content in MarkLogic. The second feature is that it has a very rich search and cts APIs to build search engines on large datasets. The third is the spell suggestion APIs where, as you type, you will get suggestions of what you are searching for, which helps users understand what they are really searching for. Fourth is the redaction APIs. If you have a large set of data in a live environment and want redacted data in lower environments, the redaction APIs are very effective. From a user perspective, you can keep your data in redacted format in any environment, even on production.

The other valuable feature is the CPF, which is the Content Processing Framework. That is a very powerful tool. You can orchestrate how your document is processed before insertion or after insertion. A big example is that as soon as you have loaded a PDF into MarkLogic and want to extract the data from that PDF and store it as XML in MarkLogic for searching, that is where CPF is very useful.

MarkLogic has impacted my organization positively. We used to have one fetch API which was built using .NET API and the backend was SQL. We got to know from customers that the API was very slow and they were getting impacted. We moved to MarkLogic and created the API using JavaScript server-side language, and we saw almost 60% improvement in the speed of the search. The fetch results were 60% faster after that.

I think MarkLogic can be improved by providing good cloud infrastructure. Since we are in a very tech era, MarkLogic should provide good cloud infrastructure. If you look at other databases or systems like Kafka and MongoDB, they have cloud infrastructure. You do not need to worry about maintaining your own servers or provisioning your own servers. You simply log in and tell MarkLogic you want a certain number of clusters or nodes in a cluster and what cloud provider you want to use, then click okay, and they will build it for you. That is a headache with MarkLogic.

Apart from that, I don't see any issues. It is a really great product.

I have been using MarkLogic for 11 years.

MarkLogic is not entirely stable. We used to have production issues, mainly due to MarkLogic failures. The node goes down sometimes or some memory errors occur. It is stable, but if I rate it out of 100%, it is 80-85% stable. Every year we used to have four to five issues.

MarkLogic's scalability is very bad. In production, when you get to know that your data is increasing and you need to add one more node, that is not easy and not straightforward. You really need to do a lot of work and a lot of planning before you will be able to scale. But in today's world, if I talk about other systems like MarkLogic, if you have to scale, it is just a five-minute job. With MarkLogic, that is not the case.

I find customer support to be good.

MarkLogic has really good deployment processes. If you have a big MarkLogic architecture with hundreds of nodes in the cluster, many databases, forests, and many app servers, their deployment features like ML-Gradle can automate everything. You can create a new cluster within minutes through that Gradle. That is a very good feature they have provided.

I'm not much aware of pricing, setup costs, and licensing because that is another team that deals with it. But if I am correct, a few times I heard them saying that MarkLogic is quite costly, and they are looking to move away in the longer run for that reason.

Before choosing MarkLogic, we analyzed SQL and other solutions, but after analyzing and doing some POCs, we found that in our case, we had to store a large amount of binary data and SQL was not that good at storing binary data, especially when your need is to perform searches inside the binaries. That was something we did not find in SQL, and we did not prefer SQL for that reason.

My advice to others looking into using MarkLogic is that they really need to evaluate their use case. First, they need to evaluate what MarkLogic provides and what the features of MarkLogic are. Then they need to evaluate their use cases and check whether they are able to use the core features of MarkLogic. If not, then there is no point in moving to MarkLogic. Since it has a costly license, they really need to evaluate whether the features MarkLogic is providing would allow them to utilize most of them or not. I would love to see MarkLogic in more cloud-native architecture. I am giving this review a rating of 7.

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 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.