You haven't really looked into postgrest, it does not force the database schema on to the client. You expose a schema with views that are tailored for the frontend and can be totally different from the underlying tables that hold the actual data

I admit I haven't but I totally agree with you. I'm attempting to say that postgrest and graphQL are _not_ examples of apis from 'a single schema definition' in that they are not the previous incarnation of that desire where an ORM would tightly couple your imperative types to your normalized schema. These new technologies have a wholistic/referential public API but they allow client, server and DB to all have different schemas and I just want to highlight the difference.

Yes, but the constrains sql has wrt. how you represent certain datatypes can lead to problems. Sure in postgres you can fix that by a variety of compound types, and fully new types implemented as pg extension, which can scare people of.

Still there are a tone of applications for which just the basic types are good enough and the server is just a thin wrapper.

In the end the main requirement for efficiency using it is you skill with not basic SQL/plpgSQL (stored procedure, trigger functions, views and knowledge about the effects of the used isolation level). All well documented in postgres.

> In the end the main requirement for efficiency using it is you skill with not basic SQL/plpgSQL

Another way I've heard this phrased is "It's much easier to hire JS devs than PL/pgSQL devs."

Yes, this is the true reason why these elegant solutions don't see so much adoption.

Worse is better. Cheap JS devs to solve everything with heaps of imperative code is cheaper than elegant solutions.

Even long term this is true. Tech debt with code that people can understand and modify is cheaper than tech debt with an elegant DSL that require learning and mental ability beyond if then else.

There's a postgres extension called plv8 that essentially allows one to write database functions in JavaScript, instead of plpgsql.

Oh, absolutely. Same with Python, Tcl, Perl... but that's not the part I'm talking about. The business logic being encoded as pgpl/* is just fine. But having to write complex triggers that wrap pgpl functions and making sure the state of the functions is as expected and all of the other wiring stuff is just not something most people are used to.

I've recently seen an uptick in "Postgres-native" stuff being built, though. So maybe there's hope for the future.

what do datatypes have to do with this. For both PostgREST and any other api layer the situation is the same. The data sits in the db/tabes (so both parties are restricted to the types available in pg) and on the other end you need to output json. The fact that you can have some "smart" internal datatypes in other api layers has 0 advanteges, both systems have to basically take data from the db and display it as json, the intermediate types are irelevant

you can write your stored procedures in JS of Python if you don't like plpgsql that much :)