The database world has been screaming “SQL is dying” since roughly 2009. MongoDB got popular, everyone panicked, and half the internet wrote obituaries for relational databases. That was sixteen years ago. SQL is still here. MySQL 8.4 dropped in April 2024. Oracle 23ai launched with vector search built in. PostgreSQL 17 came out in September 2024 and people were genuinely excited about it.
So no, SQL is not dying. But something is changing — and it’s worth actually understanding what, instead of just picking a side and shouting about it.
The honest version is this: SQL is losing ground in specific areas where it was never the best fit to begin with. And in those areas, unstructured databases are not just winning, they’re completely dominating. The question isn’t whether SQL will disappear. It won’t. The question is whether it will keep being the default choice for everything — and that part is already over.
The NoSQL Hype Cycle Did Real Damage
Back in 2010–2013, NoSQL was going to replace everything. MongoDB, Cassandra, CouchDB, Redis — all of them were framed as the death blow to relational databases. Companies rewrote perfectly good MySQL applications in MongoDB because it felt modern. A lot of them regretted it.
The joke at the time — and it was genuinely funny — was that “NoSQL” stood for “Not Only SQL” but everyone treated it like it meant “No SQL, ever.” Startups would drop tables and schemas and then spend the next two years building schema validation in their application layer anyway. Which is just reinventing the database, badly.
So when people ask if SQL is dying, there’s baggage there. There were years of bad-faith arguments, hype-driven migrations, and people who lost their jobs because some VP read a TechCrunch article about MongoDB and decided the whole stack needed to change.
That context matters. Because the current wave of “SQL is obsolete” talk — driven mostly by AI workloads and vector search and document stores — is both more legitimate AND more prone to the same overcorrection.
Where SQL Actually Loses
Here’s where the criticism of relational databases is fair. And it’s a real list.
Unstructured text and embeddings. If you’re building a product that does semantic search — like a chatbot that retrieves documents based on meaning, not keywords — SQL is the wrong tool. PostgreSQL with the pgvector extension can do it, and people use it at smaller scales. But Pinecone, Weaviate, and Qdrant are built specifically for vector similarity search and they’re faster and cheaper for that specific job. Trying to do vector search in MySQL is like trying to make pasta in a coffee maker. Technically possible, probably fine for once, not what you want at scale.
JSON-heavy workloads with constantly changing structure. If the data shape genuinely changes every week and you don’t know what fields will exist six months from now, MongoDB or DynamoDB or Firestore make your life easier. The schema flexibility is real. Document databases are better at storing semi-structured data where every record looks a little different.
High write throughput at massive scale. Cassandra was designed for the Cassandra problem — Facebook’s inbox, basically — which is write-heavy data at scale so extreme that no single machine can handle it. If you’re writing millions of events per second across multiple data centers, Cassandra wins. SQL databases can be distributed but it gets complicated fast.
Time-series data. InfluxDB, TimescaleDB (which is actually built on PostgreSQL, so this one is a bit cheating), and ClickHouse are optimized for time-stamped data in ways that MySQL and Oracle are not. Sensor data, metrics, logs — dedicated time-series databases are faster and cheaper for this.
That’s the real list. Not “AI is making SQL obsolete.” Four specific categories where NoSQL tools genuinely fit better.
Where SQL Is Not Losing At All
Financial systems. E-commerce. HR software. Healthcare records. Government databases. ERP systems. Pretty much any application where data integrity matters more than flexibility.
The ACID properties of relational databases — atomicity, consistency, isolation, durability — are not a marketing term. They mean that when you transfer money from one account to another, either both operations happen or neither does. This sounds obvious until you try to do it in a system that doesn’t guarantee it and you find out why it matters the hard way.
MongoDB added multi-document transactions in version 4.0, released in 2018. Which is good! But they added it because people were trying to use MongoDB for transactional workloads and running into problems. The fact that they had to build it in later is sort of the whole story.
There’s a reason banks still run Oracle. It’s not just legacy lock-in. It’s that Oracle’s durability guarantees and its recovery capabilities after a failure are things that most of their alternatives have been trying to catch up to for thirty years.
Oracle 23ai, by the way — that “ai” in the name is not just branding. They added native vector data types, a JSON relational duality view (which lets you query the same data as either JSON or relational tables), and built-in property graph queries. Oracle is not acting like a company that thinks SQL is dying. They’re adding every modern feature to SQL so you don’t have an excuse to leave.
The AI Workload Argument — More Complicated Than It Sounds
The current version of “SQL is dying” is mostly about AI. The argument goes: LLMs need vector embeddings, RAG pipelines need vector search, AI-native apps need document stores, so SQL is obsolete.
This is partially right and mostly wrong.
Vector search is a real thing. But most production AI applications don’t have a database that’s purely vector search. They have vector search for retrieval and a relational database for everything else — user accounts, billing, permissions, audit logs, application state. Supabase, which is basically PostgreSQL with a nicer API, added vector search via pgvector and became one of the most popular backends for AI apps in 2023 and 2024.
The pattern that actually emerged is: people use PostgreSQL as their primary database and add vector capabilities to it, rather than replacing PostgreSQL with a pure vector database. Pgvector crossed 1 billion downloads in early 2025 — that’s not a migration away from SQL, that’s SQL absorbing the new requirement.
So “AI is killing SQL” turned out to mean “AI is making people add pgvector to their existing PostgreSQL setup.” Which is, again, not really the death of SQL.
Where it genuinely threatens relational databases is in applications that are primarily AI workloads — retrieval-augmented generation systems at scale, recommendation engines, semantic search as the core product. Those do tend to use dedicated vector stores. But those are specific product categories, not “every application going forward.”
The Vector Database Boom of 2023–2024 — What Actually Happened
The VC money that went into vector databases in 2023 was genuinely wild. Pinecone raised $100 million in April 2023. Weaviate raised $50 million in December 2022. Chroma, Qdrant, Milvus — all of them got funded, all of them got press, and all of them were positioned as the database category that AI was going to need.
Some of that was real. Some of it was hype.
The actual adoption pattern turned out messier than the pitch decks suggested. A lot of companies that set up dedicated vector databases in 2023 found they were maintaining two separate data systems — one for their application data (still PostgreSQL or MySQL) and one for their embeddings (Pinecone or Weaviate). The operational burden of running two systems, paying for two things, syncing data between them — it added up.
So by late 2024, pgvector had become good enough that a lot of teams at the mid-scale level just stopped running a separate vector database. Not because Pinecone or Weaviate are bad — they’re not — but because eliminating one infrastructure dependency has real value. For a startup with two engineers managing the whole stack, cutting out an extra managed service matters.
The pure vector database companies are not going away. At the high end — large AI products doing billions of similarity searches, multi-modal embeddings, massive scale retrieval — dedicated vector infrastructure still makes sense. But the idea that vector databases were going to replace relational databases was never the actual play. They were always going to be a specialist layer that some applications need and others don’t.
The more interesting database story from 2024 was actually SingleStore and DuckDB. SingleStore is a distributed SQL database that added vector search while keeping full SQL support — basically, it’s trying to be the one database that handles both relational queries and vector workloads. DuckDB became almost cultishly popular among data engineers and analysts because it’s an in-process analytical database that runs fast enough on a laptop to replace a lot of what people were using Spark for. Both of them are relational databases. Both of them are growing fast.
The Developer Experience Factor Is Real
Here’s something the SQL defenders don’t always acknowledge: SQL’s developer experience has not aged well for certain workflows. Writing raw SQL in 2025 feels like filling out a paper form when everyone else is using a touchscreen.
ORMs helped. But ORMs also introduced a whole generation of developers who don’t know what their queries are actually doing, which caused a different set of problems. The n+1 query problem has been introduced into production systems by developers who thought they were “using the ORM correctly” way more times than it should have happened.
Prisma, Drizzle, SQLAlchemy — these are good tools. But if you’re doing simple CRUD and the data is naturally document-shaped (a product catalog, a content management system, user profiles with variable fields), MongoDB or Firestore genuinely does reduce boilerplate. That’s not hype, that’s just true.
The places where developers have voted with their feet away from SQL are mostly in rapid prototyping, early-stage startups, and consumer apps where the data model isn’t yet understood. Those are real scenarios. And Firebase, in particular, made it so easy to get a prototype running that entire communities of mobile developers skipped relational databases entirely.
But — and this is a big but — those same developers often hit scaling walls around 18 months into production and end up with a migration project they didn’t plan for. The “just use Firestore” advice has produced enough painful restructuring stories that it’s become something of a cautionary thing in startup circles.
The Skills Gap Problem Nobody Talks About
The “SQL is dying” narrative has a real cost that doesn’t get discussed much: it convinces junior developers not to learn SQL properly.
There are developers in 2025 who have been writing code professionally for three or four years who cannot write a JOIN. Not because they’re not smart — they’re perfectly capable developers — but because they started on Firebase or Supabase’s auto-generated APIs or Prisma, and they never needed to. The abstraction layer handled it.
That works right up until it doesn’t. It doesn’t when you’re trying to debug a slow query and you don’t understand what the ORM is generating. It doesn’t when you need to write a one-off data migration and your abstraction layer can’t do what you need. It doesn’t when you join a team that runs a large PostgreSQL database and they need you to write actual queries.
Stack Overflow’s 2024 developer survey showed SQL still in the top five most-used technologies, consistently, year after year. Not because companies are stuck in the past. Because SQL is how most companies still store and query most of their important data.
And on the hiring side — this is something worth knowing if you’re early in your career — data engineering and backend roles that specifically require strong SQL are not getting easier to fill. If anything, the proliferation of “just use an ORM” culture has made developers with genuine SQL skills harder to find, which makes them more valuable.
So while the debate about SQL vs NoSQL continues at the architectural level, there’s a practical reality underneath it: SQL knowledge is a career asset that has not depreciated. Probably the opposite.
MySQL vs Oracle vs PostgreSQL vs the Others
These three are not interchangeable, even though people treat them like they are.
MySQL is everywhere because WordPress is everywhere. The entire LAMP stack runs on it. It’s a good database. It’s not the most advanced relational database. Oracle acquired MySQL in 2009 when they bought Sun Microsystems, which made a lot of people nervous, but MySQL is still open source under the GPL license. MariaDB is the fork that happened because people didn’t trust Oracle, and it’s maintained independently.
Oracle Database is a different product in a different league for a different market. It’s expensive, it requires specialized knowledge to run well, and it’s genuinely powerful. The kinds of systems that run Oracle — large banks, airlines, insurance companies — are not migrating to MongoDB. That migration is not going to happen. The risk profile doesn’t make sense, the ACID requirements are too important, and the operational complexity of removing Oracle from a system that’s been running Oracle for twenty years is enormous.
PostgreSQL is the one that keeps winning the “what would you start a new project on today” argument. It’s open source, it’s got a great feature set, it handles JSON reasonably well, it has the vector extension, and in 2024 and 2025 it became the database of choice for a large portion of AI application backends. The PostgreSQL 17 release added incremental backup support and parallelization improvements that made it noticeably better for analytics workloads that used to require a separate data warehouse.
None of these three are dying. MySQL might lose mindshare slowly to PostgreSQL among developers who have a choice. Oracle will keep running enterprise systems for decades. PostgreSQL is gaining on both.
The Actual Future: Coexistence, Not Replacement
Here’s the thing — the database landscape has never been winner-take-all. In the 1990s, Oracle and SQL Server and IBM DB2 all existed at the same time. In the 2000s, MySQL joined them. In the 2010s, MongoDB, Cassandra, Redis, Elasticsearch, DynamoDB, and a dozen others joined. All of them are still running in production somewhere right now.
What actually happens is: the category expands and SQL’s share of new projects decreases in specific domains while staying flat or growing in others.
The percentage of new mobile apps starting on Firebase instead of MySQL is high and will probably stay high. The percentage of AI-native applications using a vector database as their primary store is growing. The percentage of financial systems, healthcare applications, and government databases switching away from relational databases is basically zero.
That’s not “SQL is dying.” That’s “the universe of databases got bigger.”
The more honest thing to say is that SQL as the default for everything is over. In 2000, if you were building anything with data, you probably reached for a relational database first without thinking about it. That reflex is gone. Developers now have to make an actual choice. And sometimes they choose something else.
But “developers now have real alternatives” is very different from “SQL is dying.”
One More Thing: SQL the Language Isn’t Going Anywhere
Even if relational databases somehow lost the market — which they won’t — SQL as a query language would survive. Because SQL-like query languages have been grafted onto nearly every data system that matters.
Spark SQL lets you query distributed datasets. BigQuery is SQL. Snowflake is SQL. Athena is SQL. ClickHouse uses SQL. Even MongoDB added SQL support via their Atlas Data Federation feature. The Apache Kafka SQL layer, ksqlDB, is literally called SQL in the name.
When NoSQL databases got popular enough that people actually needed to query them at scale, they built SQL interfaces for them. That’s either deeply ironic or the highest possible compliment, depending on how you look at it.
The language itself is fifty years old — the original paper from E.F. Codd at IBM came out in 1970. It’s had a longer run than most programming languages and it’s still the lingua franca of data work. Data engineers learn SQL. Data analysts learn SQL. Business intelligence tools generate SQL. Every data science course on the planet includes a SQL module.
SQL is not going anywhere. The only question is which engine is running underneath it.
So Is SQL Dying?
No. It’s adapting.
The relational model is not optimal for every problem. It never was. The databases being built today for vector search, for time-series, for graph traversal — these fill real gaps that SQL databases were always a bit clunky at. They’re not replacing SQL, they’re handling the cases where SQL was always the wrong answer and people used it anyway because there wasn’t a better option.
What’s actually happening is that SQL is settling into the things it’s genuinely best at — transactional data, complex relational queries, data integrity requirements, analytics — while other database types handle the rest. That’s not a midlife crisis ending badly. That’s just specialization.
The “SQL is dead” cycle repeats roughly every three to four years with a new challenger as the supposed killer. It was MongoDB in 2010. Cassandra in 2013. Firebase in 2016. DynamoDB in 2018. And now vector databases in 2023. Each time, SQL absorbed what was useful, the hype cooled, and the market settled into a more complicated picture than the original death announcement suggested.
The people declaring SQL dead are mostly selling something. The people saying SQL will never change are not paying attention. SQL is a fifty-year-old technology that is still actively developed, still widely deployed, and still the right choice for a large percentage of the applications being built today.
Just not all of them. Not anymore.