Hacker News Reader

Comment by seer | Hacker News Reader

I don’t understand the hate, the only truly limiting factor for Prisma right now is its poor support for polymorphism, apart from that it has quite good support for complicated index setups, and if you need anything more performant, just drop to typed raw sql queries, it also supports views (materialized or otherwise) out of the box.

I recently wanted to check it out and wrote a small app that had good use of pgvector for embeddings, custom queries with ctes for a few complex edge cases, and it was all quite smooth.

Now it might not be at the level of active record, ecto or sqlalchemy but it was quite decent.

If you know your sql at any point it gave me options to drop down a level of abstraction, but still keep the types so as not to break the abstraction too much for the rest of the code.

View on HN

I don't hate prisma - it's just a tool - but that's far from the only limiting factor.

I recently looked at migrating a legacy project with basic SQL query generation to a modern ORM. Prisma came up top of course so I tried it.

We use Postgres built-in range types. Prisma does not support these, there's no way to add the type to the ORM. You can add them using "Unsupported", but fields using that aren't available in queries using the ORM, so that's pretty useless.

It also requires a binary to run, which would require different builds for each architecture deployed to. Not a big thing but it was more annoying than just switching the ORM.

That coupled with their attitude to joins - which has truth to it, but it's also short-sighted - eliminated Prisma.

The final decision was to switch to Kysely to do the SQL building and provide type-safe results, which is working well.

Some of those criticisms are out of date.

> It also requires a binary to run, which would require different builds for each architecture deployed to.

https://www.prisma.io/blog/from-rust-to-typescript-a-new-cha...

> That coupled with their attitude to joins

https://www.prisma.io/blog/prisma-orm-now-lets-you-choose-th...

As another poster has mentioned, a thing Prisma has over the others is type safety if you use the raw SQL escape hatch for performance reasons.

The binary change is after we made the decision, but the lack of support for some postgresql builtins and no way to add it is still a deal-breaker.

I guess the join one is from the internet memory, good to know for the next time!

How do you do typed raw queries?

https://www.prisma.io/docs/orm/prisma-client/using-raw-sql/r... - it assumes that these queries return arrays and there's a template you can pass in like this:

prisma.$queryraw<YourType>`SELECT * FROM ...`

Oh, just manual template typing. That's not great. We've done that and it is error-prone. A SQL-generator infers the types from the query, for example.

That's the raw, raw querying. They provide a TypedSQL system where you write SQL and it automatically generated the parameter and return types. It's in the docs.

Check out the docs https://www.prisma.io/docs/orm/prisma-client/using-raw-sql/t... it generates output types, though input types still need to be done by you via type comments in the sql

Reply on news.ycombinator.com