scalability does not start with the database
Every community has its habits. Sets of technologies are often used together, what we call stacks.
Developers who came from the .NET world tend to be closer to SQL Server and Angular; whoever learned to program in JavaScript-focused bootcamps probably went through the famous MERN stack (MongoDB, Express, React, Node.js). That shapes how those people see the application as a whole, including the backend and especially the database.
Often this ends up creating a limited view of what is technically possible or desirable.
To someone who only knows silver bullets, every problem is a werewolf
Universities, in turn, being heavily focused on more established theory, end up teaching only what concerns relational databases. The difficulty of changing a curriculum, or even the limits of the professors' own knowledge, restricts what gets learned and creates tendencies and predispositions in many developers.
More senior professionals, on the other hand, end up seeing relational databases as outdated technology because they faced legacy projects full of bad practices. So when it comes to scaling a backend, many immediately think of abandoning relational databases and moving to NoSQL solutions, but we will talk about overengineering later on.
It is a common reaction, as if it were a ready-made formula. But the truth is that the choice of technology, and especially of the database, should come after understanding the problem and the context of the system. What looks modern or promising in theory is not always what works best in practice.
Many people think of the application as a simple "wrapper" around the database. That is not data driven.
In that scenario the business logic almost becomes a translator between the interface and the data, which makes architectural decisions harder and leaves little room for more powerful, reusable abstractions.
A disclaimer: it is fine if you just want to build an MVP or a small application without much expense, to validate an idea or start acquiring a few customers. But here we are talking about scalability, and if you are going through a rewrite or maintaining a system where scale is a requirement, the sooner you understand the tradeoff, the more money you are likely to save.
understanding databases: the impedance mismatch problem
Reading the book "NoSQL Distilled" I had an interesting insight about a problem I did not know had a name: the idea that relational databases bring with them a challenge called impedance mismatch. That complicated name describes a simple (and very common) situation: the fact that objects in code and records in the database do not "talk" to each other naturally.
You need a translation layer (like ORMs) that is not always efficient, and can end up creating more headaches.
The excessive use of mappers and the added complexity discourages many developers and tends to become a problem later if the system is heavily coupled and has side effects.
On the other hand, the use of NoSQL databases often comes from convenience or fashion, not from a careful analysis of the requirements. Designing systems around technologies rather than around problems and business rules can be harmful, making maintenance and new implementations harder, and often the only fix is a rewrite.
what actually matters: repertoire, culture and timing
What sets a senior team apart is not choosing the "best" technology, but knowing when and why to adopt it. Having technical repertoire and experience with different kinds of tools lets you discuss solutions with depth, rather than based on hype.
Scaling an application to millions of users demands that kind of technical maturity.
That is not learned overnight. It starts with a healthy development culture that values continuous learning, good engineering practices and considered decisions; that is software engineering.
It runs through understanding architecture concepts, testing strategies, CI/CD automation and, above all, avoiding excess: that impulse to build complex solutions for problems that do not exist yet, or just to put a new technology on your CV.
Please, dev, whether or not you went to university, your work rests on science. So let us do science.
the core of the system comes first
Before going out and choosing technologies, you need to understand and model the business rules properly. That means building a stable, clean core, independent of the tools around it. Only after that does it make sense to think about what we are going to "plug in": Redis, MongoDB, a RabbitMQ queue, or whatever else is needed.
When the application is well structured and there is budget for improvements, the team should have the freedom and the confidence to swap or introduce tools according to real need. And then you can talk about real scalability: the kind based on solid technical decisions rather than passing trends.
I will leave here a conversation I had a year ago with Cubos Academy that can serve as preparation for our next post, where we will start talking about software architecture.
See below: