Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Unusually high row reads

See original GitHub issue

Bug description

This issue can probably largely be ignored because it’s likely an edge case, but wanted to post it here for anyone else running into a similar issue.

A month ago, I noticed extremely high row reads in our PlanetScale database — over 1 billion row reads over a period of 30 days (our plan only allotted us 100M row reads per month). For a small app with a database of ~56K, these many row reads pointed to an error somewhere.

How to reproduce

It turns out that a nested some: {} Prisma query was responsible for the excess. I had implemented the following schema that accounted for a User as well as a UserAlias table since some users used multiple email addresses to sign in, and we wanted to make sure that whichever email they used would get them to the same account:

model User {
  UserAliases      UserAlias[] @relation("UserAliasesToOUser")
  UserAlias        UserAlias?  @relation("OUserAliasToOUser")
  email            String      @unique
}

model UserAlias {
  id          String   @id @default(uuid())
  User        User?    @relation("UserAliasesToOUser", fields: [userEmail], references: [email])
  userEmail   String? // User’s default email
  Alias       User?    @relation("OUserAliasToOUser", fields: [aliasEmail], references: [email])
  aliasEmail  String?  @unique

  @@index([aliasEmail])
  @@index([userEmail])
}

Each time a user logged in, the following Prisma query was run:

The purpose of this was to get the user’s information, regardless of which email they used.

It turns out that doing a nested query using some: {} effectively scans the entire table. So each time a user logged in, all 56K records where read, and this soon ended up being over a billion rows being read each month.

The fix itself was easy: I just broke up the where query into two separate Prisma reads: