Thirdly, we have to consider the speed and scalability of the solution. I know I said two separate items there, but they're extremely related. How fast does your application need to be? How quickly does the data come into the database and how high is the throughput? Basically, are you expecting a spike in the number of users? Is there going to be a rush minute, a rush time? Or maybe it's just gonna be a steady-state where people are riding continuously all evening, all night, it's just an automated process or just an around-the-clock slow rate.

NoSQL databases tend to excel in terms of performance and scalability, and that can be considered when processing large volumes of data, especially when it's unstructured, but SQL solutions excel when there's a lot of joins and that that needs to be the primary focus. One final note I'll say about all of this. For smaller data sets, particularly when you're only in a couple of thousands of rows, speed is not as big of a fear point as some people might fear it is.

Speed and scalability only really start to matter as your data set gets bigger and bigger, or you get more and more users. Don't be afraid of speed and scalability concerns if your data is relatively small or it's a relatively small team without insane requirements. Just know and be aware of as your data gets bigger and more complex and your team grows and prospers, this is where you need to focus more.

So to tie it back to our fantastic coffee bean delivery service that's building a new customer support dashboard, we're typically expecting that people are gonna be submitting requests. There's really going to be no more than six users at a time, we anticipate. This is either people entering new complaints or people responding to complaints or people viewing the dashboard. And as this isn't a business-critical, need to know within a millisecond of a complaint coming in, a one to two second response time is going to be acceptable for our application.