Came across this last night.
Was looking for a CRUD system for a Postgres database and defaulted to look at Django with DRF but stumbled across this: PostgREST
Builds a API and all config and credentials are sourced in the DB.
1 Like
Reminds me of a project a friend of mine is working on called omnigres - not just CRUD, trying to move the entire application into the DB. 
I’ve never had the chance to work with either but removing layers of abstraction where they’re not needed sounds like a good cause to me.
When the Grails framework originally provided this possibility - i.e. expose your whole data layer with a REST API - it was kind of frowned on. But I think that was because in that context it would also be sitting alongside an application which was encapsulating business logic, and so some tables you really wouldn’t want to expose.
However if you spun this up instead of using things like Firebase (or Supabase) and had an SPA in front of it that could be really cool. Or even if you needed data captured from CLI tools spread around a number of servers for monitoring.
hmmm, I like it. So many options. 
That gives me traumatic flashbacks to…Oracle 9i DB and the, ah, special discovery of the embedded JVM that ran in it which could execute your classes that you had inserted as BLOBs. How database, such consolidation. It was one of the very first components we disabled.
(We used to joke about deploying the Oracle app server onto it and thus removing the middle tier servers completely 
)