Don't use Prisma ORM before reading this!

Imagine the chaos, you create a free database in NeonDB with 0.5GB of storage and think, "nice, I'll use a free tier for testing" . Then, hours later, comes the fatal email: "Your storage has been consumed!". Wow, what do you mean? There wasn't even time to warm up the chair! The answer? I used the glorious Prisma ORM and, to improve, I ran several migrates throughout the day, just modeling the schema.

Let's understand what happened and, of course, why sometimes good old SQL is still a thousand times better.

First you need to contextualize yourself. I was recording CrazyStack class 124 (my Node and React bootcamp). And it is possible to use postgres or mongodb without ORMs. However, a student asked me on WhatsApp to include Prisma in the project. Hey, I decided to do the experiment.

Prisma ORM: simple but expensive

Prisma is that thing that seems perfect. "I'm going to abstract database queries, save time, that's the new hype." But, surprise! There is no free lunch, and this rango came in the form of toasted storage. I ran migrates during the day, and it was just heavy on neondb. And it wasn't even a huge project.

And Prisma not only creates the migrations, it also leaves some extra tables and logs as a bonus. If you, like me, are testing things and running migrations left and right, this gift ends up being from Greek.

Prisma is very good, but when it comes to storage, it likes to splash out:

1. Round Migrations: Every time I ran a migrate, Prisma created and stored new migrations. Each one with its own little package of metadata, logs and tables.

2. Logs That Multiply: To ensure that nothing goes wrong (or to make your life easier when it does), Prisma records detailed logs. But these logs accumulate and, as I'm not on an "unlimited" bank, they soon become a problem.

3. Overloading with Auxiliary Tables: In addition to migrations, Prisma also creates extra tables to keep track of various things, especially in relational databases, like Postgres.

In the end, what seemed like a magical tool to simplify life ended up eating my free NeonDB.

SQL "On the Nail": Why Less Is More

And this is where the good old SQL approach comes in. Yes, Prisma is great and saves time, but sometimes it just complicates things. Let's talk about the advantages of abandoning ORM and writing your queries by hand:

1. Absolute Control: There are no surprises in the bill. You know exactly what each line of code is doing and you won't find logs or hidden tables eating up your space.

2. No Dead Weight: Using direct SQL, what you write is what goes to the bank. There is no metadata, migrations or logs weighing down the stakes.

3. More Performance: Direct SQL, when done well, consumes much less space and resources. It's ideal for small banks like NeonDB for those who are freeganists like me.

4. No hidden business: No tables created from scratch or transaction logs that pile up. The control is yours, and yours alone.

Moral of the story:

If you, like me, like testing tools and doing quick experiments, think twice before throwing a Prisma ORM into your database with little space. Is the Prisma a wonder? AND. But, in a limited bank like NeonDB, it's like having a party and discovering that the beer you bought won't be enough for everyone.

Sometimes, “on the fly” SQL is the safest way, giving you exact control over what goes into the database. And the lesson is: next time, I'll think better before running one migrate after another on a 0.5GB bank.

The above is the detailed content of Don't use Prisma ORM before reading this!. For more information, please follow other related articles on the PHP Chinese website!