Never underestimate the power of good marking for bad products. NoSQL was fun but SQL is here to stay.

Swizec's platform provides resources for developers, covering a diverse range of topics such as programming languages, web development frameworks, data visualization techniques, and software engineering best practices. Through tutorials, guides, and coding challenges, Swizec offers hands-on learning experiences and practical insights for developers at all skill levels. Readers can explore  technologies, industry trends, and software development methodologies to enhance their technical proficiency and advance their careers in the tech industry. Additionally, Swizec shares personal anecdotes, career advice, and productivity tips to inspire and motivate aspiring developers on their journey of continuous learning and professional growth.

swizec.com

SQL and relational databases remain fundamental for transactional data, despite the advances and popularity of NoSQL technologies over the past decades. Many NoSQL systems have either been removed, adapted to include SQL/natively support transactions, or are mainly used for caching and analytics. This demonstrates the enduring flexibility and utility of SQL, including new features like JSON support and vector databases, which relational databases have successfully integrated while maintaining ACID properties.

Why SQL is Forever

Relational databases adopt the best features

Learned something new? Read more Software Engineering Lessons from Production

The NoSQL hype-train was back when I was a student, and I never got why the hype was for. It looks and is cool, but for some cases only in my opinion. For all my projects I have done this far, never had I to use this kind of storage.
Maybe one day I will, I am clearly not closed to it, but the sole advantage of RDBMS is too great to ditch that. You have to think of it in advance, for sure. But that’s for the best: it shapes your whole dev and you don’t have (or mainly won’t have too much) to change your codebase based on code structure evolution. It happens obviously, but the path is clear and manageable most of the time.

NoSQL was a result of 3 things: 1) Cutting down costs by having devs maintaining the database instead of database admins, which was the norm for MSSQL and Oracle Databases. 2) Pushing the agile mindset to the database. 3) Mobile apps boom.
BTW number 1 along with the cloud boom resulted to a whole new field: devOps, but that’s a story for another time.
NoSQL created a lot of hype a decade ago and had a valid usecase for mobile apps that needed to easily sync offline data. There are way more solutions to that now.
IMHO there’s really only 1 database that can handle all workloads and that’s Postgres. It might require a few plugins, but it will do the job. From JSON to time-series data, vector, graphs…

Great survey-article. Relational databases are an invention that is not easy to substitute, with the exception of a few edge cases.

I don’t think the push to NoSql was about not learing Sql but not having a structure to maintain. I.e. when you can just add properties it’s much faster to iterate the data model than trying to get a meeting with the DBA to discuss when new columns can be delivered. NoSql was Dev’s hijacking ownership of the datamodel. Of course this leads to other issues but one can imagine in the beginning Devs were exited.

I’ve worked on projects where NoSQL seemed like the perfect fit at first, but as the data complexity grew, we ended up needing the structure and ACID guarantees that relational databases provide - it’s interesting to see how SQL has adapted to include features like JSON support while maintaining its core strengths 🤔.