We migrated to SQL. Our biggest learning? Don't use Prisma
1–10 of 104 posts
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#2Prisma is an offshoot of graphql.cool, which was a "graphql API as a service". It seems to me that was a potentially good and viable business. However they stopped graphql cool and released Prisma, where there's no business model (who's gonna pay for an ORM?). I'm still left wondering why they did that?
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#3IMO foreign key constraints are bad; they make migrations and maintenance a nightmare. It's better to have application-level processes in place to ensure data consistency. I don't agree that "no foreign key support" is a good reason to not use a particular solution. Pricing concerns are valid though.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#4IMO foreign key constraints are bad; they make migrations and maintenance a nightmare. It's better to have application-level processes in place to ensure data consistency. I don't agree that "no foreign key support" is a good reason to not use a particular solution. Pricing concerns are valid though.
Depends how important consistency is - application-level only will mean it can potentially silently fail if there is a bug.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#5Maybe 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 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.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#6IMO foreign key constraints are bad; they make migrations and maintenance a nightmare. It's better to have application-level processes in place to ensure data consistency. I don't agree that "no foreign key support" is a good reason to not use a particular solution. Pricing concerns are valid though.
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.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#7Prisma is an offshoot of graphql.cool, which was a "graphql API as a service". It seems to me that was a potentially good and viable business. However they stopped graphql cool and released Prisma, where there's no business model (who's gonna pay for an ORM?). I'm still left wondering why they did that?
I presume the services around it, e.g. their products under the Data Platform:
- https://www.prisma.io/data-platform/accelerate
and:
- https://www.prisma.io/data-platform/proxy
Whether it's a viable business is to be seen though.
I've been a happy user of Prisma for a while, and so far we've not been running into severe limitations nor need for their additional services. Who knows what the future will bring though.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#8IMO foreign key constraints are bad; they make migrations and maintenance a nightmare. It's better to have application-level processes in place to ensure data consistency. I don't agree that "no foreign key support" is a good reason to not use a particular solution. Pricing concerns are valid though.
There are situations where not using foreign keys makes sense. Most of the time, there is no benefit to not using them, only risk.
Your database is the last line of defense for data integrity.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#9Drizzle looks like an interesting alternative to Prisma https://orm.drizzle.team
You get TS support, tooling, and a very thin layer on top of SQL so little performance hit.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#10IMO foreign key constraints are bad; they make migrations and maintenance a nightmare. It's better to have application-level processes in place to ensure data consistency. I don't agree that "no foreign key support" is a good reason to not use a particular solution. Pricing concerns are valid though.
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.