114 MySQL Today and Tomorrow — Why Relational Data Still Matters

The Technologies That Built the Web

MySQL helped teach the web how to remember.

For more than three decades, relational databases have stored the articles we read, the products we buy, the accounts we create, the orders we place, and enormous amounts of the information behind websites and applications.

But today's technology landscape looks very different from the web of the 1990s.

We now hear about cloud databases, NoSQL, distributed data, JSON documents, data lakes, vector databases, machine learning, and artificial intelligence.

With so many new ways to store information, it is reasonable to ask:

Does a traditional relational database such as MySQL still matter?

Very much so.

The Basic Problem Has Not Changed

Technology changes rapidly, but many of the problems databases solve have remained remarkably consistent.

A business still needs to know who its customers are.

A store still needs to know what products it sells.

A website still needs to know which article someone requested.

An organization still needs to maintain events, members, transactions, documents, categories, and relationships between them.

This kind of structured information is exactly where relational databases excel.

Relationships Are Everywhere

The word relational is important.

Real information rarely exists in isolation.

A customer has orders.

An order contains products.

An article belongs to a category.

An event has attendees.

A photograph may belong to a project.

A user may have permissions.

A town may belong to a county.

Relational databases provide a disciplined way to represent these connections without unnecessarily duplicating information.

That idea remains just as valuable today as it was decades ago.

SQL Has Remarkable Staying Power

SQL is another technology that has survived repeated predictions that something newer would replace it.

There is a reason.

SQL provides a powerful way to ask questions about structured information.

A relatively short query can filter thousands or millions of records, connect information from several tables, calculate totals, sort results, group information, and return exactly what an application needs.

SQL is also declarative.

Instead of describing every individual step the computer must take, the developer largely describes the result that is wanted.

The database determines how to retrieve it efficiently.

That is an extraordinarily useful idea.

Modern MySQL

Today's MySQL is far more sophisticated than the database that appeared in the mid-1990s.

Modern versions include advanced transaction support, sophisticated indexing, replication, improved security, JSON capabilities, window functions, common table expressions, geographic data support, performance monitoring, encryption features, and tools for managing increasingly demanding applications.

The InnoDB storage engine provides the transactional foundation for modern MySQL installations.

MySQL can still serve a relatively small website.

But it can also participate in much larger architectures.

The Database Does Not Have to Live Beside the Website

For many years, a classic web server might run Linux, Apache, MySQL, and PHP together.

That arrangement can still work very well.

But modern systems provide many more possibilities.

The web server and database can run on different machines. Multiple application servers can connect to a database. Read replicas can distribute workloads. Databases can operate inside virtualized environments or cloud infrastructure.

Organizations can also use managed database services where much of the underlying infrastructure, maintenance, backup, and availability work is handled by a cloud provider.

The architecture has become more flexible while the fundamental database concepts remain familiar.

MySQL and MariaDB

MySQL's history also gave us MariaDB.

Because MariaDB began as a fork of MySQL, the two systems share a great deal of history and compatibility.

For many traditional PHP applications, they can appear very similar.

But they should no longer be thought of as identical products.

Years of independent development have produced differences in features, implementation, optimization, release schedules, and compatibility.

That means choosing between them—or moving an existing application from one to the other—deserves the same careful evaluation we should give any important infrastructure decision.

Then Came NoSQL

As internet applications grew to extraordinary scales, another family of databases became increasingly prominent.

They were often grouped under the term NoSQL.

Some store documents. Some use key-value pairs. Some are designed around graphs. Some distribute enormous datasets across many machines.

NoSQL databases can be excellent solutions when information does not fit naturally into traditional tables or when an application has specialized scaling requirements.

For a time, discussions about NoSQL sometimes sounded as though relational databases were becoming obsolete.

That did not happen.

Different Tools Solve Different Problems

A document database does not make a relational database obsolete any more than a screwdriver makes a wrench obsolete.

They solve different problems.

If an application manages strongly structured information with meaningful relationships and requires reliable transactions, a relational database may be exactly the right tool.

If an application manages enormous quantities of irregular documents, graph relationships, temporary cached information, or other specialized data, another database model may make more sense.

Modern systems can use more than one type of database.

The goal is not to choose the fashionable technology.

The goal is to choose the appropriate technology.

MySQL Learned to Handle Less Structured Data Too

The boundary is not always as clear as relational versus non-relational.

Modern MySQL can store and work with JSON data.

This allows an application to combine traditional relational structure with more flexible document-like information when appropriate.

That does not mean everything should be placed into JSON.

One of the great strengths of relational databases is their structure.

But having both approaches available gives developers additional flexibility.

Good Database Design Still Matters

Computers have become dramatically faster.

Storage has become dramatically cheaper.

Neither development eliminates the value of good database design.

A poorly designed database can contain duplicated information, inconsistent values, confusing relationships, slow queries, and data that becomes increasingly difficult to maintain.

A thoughtfully designed database can remain understandable and useful for decades.

This is especially important because data often outlives the software that originally created it.

A website design may be replaced several times while the information behind it continues.

The Data May Be More Valuable Than the Application

This leads to an important principle.

The application can be rebuilt. The data may be irreplaceable.

Code can often be rewritten.

A server can be replaced.

A website design can be recreated.

But decades of customer records, articles, research, transactions, photographs, measurements, membership information, or organizational history may be impossible to reconstruct once lost.

That makes protecting the database one of the most important responsibilities in operating an information system.

Backups Are Part of the Database

A database should never be thought of as only the live copy.

A dependable database strategy includes backups.

Those backups should be created regularly, protected appropriately, and ideally stored separately from the system they protect.

And a backup has limited value if no one knows whether it can actually be restored.

The real question is not simply:

“Do we have a backup?”

It is:

“Could we recover if this system disappeared today?”

Database Security Is Layered Security

Databases frequently contain some of an organization's most valuable information.

That makes security essential.

Applications should use accounts with only the permissions they actually require.

Database servers should not be unnecessarily exposed to the public internet.

Software should be maintained and updated.

Passwords and credentials should be protected.

Applications should use prepared statements or equivalent safe database interfaces rather than constructing dangerous queries directly from visitor input.

Sensitive information should receive protection appropriate to its value and risk.

Logs and monitoring can help identify unusual activity.

And backups themselves must be protected because a database backup can contain the same sensitive information as the live database.

Once again we arrive at the principle from our Digital Life Security Series:

Security is not one setting. It is a system of layers.

Prepared Statements Changed an Important Habit

One particularly important improvement in database programming has been the widespread adoption of prepared statements.

Older applications sometimes constructed SQL by combining commands directly with information supplied by a visitor.

That could allow malicious input to change the meaning of the database command—a vulnerability known as SQL injection.

Prepared statements separate the structure of the SQL command from the values being supplied to it.

That distinction is fundamental.

Data should remain data.

It should not unexpectedly become an instruction.

Performance Is Often About Asking Better Questions

When a database becomes slow, buying a faster server is not always the best first solution.

A poorly designed query can force a database to examine enormous amounts of unnecessary information.

A missing index can turn a quick lookup into a large search.

An application can repeatedly request information it already has.

Database performance therefore involves understanding both the data and how the application uses it.

Indexes, query design, caching, database structure, memory, storage, and server configuration can all matter.

Often the fastest query is simply the one that avoids unnecessary work.

The Cloud Changed Where MySQL Runs

Cloud computing has changed database infrastructure considerably.

An organization no longer necessarily needs to install and maintain MySQL directly on its own physical server.

Managed services can automate backups, replication, software maintenance, monitoring, and recovery features.

That can be extremely useful.

But moving a database into the cloud does not eliminate responsibility.

Someone still needs to understand permissions, security, backups, costs, performance, data retention, and what happens if something fails.

Convenience changes the work.

It does not eliminate the need to understand the system.

Then Artificial Intelligence Arrived

Artificial intelligence introduces another interesting chapter in the database story.

AI systems need data.

Often, enormous amounts of it.

That makes databases more important, not less.

AI can also help people work with databases.

A person can increasingly describe the information they want in ordinary language and have an AI system help construct a SQL query.

AI can help explain complex queries, suggest indexes, examine database structures, document tables, identify potential problems, and assist developers in modernizing older database code.

This may make sophisticated data analysis accessible to many more people.

But AI Can Write a Bad Query Too

The same caution that applies to AI-generated PHP applies to SQL.

A query can look convincing and still be wrong.

It may return incorrect information.

It may unintentionally update too many records.

It may expose information a user should not see.

It may perform efficiently on ten records and terribly on ten million.

AI can help create the query.

A knowledgeable person still needs to understand what the query will do.

AI Makes Data Quality Even More Important

Artificial intelligence also reinforces an old computing lesson:

The quality of the output depends heavily on the quality of the information behind it.

If a database contains duplicate, outdated, incorrectly categorized, or inconsistent information, adding AI does not magically repair the underlying problem.

In fact, AI may make clean, well-organized information even more valuable.

An organization that has carefully maintained its data for years may possess something increasingly important: structured institutional knowledge.

Relational Data and Vector Data

AI has also increased interest in vector databases and vector search.

These systems can represent information mathematically in ways that help find items based on similarity or meaning rather than only exact matches.

That can be extremely useful for AI applications.

But vector search does not eliminate relational information.

An AI system may use vector search to find documents related to a question while still relying on relational data for users, permissions, dates, products, transactions, categories, and other structured information.

The future may not be one database replacing another.

It may be several forms of data storage working together.

Could We Eventually Talk to the Database?

One of the most interesting possibilities is that people may increasingly interact with databases without knowing SQL.

Instead of writing:

SELECT ... FROM ... WHERE ...

a person might simply ask:

“Show me the products added during the last year that have not sold in the past six months.”

An AI layer could translate that request into SQL, verify the database structure, execute an appropriate query, and explain the results.

SQL would still be there.

It might simply become less visible.

The Technology Can Become Invisible Without Becoming Unimportant

This may be one of the larger themes emerging from The Technologies That Built the Web.

As technology improves, foundational technologies often disappear from the user's view.

Most people using a website do not know whether PHP generated the page.

They do not know whether MySQL retrieved the information.

They do not know which web server delivered it.

They simply expect the page to work.

Artificial intelligence may push that abstraction another layer higher.

But invisible infrastructure is still infrastructure.

MySQL Tomorrow

Will every application twenty years from now use MySQL?

Of course not.

There will be new databases, new architectures, new ways to distribute information, and new requirements we cannot yet anticipate.

But the fundamental problems MySQL solves are not disappearing.

Information still needs to be stored.

Relationships still matter.

Transactions still need to be reliable.

Data still needs to be searched.

Permissions still need to be enforced.

Backups still need to work.

And applications still need dependable information.

The Database Behind the Future

MySQL began during the early days of the commercial web and became one of the technologies that allowed dynamic websites to flourish.

Today it operates in a world of cloud computing, APIs, mobile applications, enormous datasets, and artificial intelligence.

The surroundings have changed dramatically.

The core mission remains surprisingly familiar.

Store information reliably. Protect it. Organize it. Connect it. Return it when it is needed.

That was valuable in 1995.

It is valuable today.

And it is difficult to imagine a future in which it will not be valuable.

Next: The Web Server

We have now looked at two technologies working behind many dynamic websites.

PHP provides the logic.

MySQL provides the memory.

But something has to receive the visitor's request in the first place.

Something must listen for connections, locate resources, communicate with PHP, and send the resulting page back across the internet.

That brings us to another technology that quietly helped build the web:

The web server.

Next in The Technologies That Built the Web, we will explore the history of web servers and Apache—from the earliest HTTP servers to the open-source software that became one of the foundations of the World Wide Web.