postgrest VS Hasura

This is especially helpful because Supabase uses PostegREST under the hood, which does not support OpenAPI 3.x. Note that some Postgres specific features like enums are not converted to JSON Schema enums as Sequelize doesn't expose that information.

PostgREST stands out as the leading solution for PostgreSQL databases. It turns your database directly into a RESTful API with minimal configuration. The tool automatically creates endpoints for tables and views, supports complex filters, and leverages PostgreSQL's row-level security for fine-grained access control. If you'd like to see this in action, check out our Neon PostgresQL sample.

PostgREST

> I don't really see how the validation schema and ORM model would ever really diverge...

If that were the case, then using a PostgreSQL API[0] that maps tables to APIs would be all that's required.

However, the real world is messy. Requirements change, which could lead the project becoming a reimplementation of full framework such as Django.

Django also comes with generic REST endpoints based on models thus giving you the magic, but still allows for all the different use cases and customizations that might present themselves during the full lifecycle of a project.

[0]https://github.com/PostgREST/postgrest

PostgREST 12.2 is out! It comes with Observability and API improvements. In this post, we'll see what's new.

Supabase provides a RESTful API using PostgREST. However, without RLS, you will expose your database to the frontend. With the RLS policies created above, it’s safe to expose the API to the public because each user can only access the data allowed by the policy. For example, if you try to get all the List items using the API below, you will only receive the ones you are allowed to read by the read policy:

I spoke at Swiss PgDay in Switzerland in late June. The talk was about how to create a no-code API with the famous PostgreSQL database, the related PostgREST, and Apache APISIX, of course. I already wrote about the idea in a previous post. However, I wanted to improve it, if only slightly.

Supabase was started as a thin deployment layer on top of PostgreSQL and PostgREST, which implies that understanding Supabase requires understanding PostgREST and PostgreSQL.

Yes, sorry about that. We're looking at it on https://github.com/PostgREST/postgrest/issues/3503.

Hasura is a neck-to-neck competitor to Supabase as a BaaS, but with a crucial difference: its GraphQL-first approach. Unlike Supabase, Hasura doesn't bundle database services, allowing it to work with virtually any database including Supabase's own Postgres, Neon, and others.

Hasura and PostGraphile lead the PostgreSQL GraphQL landscape. Hasura provides real-time subscriptions and a powerful permissions system, while PostGraphile offers deep PostgreSQL integration and excellent performance for complex queries.

Here is an example data schema we get for a query using Hasura and GraphQL-Codegen

Hasura is a great tool. I was worried about a few things such as huge RAM consumption, excessive focus on new features and functions despite many outstanding issues, long time rewrite of the server in Rust, etc...

> 2. ORMs do not hide SQL nastiness.

This is certainly true!

I mean: ORMs are now well known to "make the easy queries slightly more easy, while making intermediate queries really hard and complex queries impossible".

I think the are of ORMs is over. It simply did not deliver.

If a book on SQL is --say-- 100 pages, a book on Hibernate is 400 pages. So much to learn just to make the easy queries slightly easier to type? Just not worth it.

I prefer jooq any day over ORMs. And dont get me started over what tools like Hasuna have to offer.

There are also some languages (forgot the names) that are SQL-done-right. Select in the back, more type safe, more logic, more in the same steps as the query gets executed. These need to be adopted by PG and MySQL and we're good to go. (IMHO)

https://www.jooq.org/

https://hasura.io/

[4] https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md

Another strategy is to model access control declaratively and enforce it in the application layer. ZenStack (built above Prisma ORM) and Hasura are good examples of this approach. The following code shows how access policies are defined with ZenStack and how a secured CRUD API can be derived automatically.

Today, this ecosystem is going strong with new providers like Hasura, AppWrite and Supabase powering millions of projects. There are a few reasons people choose this style of hosting, especially if they are more comfortable with frontend development. BaaS lets them set up a database in a secure way, expose some business logic on top of the data, and connect via a dev-friendly SDK from their app or website code to save data easily. These modern tools build a blend of managed database with curated plugins such as authentication, great admin dashboards, and function as a service type capability - all in one package, and often offered as a integrated hosted service.

Hi! If you’ve ever thought about something like using GraphQL for something like this.. You might like Hasura. (Obligatory I work for Hasura)

We’ve got an OpenAPI import and you can setup cron-jobs or one-off jobs and do things like load in headers from the environment variables to pass through. There isn’t currently an easy journey for chaining multiple calls together without writing any code at all, but you can wrap pretty much any API endpoint via OpenAPI import or a custom action, and you can even make minor edits to things like the API contract format to change aliases/naming.

Our goal is to join all the things, databases and API’s. Most people know us for instant GraphQL API’s that give you CRUD on your database, but we also wrap APIs.

Not sure if something like this would fit your use-case and do check out some of the other things mentioned, but depending what you are trying to do I think Hasura might potentially work.

You can find out more here: https://hasura.io