Imagina el caos, creas una base de datos gratuita en NeonDB con 0,5 GB de almacenamiento y piensas: "Bien, usaré un nivel gratuito para realizar pruebas". . Luego, horas más tarde, llega el correo electrónico fatal: "¡Se ha consumido tu almacenamiento!". Vaya, ¿a qué te refieres? ¡Ni siquiera hubo tiempo para calentar la silla! ¿La respuesta? Utilicé el glorioso Prisma ORM y, para mejorar, ejecuté varias migraciones a lo largo del día, simplemente modelando el esquema.

Entendamos qué pasó y, por supuesto, por qué a veces el viejo SQL sigue siendo mil veces mejor.

Primero necesitas contextualizarte. Estaba grabando CrazyStack clase 124 (mi bootcamp de Node y React). Y es posible utilizar postgres o mongodb sin ORM. Sin embargo, un estudiante me pidió por WhatsApp incluir a Prisma en el proyecto. Oye, decidí hacer el experimento.

Prisma ORM: simple pero costoso

Prisma es eso que parece perfecto. "Voy a abstraer las consultas de la base de datos, ahorrar tiempo, esa es la nueva moda". Pero ¡sorpresa! No hay almuerzo gratis y este rango vino en forma de almacenamiento tostado. Ejecuté migrates durante el día y tenía mucho uso de neondb. Y ni siquiera era un gran proyecto.

Y Prisma no solo crea las migraciones, sino que también deja algunas tablas y registros adicionales como beneficio adicional. Si tú, como yo, estás probando cosas y realizando migraciones de izquierda a derecha, este regalo termina siendo griego.

Prisma es muy bueno, pero cuando se trata de almacenamiento, le gusta hacer todo lo posible:

1. Migraciones redondas: cada vez que ejecutaba una migración, Prisma creaba y almacenaba nuevas migraciones. Cada uno con su propio pequeño paquete de metadatos, registros y tablas.

2. Registros que se multiplican: Para garantizar que nada salga mal (o para hacerle la vida más fácil cuando suceda), Prisma registra registros detallados. Pero estos registros se acumulan y, como no estoy en un banco "ilimitado", pronto se convierten en un problema.

3. Sobrecarga con tablas auxiliares: Además de las migraciones, Prisma también crea tablas adicionales para realizar un seguimiento de varias cosas, especialmente en bases de datos relacionales, como Postgres.

Al final, lo que parecía una herramienta mágica para simplificar la vida terminó comiéndose mi NeonDB gratuito.

SQL "Na Nail": por qué menos es más

Y aquí es donde entra en juego el viejo enfoque SQL. Sí, Prisma es genial y ahorra tiempo, pero a veces simplemente complica las cosas. Hablemos de las ventajas de abandonar ORM y escribir tus consultas a mano:

1. Control Absoluto: No hay sorpresas en la factura. Sabes exactamente qué hace cada línea de código y no encontrarás registros ni tablas ocultas que consuman tu espacio.

2. Sin peso muerto: usando SQL directo, lo que escribes es lo que va al banco. No hay metadatos, migraciones ni registros que pesen lo que está en juego.

3. Más rendimiento: SQL directo, cuando se hace bien, consume mucho menos espacio y recursos. Es ideal para bancos pequeños como NeonDB para aquellos que son freeganistas como yo.

4. Sin negocios ocultos: No hay tablas creadas desde cero ni registros de transacciones que se acumulen. El control es tuyo y sólo tuyo.

Moraleja de la historia:

Si a usted, como a mí, le gusta probar herramientas y realizar experimentos rápidos, piénselo dos veces antes de incluir un Prisma ORM en su base de datos con poco espacio. ¿Es el Prisma una maravilla? Y. Pero, en un banco limitado como NeonDB, es como hacer una fiesta y descubrir que la cerveza que compraste no será suficiente para todos.

A veces, SQL “sobre la marcha” es la forma más segura, ya que le brinda control exacto sobre lo que ingresa a la base de datos. Y la lección es: la próxima vez, lo pensaré mejor antes de realizar una migración tras otra en un banco de 0,5 GB.