Played around with postgraphile a bit and love how easy it is to stand up a graphql endpoint with a ton of features. Liked it a lot more than hasura because you could use it as a library to expose a graphql endpoint on a next.js api endpoint rather than running as a separate service.

I do wonder how a project built with a lot of logic in the DB ends up evolving over time. With a Rails project (my recent professional experience) if we're tweaking a feature, I can refer a new engineer to my_feature.rb where they'll find all the logic around that feature. With triggers and functions in the DB, it seems like there's not a common notion of organizing the source code. Anyone dealt with that in the past?

The thing that's attractive to me about Prisma is that the mental model seems a lot closer to ActiveRecord and I just understand that way of working and scaling a productive team using it.

Second this. I've used both Postgraphile and Prisma on production projects (they can work well together too). Both are cool, but Postgraphile is way more mature.

The end goal is goal is different:

- Prisma is supposed to use as an ORM and not to be publicly exposed (although you can if you want)

- Postgraphile is a way to create an API using only your DB schema as reference. There are some tricks here and there, but you would need to do dig quite deep in SQL.

I tried postraphile and is quite cool for quick prototypes. Once you need something more custom, it gets tricky and weird (it is doable though). I haven’t tried Prisma in prod because, at the end, I am pretty happy with sqlc in Golang (code generator based on SQL queries).

Also Hasura.