4 ms·
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
by seer 1y ago
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.
- vvpan 1y agoHow do you do typed raw queries?
- campbellmorgan 1y agohttps://www.prisma.io/docs/orm/prisma-client/using-raw-sql/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 ...`
- vvpan 1y agoOh, 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.
- Tadpole9181 1y agoThat'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.
- seer 1y agoCheck out the docs https://www.prisma.io/docs/orm/prisma-client/using-raw-sql/typedsql 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
- sitharus 1y agoI 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.
- hn_throw2025 1y agoSome 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-chapter-for-prisma-orm 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-the-best-join-strategy-preview 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.
- sitharus 1y agoThe 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!