Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We migrated to SQL. Our biggest learning? Don't use Prisma

codedamn.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#61

Post by pritambarhate »

switch007 wrote: post #24

I’ve been tempted to ditch django for typescript in the backend but the sql and migrations story looks a bit … confusing and underwhelming? I feel like typeorm should cover 99% of cases, due to its feature list and age (7 ish years…ancient!), but then you see people often recommending other projects (eg pg_typed). Do people just string things together? Make use of Liquibase? In 2021 it seemed the TypeORM project was…

We have been using TypeORM for last 2 years now. Found it quite suitable for our use case. Didn't come across any big issue.

But the projects we did with it where not very high scale. Less than 5 requests per second. So a single server affair.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#62

Post by RadiozRadioz »

spion wrote: post #53
estebarb wrote: post #43

Earlier quoted context omitted.

The joins should be done inside the DB, not in an external server. Any SQL DB should be able to do that.

If 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 ha…

Still 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.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#63

Post by patmorgan23 »

mijoharas wrote: post #13

> Weird pricing: PlanetScale prices you on row-reads and row-writes per month. What is weird is that row-reads is something that nobody controls. It is the SQL query planner which determines the query plan, which results in how many rows you’re reading internally. Remember that row-reads are not row returns. You can write a wrong query that returns 0 rows but can still do a full table scan of 1M rows and PlanetScale…

Row-reads sounds like a perfectly acceptable metric to use for billing. It's basically changing based on disk io. So what if the result of your query is 0, the server has to do a bunch of work to figure out the answer is 0.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#64

Post by DanielHB »

Tade0 wrote: post #41

I kind of want to say "y-yeah" regarding Prisma, because all this information (especially the fact that it creates a transaction every time and downloads those engines) is either available in the documentation or visible upon install/build - you can actually make it point to specific executables instead of downloading each time using environment variables but again - it's in the docs. I picked Prisma because I'm not…

I added prisma to a server I have and I was surprised it was running out of memory when using "prisma migrate deploy" (only migrations, not actually just running prisma client). The server was configured to use only 512mb of RAM though. It seems prisma migrate needs quite a bit of RAM.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#65

Post by CharlieDigital »

w0m wrote: post #57
freddref wrote: post #18

Earlier quoted context omitted.

I am amazed at the number of engineers I've worked with who jump straight into the full implementation. I've done it myself on a few occasions thinking "how hard can this be". Building the "toy" first is great. In my experience, about one third of the time the toy is all you need, you can stop there, and what you were going to build fully would be over-engineering. About one third of the time, building the toy tells…

> In my experience, about one third of the time the toy is all you need, you can stop there In my experience, about two-thirds of the time management sees the toy and ShipsIt thinking that's all you need.

Nothing wrong with that if the toy meets all of the functional and non-functional requirements.

If you find offense to this, the easiest way to mitigate is with process and practice: sandbox code goes into a dedicated "Sandbox" mono-repo and if it's suitable for production, you rebuild it appropriately in a production repo.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#66

Post by ivanb »

It looks like one poor choice leading to another poor choice. They probably chose Prisma because it may have helped them with GraphQL, whereas they most likely don't need any GraphQL at all.

Then they are screwing around with AWS Lambdas and package size, but what is the advantage of the Lambdas if they don't make your deployment easier? Just have a ECS and run whatever you want for better price/performance ratio and much higher performance ceiling.

I don't get which of their tools are improving developer productivity or software quality. It looks like every tool stands in their way. Why won't they just learn SQL and use it? What's is so low productivity about it? It's the highest level data manipulation language there is. Now they are bringing Kysely for supposed type safety. Yeah, good luck debugging, optimizing or changing the queries in any way. You'll have to convert from SQL to TypeScript and back whenever you'd want to develop the query in your SQL console.

What I see is a bunch of poor choices. Shiny tools standing in the way of getting stuff done.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#67

Post by spion »

RadiozRadioz wrote: post #62
spion wrote: post #53

Earlier quoted context omitted.

If 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 ha…

Still 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.

The 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/j...)

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#68

Post by himinlomax »

estebarb wrote: post #43
spion wrote: post #14

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. (…

The joins should be done inside the DB, not in an external server. Any SQL DB should be able to do that.

That this has to be said is scary.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#69

Post by ehutch79 »

ivanb wrote: post #66

It looks like one poor choice leading to another poor choice. They probably chose Prisma because it may have helped them with GraphQL, whereas they most likely don't need any GraphQL at all. Then they are screwing around with AWS Lambdas and package size, but what is the advantage of the Lambdas if they don't make your deployment easier? Just have a ECS and run whatever you want for better price/performance ratio and…

Your last sentence nails it. They’ve been sold a bunch of tools by tech influencers. Told that if you don’t use X you’re doing it wrong. They believed the hype.

It’s hard to remember that, at this point, most tech influencers are shitposting or are full of shit.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#70

Post by [deleted] »

ivanb wrote: post #66

It looks like one poor choice leading to another poor choice. They probably chose Prisma because it may have helped them with GraphQL, whereas they most likely don't need any GraphQL at all. Then they are screwing around with AWS Lambdas and package size, but what is the advantage of the Lambdas if they don't make your deployment easier? Just have a ECS and run whatever you want for better price/performance ratio and…

[deleted]
Post reply on HN