Your Database Is Choosing Your Architecture
If there is one decision that shapes the future of a system more than any other, it is the choice of the data layer.
Ask most engineers where the architecture begins, and many will point to the application. They will talk about APIs, containers, deployment pipelines, or Kubernetes clusters. Those components are visible, easy to discuss, and often receive most of the attention during design meetings.
Experienced architects usually look somewhere else.
They look at the database.
Not because databases are more interesting than applications, but because they are far less forgiving. Applications can be rewritten, containers can be replaced, APIs can evolve, and cloud services can be migrated. Data, however, has a remarkable tendency to stay exactly where it was first placed. Once terabytes or petabytes of business information accumulate inside a platform, moving them becomes one of the most expensive engineering projects a company will ever undertake.
This is why architects often say that applications are temporary, but data is forever.
It is, of course, an exaggeration. Yet like many engineering jokes, it contains an uncomfortable amount of truth.
The First Mistake Happens Before the First Table Is Created
One of the most common questions in cloud projects sounds perfectly reasonable.
“Which database should we use?”
Unfortunately, it is the wrong question.
Choosing a database before understanding the nature of the data is like choosing the size of a warehouse before knowing what will be stored inside it. A warehouse designed for furniture makes little sense if the business sells frozen food.
The same applies to cloud databases.
Different storage technologies solve different problems because data itself behaves in fundamentally different ways.
Some data changes thousands of times every second.
Some data is written once and never modified again.
Some must be available globally within milliseconds.
Some can wait several hours before anyone looks at it.
Some represents financial transactions where losing a single record is unacceptable.
Some consists of anonymous analytical events where occasional delays have almost no business impact.
Treating all these workloads as identical inevitably leads to poor architecture.
Data Has Personalities
Architects often classify applications.
A more useful habit is to classify data.
Imagine four completely different companies.
An online bank processes money transfers.
A retail chain analyzes customer purchases.
A video streaming platform stores user preferences.
A logistics company tracks the movement of delivery vehicles.
All of them use databases.
Yet almost nothing about their data is similar.
The bank cares about transactional consistency above everything else. Every operation must either complete successfully or not happen at all. There is no acceptable middle ground.
The retailer is interested in historical analysis. Managers want to compare this month with last year, analyze seasonal trends, identify successful campaigns, and forecast future demand.
The streaming platform focuses on rapid retrieval of relatively small pieces of information. User preferences, recommendations, watch history, and personalized settings must be available almost instantly.
The logistics company continuously receives location updates from thousands of vehicles. The challenge is no longer storing information but ingesting and processing large streams of events efficiently.
Notice something important.
These businesses are not choosing between databases.
They are choosing between completely different architectural philosophies.
The Transactional World
Transactional systems are designed around one simple promise.
When the application says that something happened, it really happened.
If a customer transfers one hundred dollars, there must never be a moment when the money disappears from one account but has not yet appeared in another.
This requirement sounds obvious.
Implementing it at scale is remarkably difficult.
Transactional databases invest enormous effort into maintaining consistency. Locks, transactions, isolation levels, recovery logs, replication protocols—all exist to preserve correctness even when hardware fails or thousands of users interact with the same data simultaneously.
These guarantees are expensive.
Every consistency guarantee reduces flexibility somewhere else.
This is why transactional databases usually prioritize correctness over analytical performance.
The Analytical World
Analytical systems ask completely different questions.
Nobody wants to know the balance of one customer.
They want to analyze five years of purchasing behavior across twenty million customers.
Instead of updating individual records thousands of times per second, analytical platforms read enormous volumes of historical information and aggregate it in useful ways.
This difference changes everything.
Storage layouts become different.
Compression strategies become different.
Query optimizers become different.
Even pricing models become different.
This explains why services such as BigQuery behave so differently from transactional databases.
They were never trying to solve the same problem.
They were built for different conversations.
The Most Expensive Architecture Mistake
One of the most expensive mistakes in cloud projects is trying to force a single database to solve every problem.
A team discovers BigQuery and decides to use it for operational workloads.
Another team already has Cloud SQL and attempts to build enterprise analytics directly on top of it.
Both decisions usually end the same way.
The technology performs exactly as designed.
The architecture fails because the workload does not match the platform.
This is remarkably common because engineers naturally prefer reducing the number of technologies in a system.
In many areas this is good engineering.
In data architecture it can become an expensive shortcut.
Sometimes the simplest architecture is not the one with the fewest services.
It is the one where every service performs the job it was designed to perform.
One of the easiest ways to recognize an inexperienced architect is to ask a very simple question.
“Why did you choose this database?”
The answer often sounds something like this:
“Because we already use PostgreSQL.”
“Because BigQuery is fast.”
“Because Firestore scales automatically.”
“Because everyone recommends it.”
None of these answers is technically incorrect.
None of them explains the architectural decision.
An experienced architect almost never starts with the database itself. Instead, they begin by examining how information moves through the business.
Data is not static. It has a lifecycle. It is created, modified, analyzed, archived, and eventually deleted. Understanding that lifecycle is far more important than memorizing product names.
Once you understand how data behaves, the database almost chooses itself.
One Business, Multiple Databases
A common misconception in cloud projects is that every application should have one database.
In reality, most successful cloud systems use several.
This surprises many engineers because they associate multiple databases with unnecessary complexity. The opposite is often true.
Imagine a modern online retailer.
A customer opens the website.
Product information must load immediately.
The shopping cart must update instantly.
Payment processing must never lose a transaction.
Managers want sales reports every morning.
The marketing department wants to analyze customer behavior over the last two years.
The recommendation engine needs historical purchase patterns.
The finance department stores invoices for seven years.
Although this appears to be one application, it actually contains several completely different data workloads.
Trying to solve all of them with one database forces that database to perform tasks it was never designed to perform.
Good architecture accepts that different problems deserve different storage technologies.
Operational Data Lives in the Present
Consider what happens when a customer clicks the Buy Now button.
At that moment, several things occur almost simultaneously.
The application verifies inventory.
It reserves stock.
It creates an order.
It records payment information.
It updates customer history.
Every operation must either succeed together or fail together.
There is no room for partial success.
Imagine completing payment but never creating the order.
Or reducing inventory without charging the customer.
This is why transactional databases exist.
Their primary objective is correctness.
Everything else comes second.
Cloud SQL, AlloyDB and Spanner all belong to this world, although each approaches the problem differently.
Their job is not to answer complicated analytical questions.
Their job is to make sure today’s business operations happen correctly.
That distinction is critical.
Analytical Data Lives in the Past
Now imagine the CEO asking a completely different question.
“Which marketing campaigns generated the highest profit among customers aged between twenty-five and thirty-five who purchased at least three times during the last eighteen months?”
Notice how different this question is.
Nobody cares about one transaction anymore.
The goal is to analyze millions of them.
The database is no longer serving operational decisions.
It is supporting business decisions.
Analytical systems therefore optimize for reading enormous datasets efficiently.
They compress data differently.
They organize storage differently.
They execute queries differently.
This explains why BigQuery can process terabytes in seconds yet would be a poor choice for recording a customer’s payment.
It is solving an entirely different problem.
Why BigQuery Should Not Replace Your Database
One mistake appears surprisingly often in cloud migrations.
A team discovers BigQuery and becomes impressed by its performance.
Soon someone asks:
“If BigQuery is so powerful, why don’t we store everything there?”
It sounds logical.
Until the first customer tries to place an order.
BigQuery is exceptionally good at scanning large amounts of historical information.
It is not designed to support thousands of small transactional updates every second.
Imagine trying to run an airport using only satellite photographs.
The images are detailed.
They cover enormous areas.
They are excellent for strategic planning.
They are terrible for directing aircraft on the runway.
BigQuery plays a similar role.
It gives businesses extraordinary visibility into historical information.
It is not the operational heart of an application.
Why Cloud SQL Should Not Become Your Data Warehouse
The opposite mistake is equally common.
A company already uses PostgreSQL.
Managers request analytical dashboards.
The engineering team decides to build reports directly from the production database.
Initially everything works.
Reports are small.
Traffic is low.
The database easily handles both application traffic and reporting queries.
Then the business grows.
Reports become more complicated.
Analysts begin exploring larger time ranges.
Dashboards refresh every few minutes.
Suddenly the production database slows down.
Customers experience delays.
Orders take longer to process.
Nothing is technically broken.
The architecture simply forced one system to perform two completely different jobs.
Production databases should spend their time serving users.
Analytical databases should spend their time answering questions.
Mixing those responsibilities rarely ends well.
Data Wants to Flow
Perhaps the biggest mental shift for new cloud architects is understanding that modern systems are not built around databases.
They are built around data movement.
Information enters the system through operational databases.
Events are published.
Pipelines transform them.
Analytical platforms aggregate them.
Machine learning models consume them.
Dashboards visualize them.
Archive storage preserves them.
In other words, databases are no longer isolated islands.
They are stations along a continuous data journey.
This explains why cloud architecture increasingly focuses on pipelines rather than storage engines.
Moving data correctly has become just as important as storing it correctly.
The Architect’s Perspective
When experienced architects discuss databases, they rarely begin with product names.
Instead, they ask questions.
Is this data operational or analytical?
How often does it change?
How quickly must it be available?
Who consumes it?
How long will it be retained?
What happens if it becomes temporarily unavailable?
These questions sound deceptively simple.
Yet they determine almost every storage decision that follows.
Once these answers become clear, the technology usually becomes obvious.
Architect’s Notebook
The best database is rarely the most powerful one.
It is the database whose design assumptions match the behavior of your data.
Operational systems optimize for correctness.
Analytical systems optimize for insight.
Trying to make one system perform both jobs usually produces mediocre results in each.
A database is not selected because it is popular.
It is selected because it naturally supports the lifecycle of the information it stores.
Closing Thought
The first question an architect asks should never be:
“Which database should we use?”
It should be:
“What kind of data are we building the business around?”
Because once that answer is clear, the architecture begins to reveal itself.