Why I Stopped Using Prisma for High-Volume Production Workloads

The client had 8 clothing brands. Monthly uploads of 15K to 30K rows each. Prisma was my starting choice because the schema tooling and migration workflow are genuinely good.

The first few months were fine. Data volumes were small, tests passed, the DX was clean. Then we went live with real monthly data.

Problem

Uploads started failing around the 20K record mark. Not every time, but often enough that operations teams were re-uploading files manually to recover.

Prisma wraps every write operation in its own transaction by default. At 20K records, that behavior creates 20K sequential transaction opens and closes against a connection pool that is not built for that pattern. Add concurrent uploads from two brands and the pool hits its limit. New requests queue. Some timeout.

The second problem was reports. The MOS report joined stores, transactions, inventory, and deliveries. Prisma does not execute SQL JOINs directly. It fetches each related table separately and merges results in its Rust query engine. For one report page with 100 stores that is 4 separate database round trips instead of one. At 2 minutes per page load, managers stopped trusting the system.

I tried adjusting Prisma transaction isolation, increasing pool limits, and chunking uploads at the application layer. The timeouts shifted but did not resolve. The query engine architecture was the constraint, not the configuration.

Solution

I kept Prisma for what it does well: schema definition, migrations, and TypeScript type generation. That workflow stayed unchanged.

For data operations I moved to MySQL2 with a direct connection pool.

The specific changes:

• Connection pool of 20 connections per brand instance with keepAliveInitialDelay enabled
• Bulk INSERT using multi-row VALUES syntax, one query per batch of 3000 records
• Bulk UPDATE using CASE WHEN, one query per batch instead of individual row updates
• Native SQL JOINs for reports, replacing the 4-query Prisma fetch pattern
• Composite indexes on (store_id, transaction_date) and (store_id, stock_level)

The Prisma-generated TypeScript interfaces stayed in the codebase. I used them as type annotations on MySQL2 RowDataPacket results. Type safety without keeping the query engine.

Result

20K record uploads now finish in about 8 seconds. Before the fix, they timed out more often than not.

The MOS report dropped from 2 minutes to 30 to 40 seconds.

Connection pool exhaustion errors went to zero after the pooling configuration was in place.

The split works in practice: Prisma for schema management, MySQL2 for data at volume. The types from Prisma are still used everywhere in the codebase.

One thing I took from this: benchmark with real data volumes before committing to an ORM for a data-heavy system. Light usage hides a lot.