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

31–40 of 104 posts

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

#31

Post by CharlieDigital »

freddref wrote: post #18
CharlieDigital wrote: post #5

Maybe it's just me, but if I'm doing any sort of migration like this, the first thing I do is create a small PoC that emulates the full process to iron out any weird, obvious edge cases and ergonomic issues. In this case, hitting the Lambda size limit would have been the first red flag that triggered a re-evaluation of the whole approach. Understanding the limits of the stack (Prisma + PlanetScale) would have been ob…

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…

I have a directory on my drive called `sandbox` where I basically throw together small toys for anything with some unknown complexity. Anything from how an ORM might model a specific type of relationship (throw together a basic replica with a Docker compose file) to replicating the deployment model (poking AWS Copilot, for example) to testing out some tooling flow (e.g. local build process change).

The main thing with a toy model is speed. You can build/deploy/test with a smaller scope and progressively scale it up some reasonable scale of the full thing (whatever you're testing for) and you can iterate your testing faster. But many times, the key issues show up quite early in the process of grokking the toy model.

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

#32

Post by danjac »

CharlieDigital wrote: post #5

Maybe it's just me, but if I'm doing any sort of migration like this, the first thing I do is create a small PoC that emulates the full process to iron out any weird, obvious edge cases and ergonomic issues. In this case, hitting the Lambda size limit would have been the first red flag that triggered a re-evaluation of the whole approach. Understanding the limits of the stack (Prisma + PlanetScale) would have been ob…

Maybe they should take one of their courses.

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

#33

Post by Exuma »

Wow just one look at this issue was all I needed to see. https://github.com/prisma/prisma/discussions/12715 “Please open an issue if something really is unusable or breaks in any way so we have these concrete cases recorded. In our knowledge Prisma works just fine and returns the data that was requested, just using a different method.”

Good lord

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

#34

Post by nijave »

oblio wrote: post #22
lazy_moderator1 wrote: post #17

Earlier quoted context omitted.

you can always use views + triggers for a zero downtime migration, this is a non-issue

Can you expand on this? I'm curious about the steps.

Sounds like it's basically explained in the gh-ost readme https://github.com/github/gh-ost#how

I think it amounts to "use views to decouple access to the table with a fixed interface" and "use triggers for migrating data between tables"

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

#35

Post by nijave »

lazy_moderator1 wrote: post #17
francislavoie wrote: post #10

Earlier quoted context omitted.

With foreign keys, I can't use https://github.com/github/gh-ost for zero downtime migrations. Instant deal breaker, because schema changes are inevitable given business evolution.

you can always use views + triggers for a zero downtime migration, this is a non-issue

It sounds like gh-ost is supposed to offer more control over the process but I question how many companies need that level of sophistication in DB migrations.

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

#36

Post by nijave »

est wrote: post #25
mijoharas wrote: post #19

Earlier quoted context omitted.

How do you find fkey constraints making maintenance or migrations a nightmare? I've always found them reasonably pleasant to use on postgres.

because programmers are bad at DBA jobs. DBAs don't care about business logic.

And some companies don't hire DBAs so programmers do the things programmers know/understand

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

#38

Post by leononame »

francislavoie wrote: post #10
leononame wrote: post #6

Earlier quoted context omitted.

That is a strange take tbh. For me, ensuring data integrity at the database level gives me a lot of peace of mind. Migrations are actually safer and easier because the database will complain if something's wrong, and at the application level I can do an opportunistic insert and if the FK is not valid, I'll get an error, which is really nice if I don't need the related record at all so I don't need to fetch it first.

With foreign keys, I can't use https://github.com/github/gh-ost for zero downtime migrations. Instant deal breaker, because schema changes are inevitable given business evolution.

True, but going from there to "foreign keys are bad" is still quite a jump. There are other options available for migrations as well, but I understand that it can become a trade-off at scale, especially if availability and uptime are more important than data integrity. But as I said, it's a trade-off and I suppose in most situations you won't have noticeable downtime due to migrations or you can even avoid downtime altogether without ditching foreign keys.

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

#39

Post by rewmie »

freddref wrote: post #18
CharlieDigital wrote: post #5

Maybe it's just me, but if I'm doing any sort of migration like this, the first thing I do is create a small PoC that emulates the full process to iron out any weird, obvious edge cases and ergonomic issues. In this case, hitting the Lambda size limit would have been the first red flag that triggered a re-evaluation of the whole approach. Understanding the limits of the stack (Prisma + PlanetScale) would have been ob…

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, and what you were going to build fully would be over-engineering.

On the flip side, the cases where the toy ends up being promoted to production service end up being riddles with technical debt, missing features, and buggy behavior that jeopardizes the whole project, also happen.

Survivorship bias is also a major problem. It's easy to presume that the winning bet you took is the right path.

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

#40

Post by adamzochowski »

> 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 will charge you for it.

This is expected pricing. The pricing is based on the load on the db, not based on results.

Usually there are two ways working with this:

DB supports showing estimated query plan , which explains how query would be ran without running it. Allowing to capture any missing indexes or filtered indexes.

DB allows only querying against indexes (this is usually done by no-sql dbs which have flexibility to deny bad queries).

Post reply on HN