NoSQL databases often make tradeoffs by relaxing some of the ACID properties of relational databases for a more flexible data model that can scale horizontally. This makes NoSQL databases an excellent choice for high throughput, low-latency use cases that need to scale horizontally beyond the limitations of a single instance.
Users suffer when the development process fails to acknowledge traffic growth until brought too light as a real problem. A large portion of industry lacks the means of true observability into this altogether. A problem that can somewhat be eradicated by considering scale from the start and using modern tools to facilitate it more easily so users aren’t left holding the bag. Many scaling and performance problems are not simple to solve once the app has been built and is in production use. This is especially true for older legacy platforms like monolithic cms. Instead of actually solving the problems and changing the architecture bandaids on top of band aids like caching are implemented that make the software more and more complex and get in the way of development. The inherit scalability, availability, flexibility of NoSQL solutions have a significant role to play in building architectures robust enough to scale to accommodate any traffic needs without a whole bunch of bandaids on top.
There are also some none json solutions in this realm as well. If you want to stick with a relational data model with tables Cassandra is a highly available, scalable alternative to traditional relational databases.
With that in mind traditional databases are one of the most expensive things to change. The more applications that rely on a database the more difficult it will be to modify the existing structure without needing to update the other apps in the process. Many times organizations with large databases don’t even have an understanding of all the apps that might be using a single database. Much of the time the people who manage the database don’t even know what apps are being used nor the business logic necessary to maintain workflow integrity. On the other end a team might modify the database with unintended consequences for another team that they are unaware of. I would diagree that its never to early to optimize data storage and consider future data and traffic needs. The same rules about premature optimization in app code are not as relevant to the data model. Its important to have a flexible robust scalable data model in the first place otherwise you will likely need to rewrite the app, implement bandaids, undergo large and expensive migration process full of risks as needs grow.
Blockchain is a solution looking for a problem, and a poor one at that.
All these “old” techniques exist for a reason, and all the new ones do to. I’m all in favor of new stuff, but not in favor of abandoning everything to go to new stuff because it’s new. And I’m especially not in favor of recommending only new things to people who are just starting out. Things that have been around longer have more information online, more fleshed out documentation, more people to ask questions about them, etc. Which is precisely what you want when you’re starting out.
There’s nuance and tradeoffs all around. Sometimes and old tool simply is best for the job, because it’s been doing it for ages without problem and all initial problems have been fixed. Which is always the question what you encounter when you jump on the bandwagon of a new shiny thing.
I’m not saying here that one should never use new techniques. I’m saying you should consider the problem at hand and see which solution fits best instead of always using a hammer because everything looks like a nail.
Many NoSQL technologies have been around for over a decade including Mongo and CDNs. They just appear “new” so to those who have not embraced anything new in the past decade.
Funny you mention that because that is what applying a relational database or monolithic cms, php framework to every problem is. Using the same tool over and over not considering, researching more viable tools in the modern space.
New comers can capitalize marketability embracing modern technologies that legacy developers are unfamiliar and reluctant to learn. The cool new projects are being built with modern solutions not age old legacy technology. This includes a heavy dose of alternative legacy database solutions and the cloud.
Relational databases have been around since the 60s or so. In that sense NoSQL is still new.
Agreed. That shouldn’t be done either.
I think most people are because they already landed a PHP job and need some guidance on how to do things. Sure, it’s good for them to broaden their horizon, but migrating an existing system to a new technology is usually a really hard sell to management, mostly because there are no tangible benefits to them and because full rewrites pose a pretty huge risk.
But indeed, it might be interesting for them to see new stuff, play around with it and maybe land a different job next time. No argument here.