MarkLogic, dual-wielding its way through transactional and analytical workloads

Is dealing with transactional and analytical workloads in a single database a pipe dream? Not according to MarkLogic, which has its own way of taking on both.
Even for big data enthusiasts, HTAP is probably YAA. Cryptic acronyms aside though, the notion of having one database to process both transactional and analytical workloads has been a recurring one through the years. This is the road that MarkLogic, like a few others before it, is walking down.
MarkLogic started out as a pure-play XML database back in 2001. The founders had a background in search, so the notions of shared nothing architecture and inverted indices came naturally, even though they have not been widely replicated until recently. You could say that MarkLogic was somewhat of a maverick or maybe ahead of its time, and it therefore had a hard time hitting the mainstream. I have seen numerous executives either failing to grasp what it’s all about — or just not being able to see the use.
But, eventually, MarkLogic found its way to the enterprise, largely thanks to the publishing industry. It was around 2003 when Google started becoming a threat to paper publishers and MarkLogic started making its name. It did that by helping traditional publishers transition to a new era of content management, going from books and journals to apps delivering high-value content to the right people.
It was a good match, as publishers have a lot of unstructured information they could use a database for, and that’s what MarkLogic touted itself as: a database for unstructured content, based on its schema-less data model. MarkLogic promotes its solution as a self describing format that accommodates all kinds of data, and it’s flexible enough to make the need to know your schema in advance obsolete.