The particular tool Fabien recommends may be "PostgREST", but the general approach is "API database architecture", which has been adopted by a number of other tools as well: PostGraphile, Prisma, and Hasura come to mind. There is a lot of criticism of this approach in the comments here, but they exhibit a lot of repetition, so let me consolidate them--along with my responses--in one place and be done with it.<p><i>You should never expose your database.</i><p>Let me stop you right there. Please don't tell me what I should do, especially if you don't know what my circumstances are. You'll get a less frosty response if you make your criticism impersonal and frame it in terms of trade-offs.<p><i>Fine. 'One' should never expose their database.</i><p>Unless it's accompanied by reasoning and evidence, I'm going to regard criticisms like these as received wisdom.<p><i>OK. One should never expose their database because of security concerns.</i><p>PostgREST (for instance) addresses these concerns through a combination of web tokens, database roles, database permissions, and row level security. Other tools (Hasura, PostGraphile) are similar. If this strategy is inadequate, well that's an interesting topic. Please elaborate. If there's valid criticism, perhaps there's something the PostgREST team can do about it.<p><i>Also, one should never expose their database because the API should be decoupled from the data model.</i><p>Again with the received wisdom.<p><i>Fine. The API should be decoupled from the data model because of good reasons, like freeing the underlying data model to change without breaking clients.</i><p>With this approach, the API can be decoupled from the data model by using schema, views, and procedures in SQL. If that's inadequate, again that's an interesting topic. Let's hear more.<p><i>If the database is going to be exposed, then just go all the way and open up the database port.</i><p>Remember the thing above about "circumstances"? Sometimes, the circumstances don't allow this. For example, sometimes circumstances demand an HTTP API. That's going to be difficult for many databases without a little help. That's where things like PostgREST comes in.<p><i>This approach doesn't save much effort because creating APIs in code is so trivial that it can even be automated.</i><p>If it's trivial, then why pay an expensive developer to do it? If it can be automated, well that's what exactly what PostgREST is doing: automating APIs.<p><i>This approach adds another layer</i><p>No, this approach replaces one kind of layer with a different kind of layer. It replaces (for example) Spring Boot with PostgREST. If Hibernate is also being used, then arguably PostgREST is replacing two layers.<p><i>ORMs are bad</i><p>I'm sympathetic to that point-of-view but regard it as a <i>non-sequitur</i> since PostgREST isn't an ORM. Neither is Prisma, for that matter, despite what their marketing material says.<p><i>REST is bad</i><p>Traditionally, APIs of any stripe were difficult to code by hand. Web APIs tended to be REST APIs for a long time. Ergo, REST APIs were difficult to code by hand, not because they were REST but just because that was the nature of things. Consequently, REST APIs got a bit of a bad rap. The ease of providing REST APIs with PostgREST, however, warrants revisiting that criticism "REST is bad."<p><i>But this leaves me no place to put my business logic</i><p>Well, some kinds of business logic (input validation, sequencing, and data transformations) can be handled in the database. Other kinds are more challenging (side-effects, for example). I'd love to hear the details.<p><i>Even if the general approach of "API database architecture" can be good, why use PostgREST instead of writing your own framework which is more database-agnostic</i><p>Two reasons: One, I don't want to write the code and the PostgREST developers are probably better than I am anyway. Two, I don't need the database agnosticism. People who <i>do</i> need support for another database might consider Prisma or Hasura. If that doesn't fit the bill then yes, in that case custom code probably is in order.<p><i>Building applications in the database, in SQL, feels awkward.</i><p>Many things feel awkward at first.<p><i>Building applications in the database just isn't how it's done at my organization.</i><p>Fair enough, but that's a <i>social</i> obstacle to this approach, not a <i>technical</i> obstacle.