You don't have to get very clever. Once you get beyond inner join it starts to stick out like a sore thumb that SQL isn't relational and that you should have chosen a relational engine instead. SQL shines when you have an ORM and need a reliable backing store, though. Tradeoffs, as always.

The only true relational database engine I’m aware of is Rel [0], which is a learning tool at best, not a production-capable DBMS.

I understand that SQL is pseudo-relational, but it’s as good as you’re going to get if you want something you can use for actual workloads.

0: https://reldb.org

Postgres was relational for the first decade of its life, until the infamous '95 release when it sold its soul to the devil. You could dig up on old version, perhaps. But, yes, the tradeoff for real-world use was already mentioned.

The relational model is superior as complexity grows (although arguably the deductive model is even better), but the tablational model is superior for simple line-of-business stuff, so pick your poison. Like with all things engineering, there is never one perfect solution that satisfies everything. If, like the earlier comment suggested, you keep your SQL simple then you'll be fine.