This is a super rude and arrogant thing to say. Have you considered, before dismissing a project with 1.2k commits, that it's not the 54 authors who worked on the project for three years who are missing something, but you who heard about it at most two hours ago?
Wow, unbelievable. I don't know in what world you think it's OK to call something useless just because you don't personally see its use, when faced with evidence that plenty of people in this thread alone do.
I understand you're not a native speaker (neither am I), so I just want to make it very clear to you in case you don't realize it: Your original message, and this reply you just wrote, are both completely out of place and uncalled for. And incorrect on a technical level.
This tool is exposing DB operations as an HTTP API. It wasn't written for you specifically, it was written to solve a particular scenario. One day, you'll encounter said scenario, and you won't even realize there's a tool out there to specifically solve it because you dismissed it as "useless". And instead of "doing something great with your time", you'll waste a few days/weeks reimplementing a poorer version of that wheel.
I'm not affiliated with the project, I don't even use it, but I can still appreciate what it does. If you can't, that's fine, but don't shit on people's work no more knowledge about it than "reading the short introduction". Lest you want me to go through your Github profile and shit on your work based on how you name your repos, which would be just as productive.
Ok the tone of my message might be out of line a little bit, but I find it important to make people aware of incorrect usage of principles/tools/framework/stuff. I would not have so much problem with this project if they would call it "API" instead of "REST API", because it would communicate the purpose much clearer.
Also it would be a huge design mistake to use this on any serious project and probably not everybody will realize this.
I have a little bit of experience with PostgreSQL.
Coming from MySQL background, I was pleasantly surprised how much abstraction you can build into your PostgreSQL database itself. With just a few views and perhaps functions you can abstract away your actual data in clean and performant way, and thus enable use of such REST API without worrying too much about future schema change.
You've just formulated one of the core concepts/techniques PostgREST relies on. You don't expose your core tables as an API, you expose views that extract data from your core tables, even if in the beginning those views are nothing more then "select * from some_table". As the api evolves, you are free to change the logic in those views without the need to touch your core tables
