[flockonus]

Well the question you saw coming (hopefully) - how does it compare to Prisma use cases?

One thing I really like about Prisma is only updating my schema and having migrations generated as the "diff".

[aleclarsoniv]

I wouldn't compare the two directly, as they serve different preferences. I would say that using Postgres functions is more powerful, but that may not matter for your app, depending on its complexity and needs. Ultimately, I'm not concerned with persuading Prisma users to switch over just yet.

As far as migrations go, pg-nano is taking the same “schema diffing” approach that I assume Prisma does, where the active schema of your Postgres instance is compared to the desired schema (defined via SQL files in pg-nano's case) and a migration plan is generated from there. In the context of migrating a non-local Postgres instance, pg-nano still has some R&D to do.

[pocketarc]

Are those migrations still editable, out of curiosity? Oftentimes I'll want to have migrations add things that simply aren't possible with some ORMs (e.g. generated columns, which can't be schema'd in most ORMs).

The main thing holding me back from Prisma is precisely what you like about it - if the migrations are auto-generated and I can't edit them afterward, I won't be able to do what I need to.

[moltar]

You can edit Prisma migrations. They are plain SQL files with no magic.

[notduncansmith]

+1 have had to edit Prisma files after generating a migration, it went fine. As ‘moltar says, no magic.