<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=752538731515435&amp;ev=PageView&amp;noscript=1">

Is MarkLogic on ACID?

Dude, is your database on acid?

If you walk by a group of developers chatting and hear something like that - take a moment before channeling your inner Nancy Reagan.

Acid, in this case, isn't a drug but an acronym more correctly written as ACID.

It stands for:

  • Atomicity
  • Consistency
  • Isolation
  • Durability

Digging Deeper

Let's dig into each of those a bit deeper:


Databases are often in a state of change. In database language a group of related smaller changes is called a transaction.

An example transaction is "take $500 out of my checking account and add it to my savings account".

Atomicity is saying that a transactions should either succeed or fail as a whole. If an internet connection goes down or power is lost half-way through the example transaction the $500 should show back up in the checking account.



Databases are usually created with rules around what makes the data valid. Simple data validation rules would be:

  • No half-entered phone numbers
  • No missing or made up zip codes
  • No email addresses without a "@" and a known top level domain (.com, .edu. .net etc)

In a consistent database you would find no database records with exceptions to these rules. Attempting to complete a transaction with invalid data would result in the entire transaction being "rolled back" or undone.


Have you ever gotten into a bidding war on eBay?

You and 30 other people all trying to "snipe" that rare PEZ dispenser at the last possible second in the auction is a great example of why databases need to isolate transactions.

Isolation means each of those last-minute bids are unaware of each other. Ebay's servers will assign a sequential order to them, and if the slower bid needs data from the faster bid (like the newly updated selling price) it will have to wait until the faster bid is done processing.


Hard drives crash. Servers go down. Databases get corrupt.

But end users and customers shouldn't suffer because of that. Durability is the guarantee that once a transaction is complete it will be saved and recoverable.

MarkLogic and ACID

MarkLogic is a No-SQL database that we're getting pretty handy with here at Omni.

Reading up on the differences of SQL vs NoSQL databases, you might think that a NoSQL database wouldn't be ACID compliant.

Au contraire mon frère.

The MarkLogic Developer Blog has all of the gory details, but key takeaways are that MarkLogic achieves ACID compliance by a combination of features including:

  • Document Locks
  • Timestamps
  • Journaling
  • Commit Process

Document Locks

Relational databases usually have record locking, but a NoSQL database doesn't have records. It has documents. MarkLogic has document locks that keep data saved during updates and isolate transactions from each other.


In MarkLogic, when a document is updated it's actually copied and the updates are applied to the new version of the document. MarkLogic adds timestamps to documents so queries run only against the state of documents when the query started. If an update happens to the document while a query is running the query doesn't see that newest version - it's still looking at what was most recent when the query started.


Much like you would keep a personal journal to remember what happened throughout your day, MarkLogic keeps a journal of updates. The journaling happens before changes are committed. If the system fails, transactions can be rebuilt by looking at the journal.

Commit Process

MarkLogic has a commit process that happens at the end of a transaction. MarkLogic ensures that the entire transaction succeeds or fails, even when the data is stored across multiple hosts.

Need a Hit of ACID?

If you think your application needs both a NoSQL database and ACID compliance, give us a call. We can talk through how MarkLogic might just be the solution you are looking for.

Elijah Bernstein-Cooper

About Author Elijah Bernstein-Cooper

Elijah Bernstein-Cooper is a former solutions consultant with Omni. He developed applications with MarkLogic. Prior to Omni, Elijah received his masters in astrophysics at the University of Wisconsin-Madison where he expanded his repertoire in data science. Elijah’s background in astrophysical data science complemented with NoSQL development allows him to provide fresh solutions for businesses’ challenges in data governance and analysis.


Omni’s blog is intended for informational purposes only. Any views or opinions expressed on this site belong to the authors, and do not represent those held by people or organizations with which Omni is affiliated, unless explicitly stated.

Although we try to the best of our ability to make sure the content of this blog is original, accurate and up-to-date, we make no claims of complete accuracy or completeness of the information on this site/s to which we link. Omni is not liable for any unintended errors or omissions, or for any losses, injuries, or damages from the display or use of this information. We encourage readers to conduct additional research before making decisions based on the information in this blog.