Almost every relational databases today and a few none relational databases support transactions…

Most follow the protocols that were introduced in 1975!

• IBM system R the first SQL database

Although some implementation details have changed, the general technical patterns here have remained the dame for over 40 years!

Systems that are similar to R, that have transaction support:

• MySQL
• PostSQL
• Oracle
• SQL Server

The rise of NoSQL databases

None relational NoSQL databases started gaining popularity in the late 2000s, as they were aimed to improve upon the relational database status quo. This was achieved by offering new choices of data models, and by including replication and partitioning by default.

The consequences of transactions

Transactions was the the primary causality of this movement towards NoSQL, as many of these new generation databases abandoned transactions entirely! Or, redefined the definition to describe a weaker set of guarantees that was previously understood.

Transactions being the antithesis of scalability

With the escalation of adoption of distributed databases, there merged a popular notion that transactions were the opposition of scalability…

And that any large-scale database system would have to redact transactions in order to maintain good performance and high availability. 🤷‍♂️

The misconception of “serious” and “valuable” data

Transactional guarantees are sometimes presented by database vendors as an essential requirement… for “serious” applications with “valuable” data.

The reality is, both view points are exaggerated as the truth is not that simple.

Like every other technical design choice… transactions have advantages and limitations!

In the upcoming posts I will explore the trade offs, that are required in order to support these guarantees, in both normal and extreme data-intensive environments.