How to fix P2033: A number used in the query does not fit into a 64 bit signed integer in Prisma

PrismaINTERMEDIATEMEDIUMUpdated Dec 22, 2025· 139 views

The Prisma P2033 error occurs when you try to store or query with integer values that exceed the 64-bit signed integer range (-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807). This typically happens when working with very large numbers, timestamps, or IDs that exceed this limit.

Quick fix

Fixes P2033: A number used in the query does not fit into a 64 bit signed integer

// Before: May cause P2033 for large values
model Transaction {
  id        Int     @id @default(autoincrement())
  amount    Int     // May overflow for large amounts
  timestamp Int     // May overflow for future dates
}

// After: Uses BigInt to prevent overflow
model Transaction {
  id        Int     @id @default(autoincrement())
  amount    BigInt  // Can store arbitrarily large amounts
  timestamp BigInt  // Can store future timestamps safely
}
  1. Change field type from Int to BigInt in your Prisma schema
  2. Use BigInt literals in your TypeScript/JavaScript code
  3. Handle existing data migration from Int to BigInt
  4. Validate and sanitize numeric inputs
prisma — error
// Before: May cause P2033 for large values
model Transaction {
id Int @id @default(autoincrement())
amount Int // May overflow for large amounts
timestamp Int // May overflow for future dates
}
// After: Uses BigInt to prevent overflow
model Transaction {
id Int @id @default(autoincrement())
amount BigInt // Can store arbitrarily large amounts
timestamp BigInt // Can store future timestamps safely
}
P2033: A number used in the query does not fit into a 64 bit signed integer

What this error means

The P2033 error in Prisma indicates that a numeric value in your query exceeds the maximum size that can be stored in a 64-bit signed integer. This error is thrown as a `PrismaClientKnownRequestError` when you attempt database operations with numbers outside the range of -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. 64-bit signed integers are the standard integer type used by most databases and programming languages for large whole numbers. When you work with values larger than this (such as very large timestamps in milliseconds, big financial amounts, or oversized IDs), Prisma cannot safely store or process these values using standard integer types. This error commonly occurs when: 1. Working with JavaScript numbers that exceed Number.MAX_SAFE_INTEGER (9,007,199,254,740,991) 2. Using timestamps in milliseconds that accumulate over long periods 3. Storing large financial amounts or scientific measurements 4. Working with database IDs or counters that grow very large 5. Migrating data from systems that use larger numeric types The error message suggests using `BigInt` as an alternative field type, which can handle arbitrarily large integers in JavaScript and is supported by Prisma for databases that have equivalent big integer types.

Typical symptoms

  • Prisma Client throws a PrismaClientKnownRequestError with code P2033
  • Database operations fail with "A number used in the query does not fit into a 64 bit signed integer" message
  • Errors occur when inserting, updating, or querying with large numeric values
  • JavaScript Number type shows precision loss or rounding for very large values
  • Timestamps or counters that have grown very large over time cause failures

Common causes

  1. Using JavaScript Number type for values exceeding Number.MAX_SAFE_INTEGER (9,007,199,254,740,991)
  2. Storing timestamps in milliseconds that exceed the 64-bit signed integer range
  3. Working with large financial amounts, scientific data, or counters that grow beyond integer limits
  4. Database IDs or sequence numbers that have grown very large over time
  5. Migrating data from systems that use larger numeric types than 64-bit integers
  6. Arithmetic operations that produce results exceeding the integer range

How to fix "P2033: A number used in the query does not fit into a 64 bit signed integer"

1Change field type from Int to BigInt in your Prisma schema

Update your Prisma schema to use BigInt instead of Int for fields that need to store large numbers:

prisma
// Before: May cause P2033 for large values
model Transaction {
  id        Int     @id @default(autoincrement())
  amount    Int     // May overflow for large amounts
  timestamp Int     // May overflow for future dates
}

// After: Uses BigInt to prevent overflow
model Transaction {
  id        Int     @id @default(autoincrement())
  amount    BigInt  // Can store arbitrarily large amounts
  timestamp BigInt  // Can store future timestamps safely
}

After changing the schema, run npx prisma db push or npx prisma migrate dev to update your database.

2Use BigInt literals in your TypeScript/JavaScript code

When working with large numbers in your application code, use BigInt literals (append n to the number):

typescript
// Wrong: Using regular number (may lose precision or overflow)
const largeAmount = 10000000000000000000; // Exceeds MAX_SAFE_INTEGER

// Right: Using BigInt literal
const largeAmount = 10000000000000000000n; // BigInt, preserves precision

// Working with BigInt in Prisma queries
await prisma.transaction.create({
  data: {
    amount: 10000000000000000000n, // BigInt literal
    timestamp: BigInt(Date.now()) // Convert to BigInt
  }
});

// For values from user input or APIs
const userAmount = BigInt(req.body.amount); // Convert string to BigInt

Remember that BigInt cannot be mixed with regular numbers in arithmetic - you must convert between types explicitly.

3Handle existing data migration from Int to BigInt

If you need to migrate existing Int data to BigInt, create a migration script:

typescript
// Migration script to convert Int to BigInt
async function migrateIntToBigInt() {
  // 1. First, update your Prisma schema to use BigInt
  // 2. Create and apply a migration
  // 3. Run data migration if needed

  const transactions = await prisma.transaction.findMany();
  
  for (const transaction of transactions) {
    // Convert Int values to BigInt
    await prisma.transaction.update({
      where: { id: transaction.id },
      data: {
        amount: BigInt(transaction.amount),
        timestamp: BigInt(transaction.timestamp)
      }
    });
  }
}

// For large datasets, use batch operations
async function batchMigrate() {
  const batchSize = 1000;
  let skip = 0;
  
  while (true) {
    const transactions = await prisma.transaction.findMany({
      take: batchSize,
      skip: skip
    });
    
    if (transactions.length === 0) break;
    
    await prisma.$transaction(
      transactions.map(transaction =>
        prisma.transaction.update({
          where: { id: transaction.id },
          data: {
            amount: BigInt(transaction.amount),
            timestamp: BigInt(transaction.timestamp)
          }
        })
      )
    );
    
    skip += batchSize;
  }
}

Always backup your database before running data migrations.

4Validate and sanitize numeric inputs

Implement input validation to catch large numbers before they cause P2033 errors:

typescript
function validateNumberInput(value: string | number): BigInt | null {
  try {
    const bigIntValue = BigInt(value);
    
    // Check if it fits in 64-bit signed integer range
    const MAX_64BIT = 9223372036854775807n;
    const MIN_64BIT = -9223372036854775808n;
    
    if (bigIntValue > MAX_64BIT || bigIntValue < MIN_64BIT) {
      console.warn(`Value ${value} exceeds 64-bit signed integer range`);
      return null;
    }
    
    return bigIntValue;
  } catch (error) {
    console.error(`Invalid number input: ${value}`, error);
    return null;
  }
}

// Usage in your application
const userInput = req.body.amount;
const validatedAmount = validateNumberInput(userInput);

if (!validatedAmount) {
  return res.status(400).json({ error: 'Invalid amount specified' });
}

// Safe to use with Prisma
await prisma.transaction.create({
  data: {
    amount: validatedAmount,
    // ... other fields
  }
});

This prevents P2033 errors by validating inputs before they reach the database.

5Use appropriate numeric types for different use cases

Choose the right numeric type based on your data requirements:

prisma
model FinancialRecord {
  id        Int     @id @default(autoincrement())
  
  // For currency amounts (use Decimal for precision)
  amount    Decimal @db.Decimal(19, 4) // 19 total digits, 4 decimal places
  
  // For large counters or IDs
  bigCounter BigInt
  
  // For normal integers within safe range
  quantity  Int
  
  // For floating point numbers
  ratio     Float
  
  // For timestamps (consider DateTime type instead)
  createdAt DateTime @default(now())
}

// Alternative: Store timestamps as DateTime instead of numeric
model Event {
  id        Int      @id @default(autoincrement())
  timestamp DateTime // Better than BigInt for timestamps
  
  // If you need millisecond precision
  timestampMs BigInt // Only if you need milliseconds specifically
}

- Use Decimal for financial amounts requiring exact precision
- Use BigInt for very large whole numbers
- Use Int for normal integer values within safe range
- Use Float for scientific measurements where precision loss is acceptable
- Consider DateTime for timestamps instead of numeric types

6Implement error handling for P2033 in your application

Wrap Prisma operations in try-catch blocks to handle P2033 errors gracefully:

typescript
import { Prisma } from '@prisma/client';

async function createTransaction(data: any) {
  try {
    const transaction = await prisma.transaction.create({
      data: {
        amount: data.amount,
        timestamp: data.timestamp,
        // ... other fields
      }
    });
    return transaction;
  } catch (error) {
    if (error instanceof Prisma.PrismaClientKnownRequestError) {
      if (error.code === 'P2033') {
        // Handle the integer overflow case
        console.error('Number too large for database field', error.message);
        
        // Suggest using BigInt or validating input
        throw new Error(
          `The value ${data.amount} is too large. ` +
          `Consider using BigInt type or validating input size.`
        );
      }
    }
    // Re-throw other errors
    throw error;
  }
}

// Alternative: Proactive checking
function ensureFitsIn64Bit(value: BigInt | number): boolean {
  const bigIntValue = typeof value === 'bigint' ? value : BigInt(value);
  const MAX_64BIT = 9223372036854775807n;
  const MIN_64BIT = -9223372036854775808n;
  
  return bigIntValue >= MIN_64BIT && bigIntValue <= MAX_64BIT;
}

// Check before database operation
if (!ensureFitsIn64Bit(data.amount)) {
  throw new Error('Amount exceeds 64-bit integer range');
}

This ensures your application provides helpful error messages and doesn't crash when encountering large numbers.

Advanced notes

Database Compatibility: While Prisma supports BigInt, database compatibility varies:
- PostgreSQL: Supports bigint (8-byte integer) and numeric (arbitrary precision)
- MySQL: Supports BIGINT (8-byte signed integer) and DECIMAL
- SQLite: All integers are stored as 8-byte signed integers (similar to BIGINT)
- SQL Server: Supports bigint and decimal/numeric

JavaScript Number Limitations: JavaScript's Number type uses double-precision floating point (IEEE 754), which can only safely represent integers up to Number.MAX_SAFE_INTEGER (9,007,199,254,740,991). Beyond this, integers may lose precision. BigInt was introduced to solve this problem.

Performance Considerations: BigInt operations are generally slower than regular number operations. For performance-critical applications:
- Use Int where possible
- Consider using Decimal for financial amounts
- Benchmark BigInt operations in your specific use case

TypeScript Configuration: Ensure your TypeScript configuration supports BigInt:

json
{
  "compilerOptions": {
    "target": "ES2020", // or higher for BigInt support
    "lib": ["ES2020"] // includes BigInt
  }
}

Migration Strategies: When migrating from Int to BigInt:
1. Test the migration on a staging environment first
2. Consider downtime for large datasets
3. Update API contracts if returning BigInt to clients
4. Handle backward compatibility for existing clients

Common Pitfalls:
- Mixing BigInt and Number in arithmetic (use explicit conversion)
- JSON serialization of BigInt (may need custom serialization)
- Database driver compatibility with BigInt
- Frontend JavaScript that doesn't support BigInt (older browsers)

Frequently asked questions

What does "P2033: A number used in the query does not fit into a 64 bit signed in" mean?
The P2033 error in Prisma indicates that a numeric value in your query exceeds the maximum size that can be stored in a 64-bit signed integer. This error is thrown as a PrismaClientKnownRequestError when you attempt database operations with numbers outside the range of -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. 64-bit signed integers are the standard integer type used by most databases and programming languages for large whole numbers.
How do I fix "P2033: A number used in the query does not fit into a 64 bit signed in"?
The Prisma P2033 error occurs when you try to store or query with integer values that exceed the 64-bit signed integer range (-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807). This typically happens when working with very large numbers, timestamps, or IDs that exceed this limit.
What causes "P2033: A number used in the query does not fit into a 64 bit signed in"?
Using JavaScript Number type for values exceeding Number.MAX_SAFE_INTEGER (9,007,199,254,740,991) Storing timestamps in milliseconds that exceed the 64-bit signed integer range Working with large financial amounts, scientific data, or counters that grow beyond integer limits
Is the "P2033: A number used in the query does not fit into a 64 bit signed in" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading