Part 2 of 3: Relational Databases, the AI Era, and the Prediction That Keeps Not Coming True
Every few years, someone declares that relational databases are on the way out.
First it was NoSQL.
Then it was NewSQL.
Now it’s vector databases and AI native data platforms.
And every time, the prediction quietly fails to materialize.
Instead of losing ground, PostgreSQL and MySQL keep absorbing the capabilities that were supposed to replace them.
This is Part 2 of a series on leading database reliability in the managed services and AI era. Part 1 explored what managed services and AI actually changed about the job. This article looks at why the relational model continues to hold up, and what that means when you’re designing systems for AI workloads today.
The Pattern Behind Every “We Need a New Database” Decision
Here’s a pattern that’s familiar to anyone who’s inherited a mature architecture.
A queue gets added because queuing became important.
A search engine gets added because search became important.
A document store gets added for flexible metadata.
Now a vector database gets added because AI showed up.
On an architecture diagram, every addition looks modern.
In production, it usually looks different.
It looks like duplicated data, reconciliation jobs nobody wanted to maintain, and permissions that quietly drift out of sync six months later.
Adding a specialized system isn’t free simply because the system itself is good.
Every new datastore is another component that can fail independently, another security model to manage, another backup strategy, another monitoring pipeline, and another synchronization problem waiting to happen.
That’s one of the biggest reasons PostgreSQL and MySQL continue to absorb new capabilities instead of losing ground to specialized alternatives.
PostgreSQL now supports full text search, JSONB for semi structured data, geospatial extensions, and pgvector for embeddings and similarity search, all within the same transactional, ACID compliant engine where your business data already lives.
Before introducing a fifth specialized system, it’s worth asking a harder question.
Can the relational database you already operate, with the right extensions, solve this problem well enough while reducing operational complexity?
The answer isn’t always yes.
Some workloads genuinely benefit from a dedicated vector database or a purpose built search engine because the scale or query patterns demand it.
But a surprising number of specialized databases introduced over the past few years solved problems that a well configured relational database could already handle.
Teams adopted the new technology because it was new, not because they had actually reached PostgreSQL’s limits.
Where This Is Headed
If you talk to engineers responsible for large PostgreSQL and MySQL fleets, the long term direction looks surprisingly consistent.
Built in sharding and distributed architectures will continue to mature, drawing lessons from projects like Citus, CockroachDB, and YugabyteDB.
Get Archana Reddy’s stories in your inbox
Join Medium for free to get updates from this writer.
Storage and compute will become increasingly disaggregated, following the path already established by systems like Aurora.
The line between transactional and analytical workloads will continue to blur, allowing organizations to analyze recent operational data without maintaining separate warehouses or accepting ETL delays.
AI assisted administration is simply another step in that evolution.
Automatic index management.
Adaptive configuration.
Smarter workload balancing.
Eventually, natural language interfaces that generate SQL accurately enough for routine work.
None of those changes alter the relational model itself.
Tables remain.
SQL remains.
ACID guarantees remain.
What’s disappearing isn’t the relational database.
It’s the expectation that engineers need to manage every operational detail manually.
This is also where some AI native database marketing gets ahead of reality.
Many vendors present purpose built AI databases as the only viable way to combine vectors, unstructured data, and transactional workloads.
Some of that innovation is real.
Some of it is selling you another system to solve a problem your existing database can already solve with the right extensions.
The Practical Question Architecture Teams Should Ask
The mistake isn’t choosing PostgreSQL.
The mistake isn’t choosing a vector database.
The mistake is treating either decision as permanent.
Technology moves quickly enough that an architectural choice made three years ago deserves another look.
Maybe you introduced a specialized database because PostgreSQL genuinely lacked the capability you needed.
Maybe it doesn’t anymore.
Or maybe you’ve spent years maintaining workarounds for limitations that no longer exist.
The strongest engineering organizations aren’t the ones running the most exotic data stack.
They’re the ones that pause whenever a new requirement appears and ask one simple question.
Do we actually need another database?
Or do we need fifteen more minutes thinking about how to extend the one we already know how to operate, secure, and keep reliable?
Continue the series
Part 3: The Database Leader’s Playbook for the AI Era
