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

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 obvious from a few simple toy examples. Seems like this team dove headfirst without even building a simple toy to determine if the choice was actually viable. … Survivorship bias is also a major problem. It's easy to presume that the winning bet you took is the right path. brightball on Oct 9, 2023 ... I do get the feeling they went YOLO and built their solution on an over-engineered approach with a stack they were unfamiliar with, and when they hit problems, they YOLO'd into another solution without properly evaluating why, which feels like a team of junior developers run amok. They also seemed to not really understand relational databases, and why foreign keys are kind of important when you are choosing a relation database implementation (yes you can do without them, but it's best to understand them first). Exuma on Oct 9, 2023 ... The library also looks like it was written in a yolo way as well. My guess is the graphql background has permanently stunted it, as the project manager keeps wanting examples for performance issues instead of realizing the entire fact joins are missing to begin with is idiotic and absurd. So my guess is they’re piecemeal fixing one off issues instead of fixing the problem at its root, probably because prisma code is not designed with that in mind from the beginning … The lack of rollbacks is one legitimate pain point and I wish they addressed it. DanielHB on Oct 9, 2023 mattacular on Oct 9, 2023 ... Tl;dr it's a design decision, not everyone (including me) agrees.