Transactional ACID-compliant database

The Atomicity, Consistency, Isolation, Durability (ACID) of transactions ensure that your data will not be corrupt. Neo4j prides itself in being an ACID-compliant database. To explain this further, it's probably useful to go back to what ACID really means, apart from that your data stays surprise-less. Basically, the acronym is one of the oldest summaries of the four goals that many database management systems strive for, and they are shown in the following figure:

• Atomicity: This means that changes in the database must follow an all
  or nothing rule. Transactions are said to be atomic if when one part of the transaction fails, the consequence is that the entire transaction is rolled back.
• Consistency: This means that only consistent or valid data will be allowed to be entered into the database. In relational terminology, this often means that the schema of the database has to be applied and maintained at all times. The main consistency requirement in Neo4j is actually that the graph relationships must have a start and an end node. Relationships cannot be dangling. Aside from this, however, the consistency rules in Neo4j will obviously be much looser, as Neo4j implements the concept of an optional schema.

• Isolation: This requires that multiple transactions that are executed in parallel on the same database instance do not impact each other. The transactions need to take their due course, irrespective of what is happening in the system at the same time. One of the important ways that this is used is in the example where one transaction is writing to the database and another is reading from it. In an isolated database, the read transaction cannot know about the write that is occurring next to it until the transaction of the write operation is complete and fully committed. As long as the write operation is not committed, the read operation will have to work with the old data.
• Durability: This basically means that committed transactions cannot just disappear and be lost. Persisted storage and transaction commit logs that are forced to be written to disk--even when the actual data structures have not been updated yet--ensure this quality in most database systems, and also in Neo4j.

The summary of all this is probably that Neo4j has really been designed, from the ground up, to be a truly multipurpose database-style solution. It shares many of the qualities of a traditional relational database management system that we know today; it just uses a radically different data model that is well-suited for densely connected use cases.