10 years and a few months ago I started a new job working on a website with an extremely normalized MySQL database. Prior to this, I'd never written a query with a single JOIN, let alone the query gymnastics happening in this code base.
I initially hated the way the DB was designed—that there was no ORM. I was a far more green developer than I realized at the time. But I was committed to the project, so I buckled down and tried to learn SQL. I read about relational algebra and about set theory. Eventually I was able to wrap my head around the data model. The more I understood the model the more beautiful it became. It mapped to peculiarities of the real world domain in ways that I previously didn't even know existed.
I've long since moved on from that project, but the love of well-designed relational databases stuck. I've used Redis, DynamoDB, Elasticsearch, et al in plenty of projects too—they have their place. But never has a key/value store inspired the kind of mathematical reverence as I had when I finally grokked JOINs. Or UNIONs. Or CTEs. Or window functions. And never has a NoSQL data store been as remarkably flexible as something like PostgreSQL or MySQL. Systems like DynamoDB requiring predicting exactly what your query patterns will be and baking that into the schema. With a relational DB, though, you can explore. You can join, filter, sort by, and group by any column. It's the ultimate admission that we don't know what the future holds; the ultimate agility. I have no idea what report the business will request tomorrow. But, I have absolutely no doubt that I can write a query, paste it into Graphana, and answer their question. Is the answer correct and up to date? Yes, because there is no ETL process involved to could fail or lag. It's just querying the actual canonical application data.
I have no real point in writing this besides saying, if you don't already know anything about set theory, you should learn. If you've only ever used an ORM, write some SQL. Then learn the basics of the math behind it. Learn about levels of normalization. Challenge yourself by asking your data questions that you hadn't thought about when you modeled it. Before you know it, you'll be astounded at the things you can do.