Prisma ORM — Avoid Connection Pool Exhaustion in Serverless

Every production Node.js or TypeScript app eventually hits the same wall: your database queries become a tangled mess of raw SQL strings, you ship a typo that only blows up in production, and your team spends Friday afternoon debugging why user.adress returned undefined instead of throwing an error at write time. This is the moment developers discover Prisma — not as a trendy tool, but as a genuine solution to a painful daily problem. Prisma is a next-generation ORM that puts your database schema at the centre of your codebase, generates a fully type-safe client, and gives you an API that feels like writing TypeScript rather than wrestling with SQL dialects.

Traditional ORMs like Sequelize or TypeORM were designed when JavaScript was untyped and callbacks were king. They tack types on as an afterthought, leaving you with models that drift from your actual schema over time. Prisma flips this entirely — the schema.prisma file is the single source of truth, and everything — your migrations, your client types, your auto-complete — is derived from it. When your schema changes, your TypeScript errors change too, catching bugs before they reach users.

By the end of this article you'll be able to define a real schema with relationships, run type-safe CRUD queries, handle relations in a single round-trip with nested writes, and avoid the three mistakes that trip up most developers in their first Prisma project. You'll also understand why Prisma makes the architectural choices it does — which is the knowledge that sticks.

Why Connection Pooling Is Not Optional in Serverless Prisma

Prisma ORM is a database toolkit that replaces traditional ORMs with a generated client and a query engine. The core mechanic: you define a schema, Prisma generates a type-safe client, and at runtime the query engine translates your calls into SQL. In serverless environments, each function invocation creates a new Prisma client instance — and each instance opens its own database connection. Without a shared connection pool, you hit the database's max connection limit (often 10–20 for free-tier Postgres) within seconds under moderate load. The pool is a cache of reusable connections managed by Prisma's engine, not by your application code. In practice, you must instantiate the Prisma client once outside the handler (using a global singleton pattern) and configure the pool size to match your database's limit. The pool size defaults to 10 connections; for serverless, set it to 1–3 to avoid exhaustion. The key property: Prisma's pool is lazy — connections are acquired on first query and released after the query completes, but idle connections remain open until the pool is drained. This matters because serverless functions can stay warm for minutes, holding connections open. When to use it: any serverless deployment (AWS Lambda, Vercel, Netlify) where the database is shared across many concurrent invocations. The cost of not pooling is a production outage — your database refuses new connections, and every subsequent request fails with a timeout or 'too many clients' error.

Setting Up Prisma: Schema as the Single Source of Truth

Prisma's setup is deliberately opinionated, and that's a feature. You install three things: the Prisma CLI (for migrations and codegen), the Prisma Client (the generated query engine you import in your app), and a database connector. The CLI reads your schema.prisma file and generates a Node.js client that's perfectly tailored to your schema — not a generic client with optional types bolted on.

The `schema.prisma` file has three blocks: datasource (which database and where), generator (what to generate — almost always the JS client), and your model definitions. Models map directly to database tables, but they're richer — you declare field types, constraints, default values, indexes and relations all in one place.

This matters because the schema is the contract between your app and your database. When you run prisma migrate dev, Prisma diffs the schema against the current database state and generates a SQL migration file. When you run prisma generate, it outputs a client with TypeScript types that exactly match that schema. There's no manual type-writing, no drift — the database and your TypeScript types are always in sync.

// datasource tells Prisma which database engine to use and where to find it.
// The DATABASE_URL is read from your .env file — never hardcode credentials.
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

// generator tells Prisma what to produce when you run `prisma generate`.
// The output is the fully-typed PrismaClient you import in your app.
generator client {
  provider = "prisma-client-js"
}

// A model maps to a database table.
// Field names become the column names (snake_case in DB via @@map if needed).
model User {
  id        Int      @id @default(autoincrement()) // Primary key, auto-incremented
  email     String   @unique                       // Unique constraint on the column
  name      String
  createdAt DateTime @default(now())               // Set automatically on INSERT
  orders    Order[]                                // Relation: one User has many Orders
}

model Order {
  id         Int      @id @default(autoincrement())
  totalPrice Float
  placedAt   DateTime @default(now())
  userId     Int                                   // Foreign key column in the DB
  user       User     @relation(fields: [userId], references: [id]) // Relation scalar
  items      OrderItem[]
}

model OrderItem {
  id        Int    @id @default(autoincrement())
  productName String
  quantity  Int
  unitPrice Float
  orderId   Int
  order     Order  @relation(fields: [orderId], references: [id])
}

CRUD with Prisma Client: Type-Safe Queries That Actually Make Sense

Once you've run prisma generate, you import PrismaClient and get an object with a property for every model in your schema. Each model property exposes methods like findUnique, findMany, create, update, upsert and delete. These aren't magic strings — they're fully typed, so your IDE auto-completes field names and TypeScript yells at you if you pass a field that doesn't exist.

The real power shows up with select and include. With select, you specify exactly which fields to return — Prisma generates a SELECT col1, col2 query rather than SELECT *. With include, you tell Prisma to JOIN related tables and return them as nested objects. You control whether you're doing a lean read or a rich read, and Prisma generates efficient SQL for each case.

Prisma's where clause uses a structured object rather than a SQL string, which eliminates an entire class of SQL injection bugs by design. You describe the filter as data ({ email: { endsWith: '@company.com' } }), and Prisma parameterises it safely under the hood. This is the difference between an ORM that prevents bugs and one that just makes bugs more comfortable to write.

import { PrismaClient } from '@prisma/client';

// Instantiate once and reuse — creating a new PrismaClient per request
// opens a new connection pool each time, which will exhaust your DB connections fast.
const prisma = new PrismaClient();

async function runOrderExamples() {

  // ── CREATE ──────────────────────────────────────────────────────────
  // Nested write: creates the User AND their first Order in a single transaction.
  // If the Order insert fails, the User insert is rolled back automatically.
  const newUser = await prisma.user.create({
    data: {
      email: 'alice@example.com',
      name: 'Alice Chen',
      orders: {
        create: [
          {
            totalPrice: 49.99,
            items: {
              create: [
                { productName: 'Mechanical Keyboard', quantity: 1, unitPrice: 49.99 }
              ]
            }
          }
        ]
      }
    },
    // include tells Prisma to JOIN and return the related orders in the response.
    // Without this, `newUser.orders` would be undefined.
    include: { orders: { include: { items: true } } }
  });

  console.log('Created user:', JSON.stringify(newUser, null, 2));

  // ── READ (findUnique) ────────────────────────────────────────────────
  // findUnique requires a @unique or @id field — it throws a runtime error
  // if you try to filter on a non-unique field, which catches logic bugs early.
  const existingUser = await prisma.user.findUnique({
    where: { email: 'alice@example.com' },
    select: {
      id: true,
      name: true,
      // Nested select: only fetch order IDs and totals — no unnecessary data
      orders: {
        select: { id: true, totalPrice: true, placedAt: true }
      }
    }
  });

  console.log('Found user:', existingUser);

  // ── READ (findMany with filter) ──────────────────────────────────────
  // Find all orders over £20 placed in the last 7 days, sorted newest first.
  const recentLargeOrders = await prisma.order.findMany({
    where: {
      totalPrice: { gt: 20 },                            // gt = greater than
      placedAt:   { gte: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000) } // last 7 days
    },
    orderBy: { placedAt: 'desc' },
    take: 10,                                            // LIMIT 10 — pagination
    include: { user: { select: { name: true, email: true } } }
  });

  console.log(`Found ${recentLargeOrders.length} recent large orders`);

  // ── UPDATE ──────────────────────────────────────────────────────────
  // update requires a unique identifier in `where`. Prisma won't let you
  // run a bulk update without using updateMany — accidental mass-updates
  // are a class of bug Prisma's API actively resists.
  const updatedUser = await prisma.user.update({
    where: { email: 'alice@example.com' },
    data:  { name: 'Alice Zhang' }          // Only this field changes
  });

  console.log('Updated name:', updatedUser.name);

  // ── DELETE ──────────────────────────────────────────────────────────
  // Always clean up in reverse dependency order, or configure cascading deletes
  // in your schema. Prisma won't silently ignore FK constraint violations.
  await prisma.orderItem.deleteMany({ where: { order: { userId: newUser.id } } });
  await prisma.order.deleteMany({     where: { userId: newUser.id } });
  await prisma.user.delete({          where: { id: newUser.id } });

  console.log('Cleanup complete.');
}

runOrderExamples()
  .catch(console.error)
  .finally(() => prisma.$disconnect()); // Always disconnect when the script ends

Transactions and Raw Queries: When You Need the Escape Hatch

Prisma's nested writes handle the common case where you want to create related records atomically. But sometimes you need to run multiple independent operations — decrement a product's stock and create an order — where both must succeed or both must fail. That's what prisma.$transaction() is for.

Prisma gives you two transaction flavours. The array form (prisma.$transaction([op1, op2])) batches operations in a single DB transaction and is perfect when you can build all operations upfront. The interactive form (prisma.$transaction(async (tx) => { ... })) gives you a transaction-scoped client so you can use the result of one query to build the next — exactly what you need for 'check stock, then place order' logic.

Sometimes you genuinely need raw SQL — complex aggregations, database-specific functions, or queries that Prisma's API can't yet express. prisma.$queryRaw handles this safely with tagged template literals, which parameterise values automatically. You get SQL's full power without reopening the injection vulnerability door that Prisma's structured API closed.

import { PrismaClient, Prisma } from '@prisma/client';

const prisma = new PrismaClient();

// Real-world checkout: deduct stock and create the order atomically.
// If the stock deduction fails (e.g. stock hits 0), the order is not created.
async function processCheckout(userId: number, productId: number, quantity: number) {

  // Interactive transaction — we need the updated stock value BEFORE creating the order.
  const result = await prisma.$transaction(async (tx) => {
    // Step 1: Check and decrement stock.
    // updateMany with a conditional where clause prevents overselling without a race condition.
    const stockUpdate = await tx.product.updateMany({
      where: {
        id:    productId,
        stock: { gte: quantity }  // Only update if enough stock exists RIGHT NOW
      },
      data: {
        stock: { decrement: quantity }
      }
    });

    // If count is 0, the WHERE clause didn't match — stock was insufficient.
    if (stockUpdate.count === 0) {
      // Throwing inside a transaction automatically triggers a rollback.
      throw new Error(`Insufficient stock for product ${productId}`);
    }

    // Step 2: Fetch the product price (we need it for the order total).
    const product = await tx.product.findUnique({
      where:  { id: productId },
      select: { name: true, price: true }
    });

    if (!product) throw new Error(`Product ${productId} not found`);

    // Step 3: Create the order now that we've confirmed and reserved stock.
    const order = await tx.order.create({
      data: {
        userId,
        totalPrice: product.price * quantity,
        items: {
          create: [{
            productName: product.name,
            quantity,
            unitPrice: product.price
          }]
        }
      },
      include: { items: true }
    });

    return order; // This value becomes the resolved value of the transaction
  });

  console.log('Order placed successfully:', result.id);
  return result;
}

// ── RAW QUERY ────────────────────────────────────────────────────────────────
// Use $queryRaw when you need something Prisma's API can't express —
// here, a revenue report grouped by month using PostgreSQL's date_trunc.
async function getMonthlyRevenue(year: number) {
  // Prisma.sql is a tagged template literal — values are ALWAYS parameterised.
  // Never use string concatenation here: `WHERE year = ${year}` would be safe,
  // but `WHERE name = '${userInput}'` would be an injection vulnerability.
  const rows = await prisma.$queryRaw<{ month: Date; revenue: number }[]>(
    Prisma.sql`
      SELECT
        date_trunc('month', placed_at) AS month,
        SUM(total_price)               AS revenue
      FROM orders
      WHERE EXTRACT(YEAR FROM placed_at) = ${year}
      GROUP BY month
      ORDER BY month ASC
    `
  );

  console.log(`Revenue for ${year}:`);
  rows.forEach(row => {
    const monthLabel = row.month.toLocaleString('default', { month: 'long' });
    console.log(`  ${monthLabel}: £${Number(row.revenue).toFixed(2)}`);
  });

  return rows;
}

// Run examples
processCheckout(1, 42, 2)
  .then(() => getMonthlyRevenue(2024))
  .catch(console.error)
  .finally(() => prisma.$disconnect());

Prisma Migrations in Practice: Evolving Your Schema Safely

Migrations are where many teams get burned. The mental model to hold onto is this: prisma migrate dev is for local development, and prisma migrate deploy is for staging and production. They're deliberately different commands with different safety profiles.

migrate dev is interactive — it detects schema drift, prompts you to name migrations, and re-runs seed scripts. It's designed for a developer who's actively shaping the schema. migrate deploy is non-interactive and deterministic — it applies only pending migrations that are already committed to version control, making it safe to run in a CI/CD pipeline without human intervention.

The workflow that actually works in teams is: make your schema change, run migrate dev locally to generate the SQL and validate it, commit both schema.prisma and the new migration file, and let CI run migrate deploy against staging. Never edit a migration file that has already been applied to any environment — Prisma checksums them, and tampering breaks the migration history. If you made a mistake in the last migration, create a new migration that corrects it.

# ── LOCAL DEVELOPMENT ────────────────────────────────────────────────────────

# Step 1: You've added a new `phoneNumber` field to the User model in schema.prisma.
# Run migrate dev to generate and immediately apply the migration to your local DB.
npx prisma migrate dev --name add_phone_number_to_users

# Prisma will output the generated SQL so you can review it:
# ALTER TABLE "User" ADD COLUMN "phoneNumber" TEXT;
# Always read this output — migrations are permanent.

# Step 2: After migrate dev, regenerate the client so your TypeScript types
# include the new `phoneNumber` field immediately.
# (migrate dev actually does this automatically, but it's good to know the standalone command)
npx prisma generate

# Step 3: Explore your data mid-development with Prisma Studio — a local browser UI.
# Useful for manually inspecting rows without writing throwaway scripts.
npx prisma studio
# Opens at http://localhost:5555

# ── SEEDING ───────────────────────────────────────────────────────────────────
# Run your seed script (defined in package.json under prisma.seed) to
# populate the DB with realistic test data after a fresh migration.
npx prisma db seed

# ── CI / PRODUCTION DEPLOYMENT ───────────────────────────────────────────────
# In your Dockerfile or CI pipeline, apply pending migrations non-interactively.
# This command NEVER creates new migrations — it only applies committed ones.
npx prisma migrate deploy

# ── CHECKING SYNC ─────────────────────────────────────────────────────────────
# If you suspect your DB is out of sync with your schema (e.g. a direct DB edit),
# this command shows the diff without making any changes. Read-only diagnostic.
npx prisma migrate status

Error Handling and Middleware in Prisma: Production Patterns

Prisma throws specific typed errors that you can catch and handle. The most common is PrismaClientKnownRequestError for constraint violations, unique failures, and foreign key issues. Others like PrismaClientValidationError catch invalid queries at runtime — useful in environments without TypeScript.

But error handling goes beyond try-catch. Prisma supports middleware via $use() — a function that intercepts every query before it executes. You can use this for logging, soft-deletes, audit trails, or even rewriting queries. Middleware is global and runs on every model unless you filter by action or model name.

A senior pattern: use middleware to automatically set updatedAt on every mutation, or to add tenant isolation filters. But beware — middleware runs in the same context as the request, so a blocking middleware kills performance. Keep middleware synchronous or use the deferred return pattern.

import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

// Middleware: intercept every 'find' operation to add a soft-delete filter.
// This pattern ensures deleted records are never returned without manual intervention.
prisma.$use(async (params, next) => {
  // Only apply to models that have a `deletedAt` field
  if (params.action === 'findUnique' || params.action === 'findMany' || params.action === 'findFirst') {
    // Add a condition to exclude soft-deleted records
    if (params.args && params.args.where) {
      params.args.where.deletedAt = null;
    } else {
      params.args = params.args || {};
      params.args.where = { deletedAt: null };
    }
  }

  return next(params);
});

// Example usage: errors from Prisma are typed, not strings.
async function createUserWithErrorHandling(email: string, name: string) {
  try {
    return await prisma.user.create({
      data: { email, name }
    });
  } catch (error) {
    if (error instanceof Prisma.PrismaClientKnownRequestError) {
      // Unique constraint violation — email already exists
      if (error.code === 'P2002') {
        console.error(`User with email ${email} already exists`);
        throw new Error('Duplicate email');
      }
      // Foreign key violation (e.g., ordering from non-existent user)
      if (error.code === 'P2003') {
        console.error('Referenced record does not exist');
        throw new Error('Invalid reference');
      }
    }
    throw error; // Re-throw unknown errors
  }
}

Prisma Studio: The Debugging Tool You Didn't Know You Needed

Prisma Studio is not a toy. It's a GUI that connects directly to your database through your schema, giving you a read-write interface to inspect and manipulate data without writing a single query. When you're debugging a production issue at 2 AM, you don't want to craft SQL joins — you want to see the rows, edit a field, and confirm the fix in seconds.

Run npx prisma studio and it opens a local web server. You can filter, sort, and edit records across all your models. It respects your schema constraints, so you won't accidentally create orphaned foreign keys. It also shows relation fields as clickable links — drill into a user's posts without writing a JOIN.

But here's the kicker: Prisma Studio is read-only by default for relations unless you explicitly allow writes. This prevents you from nuking a production table by accident. Use it for ad-hoc data exploration, not for migrations. And never, ever leave it running on a production server — it's a dev dependency, not a deployment.

// io.thecodeforge — database tutorial

// Start Prisma Studio (must be in project root with schema.prisma)
npx prisma studio

// Output: Prisma Studio is up on http://localhost:5555

// In Studio UI, you can:
// - Click any model to view all records
// - Use filter bar: WHERE title CONTAINS 'deploy'
// - Sort by createdAt DESC
// - Double-click a cell to edit
// - Click 'Add Record' to insert
// - Click a relation cell (e.g., authorId) to jump to parent

// Example: View all posts with their authors
// No SQL needed. Just click Post model, then click 'author' link.

// To exit: Ctrl+C in terminal

Querying Data: Why Your SQL Brain Needs a Reset

Prisma Client flips the script. You don't write queries — you call methods on generated types. This isn't magic, it's a compile-time guarantee. If your query compiles, it's valid against your schema. No runtime surprises from typos in column names.

Start with prisma.user.findMany() to get all users. Need filtering? Pass a where object: { email: { contains: '@corp.com' } }. Want related data? Use include or select to nest relations. But beware — overfetching with include is the #1 performance killer. Always prefer select to pull only the fields you need.

Here's the pattern that separates juniors from seniors: use where for filtering, orderBy for sorting, and take/skip for pagination. Never fetch 10,000 rows and filter in memory. That's how you burn your database connection pool and crash your app.

Pro tip: findUnique vs findFirst. findUnique requires a unique field (like @id or @unique) and returns null if not found. findFirst sorts and returns the first match even without uniqueness. Use findUnique for exact lookups, findFirst for fuzzy searches.

// io.thecodeforge — database tutorial

// Find all posts by a user, paginated, with author name
const posts = await prisma.post.findMany({
    where: {
        authorId: 'usr_abc123',
        published: true
    },
    select: {
        title: true,
        content: true,
        author: {
            select: { name: true }
        }
    },
    orderBy: { createdAt: 'desc' },
    take: 20,
    skip: 0
});

// Output (console.log):
[
    {
        title: 'Deploying Prisma to AWS Lambda',
        content: 'Step-by-step guide...',
        author: { name: 'Alice Chen' }
    },
    ... // 19 more posts
]

// findUnique vs findFirst example
const userById = await prisma.user.findUnique({
    where: { id: 'usr_abc123' }
});

const userByEmail = await prisma.user.findFirst({
    where: { email: { startsWith: 'alice' } }
});

Prisma Accelerate and Pulse: 2026 Platform Features

Prisma Accelerate and Pulse are two platform features introduced in 2026 to address common serverless challenges. Accelerate provides a global cache layer that reduces database load by caching query results at the edge, significantly lowering latency for read-heavy workloads. It integrates seamlessly with Prisma Client, requiring only a connection string change. Pulse, on the other hand, offers real-time database change streaming, enabling event-driven architectures without polling. Together, they help avoid connection pool exhaustion by offloading read traffic and reducing the number of concurrent connections needed.

To use Accelerate, replace your direct database URL with the Accelerate connection string in your Prisma schema. For example:

``prisma datasource db { provider = "postgresql" url = env("ACCELERATE_DATABASE_URL") } ``

Accelerate automatically caches queries based on configurable TTLs. Pulse requires setting up a subscription in your application code:

```typescript import { PrismaClient } from '@prisma/client' import { withPulse } from '@prisma/extension-pulse'

const prisma = new PrismaClient().$extends(withPulse())

async function main() { const stream = await prisma.user.subscribe() for await (const event of stream) { console.log('User changed:', event) } } ```

These features are particularly beneficial in serverless environments where connection pooling is limited. By caching frequent queries and streaming changes, you reduce the number of direct database connections, mitigating pool exhaustion. However, be mindful of cache invalidation and real-time data consistency requirements.

import { PrismaClient } from '@prisma/client'
import { withPulse } from '@prisma/extension-pulse'

const prisma = new PrismaClient().$extends(withPulse())

async function main() {
  // Accelerate: cached query
  const users = await prisma.user.findMany()

  // Pulse: real-time subscription
  const stream = await prisma.user.subscribe()
  for await (const event of stream) {
    console.log('User changed:', event)
  }
}

main().catch(console.error)

Prisma Migration Workflows: Production Best Practices

Managing database schema changes in production requires careful planning to avoid downtime and data loss. Prisma Migrate provides tools for safe evolution, but best practices are essential. First, always use a staging environment to test migrations before applying to production. Second, generate a migration file with prisma migrate dev and review the SQL output. For example, adding a column:

``sql ALTER TABLE "User" ADD COLUMN "age" INTEGER NOT NULL DEFAULT 0; ``

Third, use prisma migrate deploy in CI/CD pipelines to apply pending migrations atomically. For zero-downtime deployments, consider shadow databases: create a copy of the production schema, run migrations there, and then swap. Prisma Migrate supports shadow databases via the shadowDatabaseUrl in schema.

Another best practice is to avoid destructive changes like dropping columns or tables without a plan. Instead, use a multi-step approach: first add the new column, then backfill data, then deprecate the old column, and finally drop it in a future migration. Use prisma migrate resolve to mark migrations as applied if they were run manually.

Finally, monitor migration execution time. Long-running migrations can cause locks. Break large migrations into smaller steps. Use prisma migrate status to check the state of migrations in production. Always have a rollback plan: keep the previous migration file and know how to revert using prisma migrate resolve --rolled-back.

-- Example: Safe column addition
ALTER TABLE "User" ADD COLUMN "age" INTEGER NOT NULL DEFAULT 0;

-- Check migration status
-- Run: prisma migrate status

-- Apply migrations in production
-- Run: prisma migrate deploy

Prisma vs Drizzle ORM: Feature and Performance Comparison

When choosing an ORM for serverless applications, Prisma and Drizzle are two popular options. Prisma offers a declarative schema, auto-generated queries, and a rich ecosystem (Studio, Migrate, Accelerate). Drizzle is a lightweight, SQL-like ORM that gives you more control and often better performance due to less abstraction overhead.

Performance: Drizzle's query generation is typically faster because it produces raw SQL strings without an intermediate layer. Prisma's client has a runtime that adds latency, especially for simple queries. However, Prisma's caching via Accelerate can offset this for read-heavy workloads.

Features: Prisma provides a visual Studio, automatic migrations, and type-safe queries out of the box. Drizzle requires more manual setup but offers better support for raw SQL and complex joins. For example, a join in Prisma:

``typescript const usersWithPosts = await prisma.user.findMany({ include: { posts: true } }) ``

In Drizzle:

``typescript const usersWithPosts = await db.select().from(users).leftJoin(posts, eq(users.id, posts.userId)).execute() ``

Drizzle's syntax is closer to SQL, which can be more intuitive for developers with SQL experience. Prisma's schema-first approach enforces consistency but can be restrictive for advanced database features like partial indexes or custom types.

Serverless: Both support connection pooling via external tools (PgBouncer, Prisma Accelerate). Drizzle's smaller bundle size is advantageous for cold starts in serverless functions. Prisma's larger client can increase cold start times, but Accelerate mitigates this by reducing direct connections.

Conclusion: Choose Prisma for rapid development and built-in tooling; choose Drizzle for performance-critical, SQL-heavy applications where you need fine-grained control.

// Prisma: declarative, auto-generated
const usersWithPosts = await prisma.user.findMany({
  include: { posts: true }
})

// Drizzle: SQL-like, explicit joins
const usersWithPosts = await db.select().from(users)
  .leftJoin(posts, eq(users.id, posts.userId))
  .execute()