Fellow lion pit enjoyer here. We also use SQL for our product to deal with all the client customization needs. This has been our path for about 4 years now and

Fellow lion pit enjoyer here. We also use SQL for our product to deal with all the client customization needs. This has been our path for about 4 years now and we still haven't found a better option for our business. If you build a SQL schema and involve the business stakeholders in that process, you end up with something everyone can understand & work with. The difficulty of writing SQL scales in direct proportion with the complexity of the schema/domain. If the schema is something that is fundamentally familiar to your team, then you already have 80% of the "language" trained into your employees. At this point, showing them a few examples is all they usually need to "get it" and start doing things on their own. Inevitably, you will run into "how do I write a query that answers 13 questions at the same time and arrive at 1 final binary choice", and need to babysit with decomposition & CTEs. But even with some examples of those the team can begin to take matters into their own hands. In my experience, the joins are the hardest part. If you can, organize your problem such that even very inefficient nested queries can complete in a few milliseconds. We do things like run SQLite in-memory to achieve this outcome. Allow the team to do lazy crap and get shit done. You can always iterate the queries for quality later on - I think an LLM does this for us in our near future.