NoSQL: The Hangover of Dropping ACID

Created by Stable Diffusion

The 70s were a time of excess and rebellion, a carefree era where people embraced their wildest impulses and let their hair down. But as the years went by, people realized that the true freedom lies not in the absence of rules, but in the discipline to follow them. And so, they put away their acid-washed jeans and neon-colored hair, and embraced a more structured, disciplined way of life.

As we hit 2010, the 70s spirit of rebellion spawned a new breed of databases known as "NoSQL". The rise of NoSQL databases was a rebellion against the strict rules and constraints of SQL databases. NoSQL databases promised to free users from the rigid, structured world of SQL, with their strict schemas and complex query languages. Instead, NoSQL databases offered a simple, flexible approach to data storage and retrieval, allowing users to store and access data in whatever way they saw fit.

In contrast to SQL databases, which provide strong consistency guarantees through ACID transactions, NoSQL databases dropped ACID and offered eventual consistency. This meant that updates to the database would not be immediately visible to all clients. Instead, updates would be propagated to all nodes in the database eventually, typically within a few milliseconds to a few seconds.

While eventual consistency was useful in some scenarios, such as when dealing with large, distributed datasets, it also created problems. It introduced a range of corner cases, where the data returned by a query may not reflect the latest updates to the database. This led to inconsistencies and confusion. Dealing with eventual consistency often required developers to write complex and error-prone code to handle these corner cases. This code was typically ad-hoc and difficult to maintain, and it easily broke when the database is updated or reconfigured. As a result, developers often found themselves spending more and more time patching and fixing the seams in their code, rather than focusing on the core functionality of the application.

Moreover, without the constraints of a schema or a query language, data quickly became chaotic and disorganized, leading to a lack of consistency and reliability. The lack of structure made it difficult to perform complex queries or to integrate data from multiple sources.

As with the 70s, the wild, carefree days of NoSQL eventually came to an end. People began to realize that the freedom offered by NoSQL databases was not all it was cracked up to be. And so, like the 70s, the NoSQL era came to an end, and people returned to the structured world of SQL databases.

However, just as the 70s contributed some good things to our culture and understanding, the NoSQL era also contributed valuable lessons and techniques about scalability. The flexibility and scalability of NoSQL databases allowed developers to tackle large, distributed datasets in ways that were not possible with SQL databases. And while the eventual consistency of NoSQL databases was problematic, it also forced developers to think more carefully about data management and concurrency control.

In conclusion, like the wild carefree 70s, we outgrew the carefree everything NoSQL days. But just as the 70s contributed valuable lessons and insights, the NoSQL era also contributed valuable understanding and techniques about scalability. And just as the structured, disciplined world of today is better suited to our needs, the structured, disciplined world of SQL databases is also better suited to the needs of modern software development.

(Hey, don't shoot the messenger. ChatGPT wrote the above, I was involved only editorially.)