What needs improvement with MarkLogic?

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.

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.

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.

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 would rate this a nine because I think MarkLogic can incorporate some AI features that are emerging in other databases.

As for areas where MarkLogic can be improved, nothing else comes to mind. I have been using MarkLogic for seven years, and many improvements have already been addressed. I do not recall any additional needed improvements.

The spreadsheet capabilities could be improved. We need to convert spreadsheets into an open XML format. We have to do a few levels of conversions before we convert the data into the information we require. It would be ideal if the process could be a bit more streamlined to simplify the process. When we convert to XML, there's a lot of unnecessary data, and we have to manually clean up everything before we can really dig in. The solution is expensive.