Archive

The Dulin Report

Browsable archive from the WordPress export.

2022

In most cases, there is no need for NoSQL Apr 18, 2022 TypeScript is a productivity problem in and of itself Apr 20, 2022 Best practices for building a microservice architecture Apr 25, 2022 Good idea fairy strikes when you least expect it May 2, 2022 If you haven’t done it already, get yourself a Raspberry Pi and install Linux on it May 9, 2022 Most terrifying professional artifact May 14, 2022 Peloton could monetize these ideas if they only listen May 15, 2022 Am I getting old or is it really ok now to trash your employer on social media? May 25, 2022 There is no such thing as one grand unified full-stack programming language May 27, 2022 Automation and coding tools for pet projects on the Apple hardware May 28, 2022 Java is no longer relevant May 29, 2022 Good developers can pick up new programming languages Jun 3, 2022 Scripting languages are tools for tying APIs together, not building complex systems Jun 8, 2022 Keep your caching simple and inexpensive Jun 12, 2022 All developers should know UNIX Jun 30, 2022 Monolithic repository vs a monolith Aug 23, 2022 Why don’t they tell you that in the instructions? Aug 31, 2022 Using GNU Make with JavaScript and Node.js to build AWS Lambda functions Sep 4, 2022 Stop Shakespearizing Sep 16, 2022 The Toxic Clique Sep 28, 2022 Book review: Clojure for the Brave and True Oct 2, 2022 Why you should question the “database per service” pattern Oct 5, 2022 Why I am a poll worker since 2020 Nov 11, 2022 If we stop feeding the monster, the monster will die Nov 20, 2022 Things to be Thankful for Nov 24, 2022 Working from home works as well as any distributed team Nov 25, 2022 Should today’s developers worry about AI code generators taking their jobs? Dec 11, 2022

In most cases, there is no need for NoSQL

April 18, 2022

Over the years, I learned the hard way that, with the exception of a few niche use cases, NoSQL databases such as AWS DynamoDB or Apache Cassandra are not always a good idea.



Here is why.



With a traditional SQL-based relational database, you design your data model to represent your business objects. Your queries can then evolve and can be ad-hoc. You can even create views, materialized or otherwise, to facilitate even more complex analytical queries.



DynamoDB does not offer the flexibility of traditional SQL. While your data model can evolve and you are not tied to a rigid schema, you have to design your data model around the queries you plan to run. 



The problem with that approach is that it is very rare for end-users to say with certainty what they want. Over time their needs change, and so do the queries they want to run. Changes to the storage model in DynamoDB involve running massive data reloads -- or complex code for backward compatibility.



Meanwhile, the ability to get to the application’s data, build reports, and run analytical queries is critical to the developer and business user productivity. It can mean a difference between delivering features in days vs. weeks.



Not all developers are created equal. SQL is a widely accepted and simple query language that business users should be capable of learning and using. Yet, many have trouble with even the most straightforward SQL. 



Introducing a whole new mechanism for querying their data, even if it is as mockingly similar to SQL as PartiQL, could be a problem. Traditional SQL databases have well-established libraries and toolsets. 



It is worth noting that DynamoDB now supports ACID transactions now as well. Still, I am here to argue that most enterprise application workloads will never reach the physical limitations of traditional RDBMS databases.




Conclusion




NoSQL technology is constantly evolving, as are traditional databases and managed cloud services. What I see happening is a convergence of functionality. There is a lot of cross-pollination of ideas going on in the industry, with NoSQL databases adopting some of the SQL functionality (think: PartiQL and SQL) and SQL databases adopting some of the NoSQL functionality (think: PostgreSQL NoSQL features). It is essential to keep a cool head and not jump on any new tech without understanding your use cases and skillsets.