5 ms·
I would modify this to "Don't use Prisma if you're using serverless" With actual servers and prisma running close to the underlying database, it should be much
by spion 3y ago
I would modify this to "Don't use Prisma if you're using serverless"
With actual servers and prisma running close to the underlying database, it should be much better.
Regarding using joins, that's not necessarily the best choice either. When using simple flat joins naively, you get a lot of repetition for the more toplevel nodes of the join tree, which eventually adds up to a lot of network traffic and allocation. (TypeORM tends to have this issue, for example)
What you really want are joins that build the JSON on the server. In MSSQL this can be as simple as `FOR JSON`. In Postgres it can get... a bit more involved - Drizzle can do it: https://github.com/drizzle-team/drizzle-orm/releases#:~:text=Improved%20Relational%20Queries%20Permormance%20and%20Read%20Usage https://github.com/drizzle-team/drizzle-orm/releases#:~:text...
This is probably okay, although I do wonder what happens after you hit the compute limits of your database server (i.e. scenarios when you don't use things like planetscale). In those cases (again, non-serverless), Prisma's choice might work better as long as it runs close to the DB. It will still likely be slower than the fancy JSON join, but probably need fewer database resources (depending on how its done).
- jasfi 3y agoAgreed, if you have some sort of limit, then it seems that AWS Lambda has a limitation you could hit with Prisma. Prisma has some support for joins with relations: https://www.prisma.io/docs/concepts/components/prisma-schema/relations https://www.prisma.io/docs/concepts/components/prisma-schema... Also, you need to specifically create a transaction to encompass your Prisma calls to limit them to a transaction. This is the default for PostgreSQL as well.
- estebarb 3y agoThe joins should be done inside the DB, not in an external server. Any SQL DB should be able to do that.
- spion 3y agoIf this is not done carefully, it can also be slow in some situations, even with the right indeces in place. Lets say we have the following slightly contrieved case: organizaiton(id, name, description) -> users(id, name) -> posts(id, content) -> comments(id, userId, content) We want to get one organization with all its users. Lets imagine our org has 100 users, each of which has 100 posts on average, each of which has 100 comments on average. In a naive, flat join, we'll be repeating the organization description column 1 million times, and each post's content about 100 times on average. This can still be problematic without joins, as sending 1 million comment IDs in a query to the DB isn't going to work, so even the multiple queries version will need to do better than that
- RadiozRadioz 3y agoStill not a reason to not leverage the database. Use something like Postgres' ARRAY_AGG; reduces the duplicates, faster and better than rolling your own JOINs in your app.
- spion 3y agoThe drizzle example I linked to is a realistic example into what would actually be involved in using JSON aggregation in the datbase in PG. Its painful to write manually. I wish postgres had FOR JSON (https://learn.microsoft.com/en-us/sql/relational-databases/json/format-query-results-as-json-with-for-json-sql-server?view=sql-server-ver16 https://learn.microsoft.com/en-us/sql/relational-databases/j...)
- himinlomax 3y agoThat this has to be said is scary.