OLAP and batch analytics is just getting so much more common. Thinking back 30 years ago, column stores were rare and SQL was all about OLTP CRUD. It still does all that, but it's also become mainstream as the data science and analytics becomes ever more routine and approachable too.

And the dialects of the language itself, SQL keeps getting more relaxed and interoperable and forgiving. With WITH and CTEs and things it keeps getting easier and cleaner to express things, so it's going steadily in the right direction. There are still a few slight differences in the syntax for window functions between bigquery and duckdb, for an example I fight often, but they are all a lot closer to each other today than they used to be back 30 years ago when you had to use SQL differently and construct complicated queries differently just to run on Oracle vs MySQL vs Postgres.

The query languages that aren't SQL keep popping up and they're honestly nicer to read/write in application code in many contexts but none have the ecosystem/maturity or "every BI tool speaks it" advantage. Until there's a single non SQL language that runs efficiently everywhere from my laptop to the datacenter and every tool between SQL wins.

SQL forever? Maybe but please let me stop writing it as strings in my actual application code. Sqlc is a hope for me. It is almost like treating your DB as an RPC.

Frankly whenever people show me some "new SQL killer" it often looks like "SQL with extra steps". Sure, everyone is afraid of joins, but you can often engineer yourself further away from that. Document-oriented database systems are fine, but have downsides.

One of the main reasons I won't be dropping SQL unless I have to is schema. I *love* that data stored in SQL has an inherent schema. As anyone who has dealt with raw JSON will know, it can get pretty ugly when you make changes and either have to migrate everything, or complicate your parsing logic to handle corner cases. As long as I have a sane SQL schema, I can use migrations to make sure all data is in line with a single schema, and that makes reasoning and writing business logic easier. I have worked places where they haven't been as strict about schema as they probably should have been with DDB's and its ugly.

I like when my code is stupid simple because I am dumb and make tonnes of dumb mistakes. Having a database with a strict schema means it is simple to reason about. DDB may seem easy because you can just slap objects in a database, but you are actually just moving the complexity and schema job to YOU the developer. We all make stupid mistakes from time to time, so best to pick tools that makes our job easy, right?

I'm happy to replace SQL but I haven't found anything that gives me the qualities I want yet.