P
Prisma•2mo ago
goYsticks

Rust-Free Is 3x Slower

Has this been already reported? On a local Postgres database I was getting a massive number of transaction timeout messages running out seed script. Ended up with this config to avoid those. 
new PrismaClient({
      transactionOptions: {
        maxWait: 300000,
        timeout: 300000,
      },
      log: process.env.HIDE_PRISMA_QUERY === "true" ? [] : ["query"],
      adapter: new PrismaPg({
        connectionString: getDBUrl(),
        idle_in_transaction_session_timeout: 15000,
        statement_timeout: 15000,
        query_timeout: 15000,
        connectionTimeoutMillis: 15000,
      }),
    })
new PrismaClient({
      transactionOptions: {
        maxWait: 300000,
        timeout: 300000,
      },
      log: process.env.HIDE_PRISMA_QUERY === "true" ? [] : ["query"],
      adapter: new PrismaPg({
        connectionString: getDBUrl(),
        idle_in_transaction_session_timeout: 15000,
        statement_timeout: 15000,
        query_timeout: 15000,
        connectionTimeoutMillis: 15000,
      }),
    })
Rust + Non-ESM - Seeding Complete in 166.956seconds Rust + ESM - Seeding Complete in 149.892 seconds Rust Free + ESM - Seeding Complete in 557.726 seconds Thats from just changing 
generator client {
  provider        = "prisma-client"
  output          = "../../prisma-generated"
  previewFeatures = ["views"]
  binaryTargets   = ["native", "rhel-openssl-3.0.x"]
}
generator client {
  provider        = "prisma-client"
  output          = "../../prisma-generated"
  previewFeatures = ["views"]
  binaryTargets   = ["native", "rhel-openssl-3.0.x"]
}
to this 
generator client {
  provider        = "prisma-client"
  output          = "../../prisma-generated"
  previewFeatures = ["views"]
  engineType      = "client"
}
generator client {
  provider        = "prisma-client"
  output          = "../../prisma-generated"
  previewFeatures = ["views"]
  engineType      = "client"
}
and running npx prisma generate before the seed script. Our seed script uses functions from our application code, with seed data and some use of fakerjs. That is a lot of prisma upsert statements with deep nesting, and deep returns. That we then run synchronously with Promise.all([..]);
1 Reply
Prisma AI Help
Prisma AI Help•2mo ago
You opted for speed from this bot. Let's conjure up an answer right now! Yes, this issue has been reported by other users. There are multiple reports of transaction timeouts and performance regressions when switching to the Rust-free (TypeScript-based) Prisma ORM, especially during operations involving many transactions or complex, deeply nested queries. Some users specifically noted a spike in "Unable to start a transaction in the given time" errors and much slower seed scripts after moving to the Rust-free engine, even with increased transaction timeouts and connection pool adjustments. Rolling back to the Rust engine resolved these issues for them. The problem seems to be more pronounced with heavy transaction workloads and deep upserts, similar to your use case. The Prisma team is aware and investigating, but as of now, these issues persist for some users on the latest versions of the Rust-free engine Spike in Unable to start a transaction in the given time. for new prisma-client. It's worth noting that, in general, benchmarks show the Rust-free engine is faster for large data retrieval queries, but for some transaction-heavy or complex write scenarios, users have observed significant slowdowns or timeouts compared to the Rust engine. The team is actively working on improvements, but for now, if your workload is heavily transaction-bound, you may want to continue using the Rust engine until these issues are resolved Prisma ORM without Rust: Latest Performance Benchmarks. ✅ Great, thanks for letting us know that this solved your question!

Did you find this page helpful?