We did that for a Plotly dashboard in Python. We copied the database into a read-only in-memory sqlite database (it is quite small, only a couple thousand entries) to prevent any damages outside the dashboard. The data only gets updated every couple of days. You could skip this step. Then with sqlite you can restrict what action a query can use (SELECT, JSON, etc.) and you can restrict the instructions per query to prevent denial of service. It works like a charm and is much simpler than providing a REST API. Also the user might already know SQL.

I am actually planning something similar for a task management web app I am building at the moment (additionally to providing a REST API). No need to learn another query language like in Jira.

[–] shoo@lemmy.world 12 points 1 day ago

Couple of reasons of varying importance:

Security. Even when you limit operations or table access it's very easy to mess something up. Some new employee starts storing sensitive data in the wrong place or a db admin accidentally turns off the wrong permissions, etc...
It's secretly more overengineered than a standard api despite looking simpler. If your app needs extremely robust query capabilities then you probably have a use case for an entire analytics stack and could use an open source option. Otherwise your users probably just need basic search, filtering, sorting, etc...
Ungodly, Flex Tape tier tight coupling. Part of the purpose of an api is to abstract away implementation details and present a stable contract. Now if you want to migrate/upgrade the database or add a new data source, everyone has to know about it and it's potentially a major breaking change.
Familiarity. If someone else steps in to maintain it it's much easier to get up to speed with a more standard stack. You don't need a seven layer salad of enterprise abstraction bullshit, but it's useful to see a familiar separation of auth, queries, security, etc...
Having the option to do business logic outside of the database can save countless headaches. Instead of inventing views or kludging sprocs to do some standard transformation, you can pull in a mature library. Some things, such as scrubbing PII, are probably damn near impossible without a higher tier layer to work in.
Client support. Your browser/device probably has a few billion options for consuming a REST/HATEOAS/graphql/whatever api. I doubt there's many direct sql options with wide support.

I probably wouldn't do it outside of a tiny solo project. There are plenty of frameworks which do similar things (such as db driven apis) without compromising on flexibility, security or features.