If you've built a TypeScript backend in the last few years, you've probably used Prisma. It earned its place as the default choice — a clean schema language, an intuitive query API, and type safety that felt almost magical at the time.

But the TypeScript ORM space has quietly matured. Drizzle emerged as a serious alternative for developers who felt Prisma was too opinionated. And ZenStack v3 just completed a full rewrite that positions it not just as an ORM, but as a full-stack data layer.

Three tools, three distinct bets on what "great database access" means in 2026. This post breaks them down so you can pick the right one for your project.

Disclosure: This post is published by the ZenStack team. We've done our best to represent Prisma and Drizzle fairly, but you should factor that context into how you weigh the comparisons.

1. The Three Philosophies​

Before comparing features and APIs, it helps to understand what each tool is actually optimizing for.

Prisma is schema-first and proud of it. You define your data model in a dedicated .prisma file, run a generator, and get a fully-typed client. The goal is maximum developer experience with minimum friction — you shouldn't need to think about SQL.

Drizzle takes the opposite bet. Your schema is TypeScript, your queries look like SQL, and the library stays thin on purpose. It does offer ORM-style queries too, but they feel more like a convenience layer on top of the SQL-first core than a first-class citizen. It trusts you to know what you're doing and gets out of the way. If you've ever felt ORMs were hiding too much, Drizzle is built for that instinct.

ZenStack starts where Prisma left off. It uses a Prisma-compatible schema language and a familiar query API, but expands the scope far beyond ORM territory — built-in access control, auto-generated CRUD APIs, frontend query hooks, and a plugin system for everything else. It's schema-first like Prisma, but engineered to cover much more of the full-stack surface area. On the API side, it gives you both ends of the query spectrum: an ORM API for day-to-day simplicity, and a SQL-style query builder (powered by Kysely) when you need precise control.

2. Data Modeling​

The way you define your schema shapes everything downstream — how you think about your data and how much type safety you get out of the box.

Let's use a simple but realistic example: a User that has many Posts, where each post has a published status.

Prisma uses its own schema language (PSL):

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  posts Post[]
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  published Boolean @default(false)
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int
}

Clean and readable, even to non-developers. Prisma generates a fully-typed client from this schema, giving you strong type inference across your entire codebase.

Drizzle keeps the schema in TypeScript — no separate file, no custom language:

import { pgTable, serial, text, boolean, integer } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: serial('id').primaryKey(),
  email: text('email').notNull().unique(),
});

export const posts = pgTable('posts', {
  id: serial('id').primaryKey(),
  title: text('title').notNull(),
  published: boolean('published').default(false),
  authorId: integer('author_id').references(() => users.id),
});

No magic, no code generation step. The schema is just TypeScript, which means your editor, your linter, and your CI pipeline all understand it natively.

ZenStack uses a superset of Prisma's schema language, called ZModel. If you're coming from Prisma, the model definitions are identical — in fact, renaming your .prisma file to .zmodel is a valid starting point:

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  posts Post[]

  @@allow('all', auth() == this)
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  published Boolean @default(false)
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int

  @@allow('read', published)
  @@allow('all', auth() == author)
}

The @@allow lines are access policies — more on those in section 4. The point here is that the data modeling syntax is familiar, and since ZenStack generates the same underlying database schema as Prisma, switching costs are low.

The takeaway: if your team prefers keeping everything in TypeScript, Drizzle wins on schema. If you want a dedicated, readable schema language, Prisma and ZenStack are effectively tied — with ZenStack gaining an edge as soon as access control or other advanced features enter the picture.

3. Querying​

Let's fetch something realistic: all published posts for a given user, including the author's email. Same query, three tools.

Prisma uses a nested object API that closely mirrors the shape of your schema:

const posts = await prisma.post.findMany({
  where: {
    authorId: userId,
    published: true,
  },
  include: {
    author: {
      select: { email: true },
    },
  },
});

Readable, predictable, and fully typed. The result shape is inferred automatically — posts[0].author.email is typed as string with no extra work. For the vast majority of queries, this API is a pleasure to use.

Drizzle expresses the same query in a style that will feel immediately familiar if you know SQL:

const posts = await db
  .select({
    id: postsTable.id,
    title: postsTable.title,
    authorEmail: usersTable.email,
  })
  .from(postsTable)
  .innerJoin(usersTable, eq(postsTable.authorId, usersTable.id))
  .where(and(eq(postsTable.authorId, userId), eq(postsTable.published, true)));

More verbose, but nothing is hidden. You control exactly which columns are selected, how joins are constructed, and what the result shape looks like. For developers who think in SQL, this reads naturally. For those who don't, it's a steeper mental overhead.

ZenStack offers both styles. The Prisma-compatible API works identically:

const posts = await db.post.findMany({
  where: {
    authorId: userId,
    published: true,
  },
  include: {
    author: {
      select: { email: true },
    },
  },
});

And when you need more control, you can drop down to the Kysely query builder, which gives you full SQL power and even better typing than Drizzle's:

const posts = await db.$qb
  .selectFrom('Post')
  .innerJoin('User', 'User.id', 'Post.authorId')
  .select(['Post.id', 'Post.title', 'User.email as authorEmail'])
  .where('Post.authorId', '=', userId)
  .where('Post.published', '=', true)
  .execute();

The ability to mix both styles in the same codebase — using the high-level API for routine queries and dropping to the query builder when precision matters — is one of ZenStack's more practical advantages.

The takeaway: Prisma's query API is the most approachable. Drizzle's is the most SQL-faithful. ZenStack covers both ends.

4. Access Control & Multi-Tenancy​

Access control is where the three tools diverge most sharply. Let's use a concrete rule: users can only read their own posts, and only published posts are visible to others.

Prisma has no built-in access control. You implement it manually, typically by adding where clauses wherever you query:

const posts = await prisma.post.findMany({
  where: {
    OR: [
      { authorId: userId },
      { published: true },
    ],
  },
});

This works, but it scales poorly. Every query is a new opportunity to forget a condition. In a large codebase with many developers and AI agents, enforcing consistent access rules this way requires discipline, code reviews, and a fair amount of trust.

Drizzle is in the same position — access control is entirely your responsibility:

const posts = await db
  .select()
  .from(postsTable)
  .where(
    or(
      eq(postsTable.published, true),
      eq(postsTable.authorId, currentUser.id)
    )
  );

Worth noting: PostgreSQL's Row-Level Security (RLS) is a viable alternative for both tools — Drizzle even has first-class modeling support for it. The trade-offs are real though: RLS policies are harder to write and test, add operational complexity, and can surprise developers who don't expect business logic at the database layer.

ZenStack treats access control as a first-class concern, defined once in the schema and enforced automatically at runtime. The enforcement is handled on the application level, so it works regardless of your database choice and doesn't require any special database features. You express policies declaratively in the schema using the @@allow and @@deny attributes:

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  published Boolean
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int

  // authors can do anything to their own posts
  @@allow('all', auth() == author)
  // published posts are visible to everyone
  @@allow('read', published)
}

With these policies in place, every query through a ZenStack client automatically respects them — no manual where clauses needed:

const authDb = db.$setAuth({ id: currentUser.id });
const posts = await authDb.post.findMany();

The trade-off: ZenStack's approach is more powerful but also more opinionated. You're trusting the policy engine to handle enforcement correctly, which requires learning its rules and edge cases. For simple applications, Prisma or Drizzle's manual approach may feel more transparent. For anything with real multi-tenancy requirements — SaaS products, team-scoped data, role-based access — the ZenStack model pays for itself quickly.

5. API & Framework Integration​

Writing database queries is only part of the story. In a full-stack TypeScript app, you also need to expose that data to your frontend — which typically means building an API layer on top of your ORM (unless you fully opt-in to server-side rendering). This is where the three tools have very different stories.

Prisma and Drizzle are both database libraries, not API frameworks. They have no opinion on how you expose data to the outside world. You write the API yourself — whether that's REST routes in Express, route handlers in Next.js, or a GraphQL resolver layer. This is the right call for many teams: full control, no surprises, no magic. The downside is that it's boilerplate you write and maintain for every project.

A typical Next.js route handler with Prisma/Drizzle looks like:

// API route for fetching published posts
export async function GET(request: Request) {
  const posts = await db.post.findMany({
    where: { published: true },
  });
  return Response.json(posts);
}

Straightforward, but multiply this across every model and every operation and it adds up fast.

ZenStack can follow the same pattern — you can use it exactly like Prisma and write your own routes. But it also offers an alternative: automatically mounting a full CRUD API directly from your schema, with access policies already enforced:

import { NextRequestHandler } from '@zenstackhq/server/next';
import { db } from '@/lib/db';
import { getSessionUser } from '@/lib/auth';

// API handler for all CRUD operations for all models, with access control enforced
const handler = NextRequestHandler({
  getClient: async (req) => db.$setAuth(await getSessionUser(req)),
});

export { handler as GET, handler as POST, handler as PUT, handler as DELETE };

That single file gives you a fully secured data API for every model in your schema — no additional route handlers needed. The access policies you defined in the schema are enforced automatically on every request.

On top of that, ZenStack can generate type-safe frontend hooks based on TanStack Query, so your client code can query your backend with the same query API as your server code, with zero manual wiring:

const client = useClientQueries(schema);
const { data: posts } = client.post.useFindMany({ where: { published: true } });

The trade-off is the usual one: more automation means more to understand when something doesn't behave as expected. But for teams building standard CRUD-heavy applications — which is most SaaS products — the reduction in boilerplate is substantial.

The takeaway: Prisma and Drizzle leave API design entirely to you, which is flexible but manual. ZenStack gives you the same escape hatch, but also offers a path where much of that layer is derived automatically from your schema and access policies.

6. Extensibility​

No ORM covers every use case out of the box. How easy it is to extend the tool — to add behaviors, generate artifacts, or customize runtime logic — matters more than most developers realize until they hit a wall.

Prisma has a generator-based plugin system that lets you participate in the prisma generate step. Although barely documented, this is useful for things like generating Zod schemas or ERD from your schema. For runtime extensibility, it offers Client Extensions — a mechanism for extending PrismaClient's behavior. It's a meaningful improvement but comes with many limitations that disqualify it as a full-fledged extensibility system.

Drizzle takes a different approach to this problem by not having a plugin system at all. Extensibility in Drizzle is just TypeScript — you compose queries, wrap functions, and build abstractions the same way you would with any library. There's no framework to learn, no hook points to find. This is genuinely freeing for experienced developers, but it also means every team reinvents the same patterns independently.

ZenStack was explicitly designed around extensibility as a core concern. Its plugin system operates at three distinct levels:

• Schema level — plugins can contribute new attributes, functions, and types to the ZModel language itself.
• Generation level — plugins participate in the zen generate step to produce any artifact from your schema.
• Runtime level — plugins can intercept and transform queries and results, enabling behaviors like soft deletes, field encryption, and audit logging to be implemented once and applied transparently across your entire data layer.

The trade-off: ZenStack's extensibility is structured. You work within its model, which has a learning curve. Drizzle's "extensibility" is just TypeScript, which will always feel more natural to developers who distrust frameworks. The right choice depends on whether you'd rather have powerful, opinionated building blocks or full freedom with no guardrails.

7. Performance​

Performance is a genuinely complex topic for ORMs — numbers vary significantly depending on the database, query complexity, connection pooling setup, and whether you're measuring cold starts or steady-state throughput. No single benchmark tells the full story, and synthetic tests rarely match real workload distributions.

That said, all three tools publish their own benchmark results, which are worth reviewing in context:

• Prisma: benchmarks.prisma.io
• Drizzle: orm.drizzle.team/benchmarks
• ZenStack: zenstack.dev/docs/orm/benchmark

If you're optimizing for raw throughput at scale, the official numbers are the right place to start — but for most applications, the differences likely won't be the deciding factor.

8. Ecosystem & Maturity​

Features and API design matter, but so does the world around a tool — community size, documentation quality, available integrations, and how confident you can be putting it in production.

Ecosystem & maturity comparison — as of early 2026

A few things worth expanding on:

• Prisma is the clear ecosystem leader. Years of adoption means more Stack Overflow answers, more community plugins, more starter kits, and more teammates who already know it. Documentation is among the best in the TypeScript ecosystem. The main concern is strategic: Prisma the company has increasingly shifted focus toward its hosted products (Prisma Postgres, Prisma Accelerate), and ORM innovation has slowed as a result.
• Drizzle has grown remarkably fast for a newer tool — evolving from a lightweight alternative into a serious contender, production adoption at scale, and performance numbers that matter for serverless and edge deployments. The community is active and vocal, and documentation has improved significantly.
• ZenStack is the youngest of the three by community size, and v3 — while stable — is a relatively recent release. The documentation is solid, and the Discord community is active and responsive. The plugin ecosystem is early but growing quickly; community-built plugins for real-time, caching, and tRPC already exist. Given its schema language and query API are both Prisma-compatible, it offers an easy migration path for Prisma users who desire a more lightweight, extensible, and feature-rich alternative.

One thing worth watching: Prisma has an experimental prisma-next project in development — a full TypeScript rewrite with a proper extension system, suggesting the team is aware of the extensibility gap. The ORM space is moving fast.

Conclusion: How to Choose​

No single tool wins across the board. The right choice depends on what your project actually needs. Here's a practical decision framework:

Choose Prisma if:

• You want the most mature ecosystem with the largest community
• Your team includes developers who aren't SQL-fluent and benefit from a high-abstraction query API
• You're already on Prisma and the missing features aren't blocking you — switching has real costs
• You want battle-tested tooling and don't care much about bundle size

Choose Drizzle if:

• You're comfortable with SQL and want your queries to reflect that
• You're deploying to serverless or edge runtimes where bundle size and cold start times matter
• You want maximum flexibility with no framework opinions imposed on you
• Your team prefers TypeScript-native everything, including schema definition

Choose ZenStack if:

• You're building a multi-tenant application, a SaaS product, or anything where access control is a first-class concern
• You want to reduce boilerplate across the full stack — from database to API to frontend hooks
• You're coming from Prisma and want a low-friction migration path with significantly more capability
• Your project would benefit from a schema that serves as a single source of truth for data, security, and API shape

Regarding team size: for solo developers or very small teams, any of the three works fine. As teams grow, ZenStack's declarative access control becomes increasingly valuable — the alternative is trusting every developer (or agent) to remember every where clause on every query, forever.

Greenfield vs. existing projects: if you're starting fresh, all three are equally viable starting points. If you're migrating an existing Prisma codebase, ZenStack offers a genuine migration path from Prisma without requiring a major rewrite.

The TypeScript ORM space in 2026 is healthier than it's ever been — you have real choices with real trade-offs, not just one obvious default. Whichever you pick, the official docs are the best starting point: Prisma, Drizzle, ZenStack.

We're in the "vibe coding" era. AI coding agents — Cursor, Claude Code, Copilot, Devin, and their growing kin — are no longer writing toy snippets. They're scaffolding entire features, refactoring modules, and wiring up API endpoints in seconds. The promise is intoxicating: describe what you want, get working code.

The reality is more nuanced. These agents are prolific, but not infallible. They hallucinate API signatures. They skip edge cases. They introduce subtle bugs that compile cleanly and pass a first glance. And crucially, they do all of this fast — far faster than any human code review can keep up with.

So here's the question that matters more than ever: what catches the mistakes an agent makes?

We Need a New Way to Evaluate a Stack​

For years, we've chosen tech stacks based on developer experience, ecosystem maturity, performance characteristics, and hiring pool. These criteria still matter. But a new dimension has entered the picture: how well does the stack constrain and verify AI-generated code?

Think about it this way. When a human writes code, they bring context, intuition, and institutional knowledge. They remember the auth check that needs to go on every endpoint. They know the subtle business rule about tenant isolation. An AI agent has none of that ambient awareness — it operates on whatever context it's given, and it fills in the gaps with statistical plausibility.

This means a tech stack is no longer just a productivity tool for humans. It's a safety net for agents. The right stack catches agent mistakes before they reach production. The wrong stack lets them sail through silently.

What Makes a Stack "Agent-Friendly"?​

There are three qualities that make a stack effective at catching agent errors:

1. Strong Type System = Compile-Time Guardrails​

This is the most obvious one, but it's worth stating clearly. A strong type system acts as a first line of defense against the kinds of errors agents commonly make.

Consider TypeScript vs. plain JavaScript. When an agent adds a new field to a data model, TypeScript propagates that change across the codebase — every function that touches that model lights up with type errors until it's updated. In plain JS, the agent might update the model and the handler it's currently looking at, while a dozen other consumers silently break.

The same principle applies to data access. A typed ORM like Prisma or Drizzle makes it structurally impossible to write queries that reference non-existent fields or use wrong types. Raw SQL strings? The agent can generate whatever it wants, and you won't know it's wrong until runtime — or worse, until a user hits the broken path in production.

The takeaway: types turn runtime surprises into compile-time errors. For human developers, that's nice. For AI agents generating code at speed, it's essential.

2. Declarative Rules Over Imperative Logic​

Here's where things get interesting. Consider how most web apps handle authorization. The typical pattern looks like this:

// In route handler A
if (user.role !== 'admin' && resource.ownerId !== user.id) {
  throw new ForbiddenError();
}

// In route handler B (slightly different check)
if (user.role !== 'admin' && resource.tenantId !== user.tenantId) {
  throw new ForbiddenError();
}

// In route handler C (oops, forgot the check entirely)
const data = await db.resource.findMany();

This is imperative authorization — the rules are expressed as code, scattered across dozens of files, with subtle variations that may or may not be intentional. Now imagine asking an AI agent to add a new endpoint. It needs to somehow infer the correct authorization pattern from examples, and apply it correctly. Sometimes it will. Sometimes it won't. And when it doesn't, you have a security vulnerability.

Now contrast this with a declarative approach:

model Resource {
  // ...fields

  @@allow('read', auth().role == 'admin' || tenantId == auth().tenantId)
  @@allow('update', auth().role == 'admin' || ownerId == auth().id)
}

The rules live in one place. They're structural, not behavioral. An agent literally cannot create an endpoint that bypasses them, because the access control is enforced at the data layer, not at the route level. The more business logic lives in declarations, the less room there is for agents to introduce inconsistencies.

3. Single Source of Truth for Data Shape and Rules​

AI agents perform best when context is concentrated, not scattered. This is a fundamental property of how large language models work — they reason over a context window, and the more relevant information fits within that window, the better their output.

Schema-first approaches shine here. When your data model, validation rules, and access policies all live in a single schema file, an agent can read that one file and understand the complete picture. Compare this to a codebase where the data models are in a bunch of migration files, validations are in a middleware folder, access rules are in a service layer, and business constraints are buried in utility functions. Even a skilled human developer struggles to hold all of that in their head. For an agent, it's nearly impossible.

The best stack for the AI era is one where the "spec" of your data layer fits in one place.

When the Safety Net Is Missing​

To make this concrete, here are failure modes we've seen (or narrowly avoided) with AI-generated code:

The forgotten auth check. An agent writes a new API endpoint for fetching user invoices. It follows the pattern of existing endpoints — proper input validation, clean error handling, nice response formatting. But it doesn't add an authorization check, because the auth logic isn't in the ORM layer or the route middleware — it's manually applied per handler, and the agent didn't infer the pattern from context. Result: any authenticated user can read any other user's invoices.

The inconsistent validation. Your app validates email format in a Zod schema inside the signup handler, but the profile update handler has its own inline regex check, and the admin user-creation endpoint has no email validation at all. An agent is asked to add a new "invite user" endpoint. It writes one — with a slightly different email regex copied from the profile handler. Now you have four endpoints, three different validation rules, and one with none. The inconsistency is invisible at compile time and slips right through tests that only check the happy path.

The wrong tenant scope. An agent is asked to add a data export feature. It copy-pastes a query pattern from another feature, but the original query was for a single-tenant context. The new feature runs in a multi-tenant context, and the agent doesn't apply the tenant filter. Result: data leakage across tenants.

The common thread in all of these: the failures happen when rules are implicit and scattered. No single file told the agent "every query must be tenant-scoped" or "every endpoint must check ownership." The rules existed only as patterns in the codebase, and patterns are exactly what LLMs approximate — imperfectly.

How ZenStack Acts as the Safety Net​

ZenStack is a TypeScript toolkit centered around a (Prisma-like) schema language called ZModel. In ZModel, you define your data model, access control rules, and validation constraints in a single file:

model Invoice {
  id        Int      @id @default(autoincrement())
  amount    Float    @gt(0)
  owner     User     @relation(fields: [ownerId], references: [id])
  ownerId   Int
  tenant    Tenant   @relation(fields: [tenantId], references: [id])
  tenantId  Int

  // Access rules: declarative, co-located with the model

  // no anonymous access
  @@deny('all', auth() == null)

  // can create for self in the context of a tenant
  @@allow('create', ownerId == auth().id && tenantId == auth().tenantId)

  // can read if in the same tenant
  @@allow('read', tenantId == auth().tenantId)

  // can update or delete if owner
  @@allow('update,delete', ownerId == auth().id)
}

From this single schema, ZenStack generates a type-safe, access-controlled database client. Here's what that means for AI agents:

• Authorization is structural. An agent can't "forget" to add an auth check because the check happens automatically at the data layer. Every query through ZenStack's enhanced client is filtered by the rules in the schema. The agent's job is just to write the query — the safety net handles the rest.

• The context is concentrated. An agent can read the ZModel file and understand the complete data model, relationships, access rules, and validation constraints. No hunting across files to piece together the full picture.

• Type safety propagates. The generated client is fully typed. If an agent writes a query that references a non-existent field or uses an invalid filter, TypeScript catches it before the code runs.

• Less code to generate, less to get wrong. ZenStack and its ecosystem can automatically derive CRUD APIs, TanStack Query hooks, Zod schemas, tRPC routers, OpenAPI specs, and more. Every auto-generated artifact is one less thing an agent needs to hand-write — and one less place for bugs to hide.

Going back to the failure modes above:

• Forgotten auth check? Can't happen — ZenStack's enhanced client enforces rules automatically.
• Inconsistent validation? Unlikely — validation rules live in the schema alongside the model, so every endpoint shares the same constraints automatically.
• Wrong tenant scope? The tenantId == auth().tenantId rule in the schema ensures every query is scoped correctly, regardless of which endpoint makes the query.

Shrink the Blast Radius​

The broader principle here isn't specific to ZenStack. It's this: the best stacks for the AI era minimize what can go wrong when code is generated at speed.

Think of type systems as guardrails on a highway. They don't slow you down — you can still drive at full speed. But they keep you from flying off a cliff when you drift. Declarative schemas, enforced access control, and auto-generated boilerplate are the same kind of guardrails, applied to the data and security layer — which is exactly where mistakes hurt the most.

The stacks that will thrive in the agent era share a common philosophy: make the right thing automatic, and the wrong thing impossible. The more of your application's correctness invariants that are expressed as declarations rather than scattered imperative code, the safer you are — whether the code is written by a human, an agent, or some combination of both.

Choose Stacks That Protect You From Speed​

AI agents are only getting faster and more autonomous. The question is no longer whether to use them — it's whether your stack can keep up safely. A good stack isn't just pleasant to work with. It absorbs the speed and imprecision of AI-generated code. It turns out that what's good for human developers is even better for AI agents: clear, concentrated, enforceable rules.

If you're evaluating your stack for the agent era, ask yourself: when an AI writes code against my data layer, what stops it from making a catastrophic mistake? If the answer is "code review" or "hoping the tests catch it," it might be time to add a stronger safety net.

Get started with ZenStack and see what a schema-first, safety-net-first stack looks like in practice.

Prisma won the hearts of many TypeScript developers with its excellent developer experience - the elegant schema language, the intuitive query API, and the unmatched type-safety. However, as time went by, its focus shifted, and innovation in the ORM space slowed down considerably. Many successful OSS projects indeed struggle to meet the ever-growing demands, but you'll be surprised to find that many seemingly fundamental features that have been requested for years are still missing today, such as:

• Define type of content of Json field #3219
• Support for Polymorphic Associations #1644
• Soft deletes (e.g. deleted_at) #3398

As a new challenger in this space, ZenStack aspires to be the spiritual successor to Prisma, but with a light-weighted architecture, a richer feature set, well-thought-out extensibility, and an easy-to-contribute codebase. Furthermore, its being essentially compatible with Prisma means you can have a smooth transition from existing projects.

A bit of history​

ZenStack began its journey as a power pack for Prisma ORM in late 2022. It extended Prisma's schema language with additional attributes and functions, and enhanced PrismaClient at runtime with extra features. The most notable enhancement is the introduction of access policies, which allow you to declaratively define fine-grained access rules in the schema had have them transparently enforced at runtime.

As we went deeper along the path with v1 and v2, we felt increasingly constrained by Prisma's intrinsic limitations. We decided to make a bold change in v3: build our own ORM engine (on top of the awesome Kysely) and migrate away from Prisma. To ensure an easy migration path, we've made several essential compatibility commitments:

• The schema language remains compatible with (and in fact a superset of) Prisma Schema Language (PSL).
• The resulting database schema remains unchanged, so no data migration is needed.
• The query API stays compatible with PrismaClient.
• Existing migration records continue to work without changes.

Dual API from a single schema​

PrismaClient's API is pleasant to use, but when you go beyond simple queries, you'll have to resort to raw SQL queries. Prisma introduced the TypedSQL feature to mitigate this problem. Unfortunately, it only solved half of the problem (having the query results typed), but you still have to write SQL, which is quite a drop in developer experience.

ZenStack v3, thanks to the power of Kysely, offers a dual API design. You can continue to use the elegant high-level ORM queries like:

const users = await db.user.findMany({
  where: { age: { gt: 18 } },
  include: { posts: true },
});

Or, when your needs outgrow its power, you can seamlessly switch to Kysely's type-safe, fluent query builder API:

const users = await db
  .$qb
  .selectFrom('User')
  .where('age', '>', 18)
  .leftJoin('Post', 'Post.authorId', 'User.id')
  .select(['User.*', 'Post.title'])
  .execute();

For most applications, you'll never need to write a single line of SQL anymore.

Battery included​

ZenStack aims to be a battery-included ORM and solve many common data modeling/query problems in a coherent package. Here are just a few examples of how far it's come in achieving this goal.

Built-in access control​

Every serious application needs non-trivial authorization. Wouldn't it be great if you could consolidate all access rules in the data model and never need to worry about them at query time? Here you go:

Schema:

model Post {
  id        Int     @id
  title     String
  published Boolean
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int

  @@deny('all', auth() == null)    // deny anonymous access
  @@allow('all', auth() == author) // owner has full access
  @@allow('read', published)       // published posts are publicly readable
}

Query:

async function handleRequest(req: Request) {
  // get the validated current user from your auth system
  const user = await getCurrentUser(req);

  // create a user-bound ORM client
  const userDb = db.$setAuth(user);

  // query with access policies automatically enforced
  const posts = await userDb.post.findMany();
}

Strongly typed JSON​

JSON columns are becoming increasingly popular in relational databases. Getting them typed is straightforward.

Schema:

model User {
  id      Int     @id
  profile Profile @json
}

type Profile {
  age Int
  bio String
}

Query:

const user = await db.user.findFirstOrThrow();
console.log(user.profile.age); // strongly typed

Polymorphic models​

Ever felt the need to model an inheritance hierarchy in the database? Polymorphic models come to the rescue.

Schema:

model Content {
  id        Int    @id
  title     String
  type      String

  // marks this model to be a polymorphic base with its
  // concrete type designated by the "type" field
  @@delegate(type)
}

model Post extends Content {
  content String
}

model Image extends Content {
  data Bytes
}

Query:

// a query with base automatically includes sub-model fields
const content = await db.content.findFirstOrThrow();

// the returned type is a discriminated union
if (content.type === 'Post') {
  // typed narrowed to `Post`
  console.log(content.content);
} else if (content.type === 'Image') {
  // typed narrowed to `Image`
  console.log(content.data);
}

These are just some of the existing features. More cool stuff like soft deletes, audit trails, etc., will be added in the future.

Extensible from the ground up​

ZenStack ORM comprises three main pillars - the schema language, the CLI, and the ORM runtime. All three are designed with extensibility in mind.

• The schema language allows you to add custom attributes and functions to extend its semantics freely. E.g., you can add an @encrypted attribute to mark fields that need encryption.

  attribute @encrypted()
  
  model User {
      id       Int    @id
      email    String @unique @encrypted
  }
  

• The ORM runtime allows you to add plugins that can intercept queries at different levels and modify their payload or entire behavior. For the example above, you can create a plugin that recognizes the @encrypted attribute and transparently encrypts/decrypts field values during writes/reads.

  const dbWithEncryption = db.$use(
    new EncryptionPlugin({
      algorithm: 'AES-256-CBC',
      key: process.env.ENCRYPTION_KEY,
    })
  );
  

• The CLI allows you to add generators that emit custom artifacts based on the schema. Think of generating an ERD diagram, or a GraphQL schema.

  plugin erd {
    provider = './plugins/erd-generator'
    output = "./erd-diagram.md"
  }
  

In fact, the access control feature mentioned earlier is entirely implemented with these extension points as a plugin package. The potential is limitless.

Simpler, smaller footprint​

ZenStack is a monorepo, 100% TypeScript project - no native binaries, no WASM modules. It keeps things lean and reduces deployment footprint. As a quick comparison, for a minimal project that uses Postgres database, the "node_modules" size difference (with npm install --omit=dev) is quite significant:

A simpler code base also makes it easier for the community to navigate and contribute.

Beyond ORM​

A feature-rich ORM can enable some very interesting new use cases. For example, since the ORM is equipped with access control, it can be directly mapped to a service that offers a full-fledged data query API without writing any code. You effectively get a self-hosted Backend-as-a-Service, but without any vendor lock-in. Check out the Query-as-a-Service documentation if you're interested.

Furthermore, frontend query hooks (based on TanStack Query) can be automatically derived, and they work seamlessly with the backend service.

All summed up, the project's goal is to be the data layer of modern full-stack applications. Kill boilerplate code, eliminate redundancy, and let your data model drive as many aspects as possible.

Conclusion​

ZenStack v3 is currently in Beta, and a production-ready version will land soon. If you're interested in trying out migrating an existing Prisma project, you can find a more thorough guide here. Make sure to join us in Discord, and we'd love to hear your feedback!

MCP is trending in AI, But…​

MCP(Model Context Protocol) is undoubtedly one of the most exciting trends in AI now. Not only is everyone talking about it, but everyone is also rushing to develop their version to secure a seat at the table of the AI era. Don't feel so? Guess how many MCP servers are listed in MCP Server Directory ?

The number is 4,684 now, and remember, MCP is just a six-month-old baby. However, have you noticed the one and only filter on the left:

Guess how many remain after applying this filter? Only 59—approximately 1% of the total. For those unfamiliar with this filter, I'll provide a brief explanation that you can skip if you already understand it.

MCP was initially conceived primarily as a protocol for local execution, where AI models could interact with local tools and data sources running on the same machine, like the example MCP FileSystem and Fetch listed in the official doc. It means you must install and run the MCP server on your local machine, regardless of whether the underlying transport is stdio or HTTP SSE. This design choice made sense in the early days, as it simplified security concerns and reduced latency. The protocol's simplicity made it perfect for developers to experiment with AI tool integration on their personal machines. However, as MCP gained traction and the AI ecosystem evolved, the need for secure remote execution became increasingly apparent:

With a remote MCP server, organizations expose their data and services to AI models over the internet, so the most important thing is Auth (authentication and authorization). Initially, this was addressed by asking users to generate an API key within the product and then configure it in the MCP settings. Here is an example from the Neon MCP server:

{
  "mcpServers": {
    "neon": {
      "command": "npx",
      "args": [
        "-y",
        "@neondatabase/mcp-server-neon",
        "start",
        "<YOUR_NEON_API_KEY>"
      ]
    }
  }
}

Developers are all familiar with this process. But as more and more SaaS products are providing the MCP server due to fear of death(search ‘SaaS is dead’ if you don't get it 😁), that's definitely not a good user experience for the non-developers. Moreover, users need to manually update the NPM package from time to time to stay current.

Kent raises the same concern in his tweet:

All the examples I see so far have the user generate a token and then put that token in the MCP configuration. Is that the best we have right now? I was hoping to find an example of an MCP client that supported an OAuth flow with a hosted MCP server.

The Advent of Authorization for MCP​

The MCP is young but is growing very fast. The OAuth support was introduced in March 2025, around the time he was 3 months old. Here are the Authorization flow steps in the official specification:

The specification comes with SDK support for both client and server, enabling more MCP servers to adopt and leverage it. Even some existing servers that rely on API keys are beginning to embrace the new modern solution. For example, the Neon MCP server mentioned above adds support for it, too.

{
  "mcpServers": {
    "Neon": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.neon.tech/sse"]
    }
  }
}

After adding the above MCP configuration, the MCP client will automatically open the browser to go through the standard OAuth process without needing the API key anymore:

With this modern MCP server, you can stop worrying about the PM or CEO showing up at your desk asking for help connecting to the MCP server of some SaaS product your company uses. Trust me, it happens. 😂

MCP Is a Good Enhancement for SaaS​

With the seamless experience of OAuth support, many companies are eager to provide an MCP server to enhance their existing product or service, especially within the SaaS landscape. Balancing flexibility and simplicity is always a core challenge for SaaS - too many buttons overwhelm users, too few constrain power users. For instance, I always love the clean and efficient UX/UI design of Trello:

However, it pricks me every time for certain routine jobs.

• How many cards were done last week?
• Who has the most incomplete cards?
• Which list has the most incomplete cards?

Trello doesn’t provide a direct way to show the answer; you have to do the math manually. This is where the MCP-LLM duo could provide a great solution to let user use natural language to get their job done. I think that’s the actual point that Microsoft CEO Satya Nadella was trying to convey in his presumed “SaaS is dead” interview.

Two Approaches to Building an MCP Server​

1. Relying on the Existing API​

This seems like the obvious choice. However, since those APIs were most likely designed a long time before the LLM was born, they might not be suitable for the LLM to consume. One thing is that the semantics of the parameters and return data might not be self-explanatory enough for the LLM to understand; The other thing is that the API might not be flexible enough to provide the functionality to support what the user wants to achieve.

2. Start from Scratch​

For those considering this approach, the biggest concern is probably time. Don’t worry, we never really build from scratch, do we? The MCP is evolving fast, and so is the whole ecosystem. Let me show you the modern stack that could dramatically reduce the code you need to write to speed it up.

• MCP TypeScript SDK

  It fully implements the MCP specification, including Authorization. It provides a strong abstraction, freeing you from wrestling with low-level protocol implementation so you can focus on the business logic.

• ZenStack

  ZenStack is a schema-first TypeScript toolkit on top of Prisma ORM. The core part is a ZModel DSL that unifies data modeling and access control. Here is an example of what a simple blog post looks like:

  model User {
    id            Int                 @id @default(autoincrement())
    email         String              @unique
    name          String?
    password      String              @password @omit
    posts         Post[]
  
    @@allow('read', true)
  }
  
  model Post {
    id        Int      @id @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
    title     String
    content   String?
    published Boolean  @default(false)
    viewCount Int      @default(0)
    author    User?    @relation(fields: [authorId], references: [id])
    authorId  Int?     @default(auth().id)
  
    @@allow('all', auth() == author)
    // logged-in users can view published posts
    @@allow('read', auth() != null && published)
  }
  

  Based on the ZModel schema, ZenStack automatically creates well-structured, type-safe, and authorized CRUD APIs for your database. MCP's core value lies in its tools, which fundamentally consist of schema definitions and executable operations—specifically, the CRUD operations on your database for most SaaS applications. ZenStack can generate both directly from its schema, which can be safely called by LLM thanks to the access control policy. Thus, your primary task is to define the schema, and ZenStack manages everything else.

Building an MCP Server from Scratch​

So let me walk you through the process of turning your database into an MCP server with OAuth-based authentication and authorization from scratch. I will use the blog post mentioned above as a sample; you can adapt it for your app, and all you need to do is change the ZModel schema accordingly.

You can find the final running project below:

https://github.com/jiashengguo/zenstack-mcp-auth

Initialize the Project​

Use the below script to initialize a project with Prisma and Express:

npx try-prisma@latest -t orm/express -n blog-app-mcp

Install the MCP SDK, bcrypt(used to hash password):

npm install @modelcontextprotocol/sdk, bcrypt, @types/bcrypt

Initialize ZenStack:

npx zenstack@latest init

Auth​

To support the OAuth, the server needs to store the following information:

• OAuth Client
• Authorization Code
• Access Token
• Refresh Token

So let’s add them in the ZModel schema file so that we can use the generated type-safe API to operate on them:

model OAuthClient {
  id                       Int      @id @default(autoincrement())
  client_id                String   @unique
  client_secret            String?
  ...
}

model AuthorizationCode {
  id            Int      @id @default(autoincrement())
  code          String   @unique
  ...
}

model AccessToken {
  id        Int      @id @default(autoincrement())
  token     String   @unique
  ...
}

model RefreshToken {
  id        Int      @id @default(autoincrement())
  token     String   @unique
  ...
}

According to the MCP specification, here are the three endpoints that the server must implement:

MCP SDK provides a utility function, mcpAuthRouter, to install these standard authorization server endpoints. What we need to do is implement an OAuthServerProvider to pass it to the mcpAuthRouter.

Let’s create an AuthMiddleware class to handle all the Auth logic, and a PasswordAuthProvider implementing the OAuthServerProvider to do the actual logic.

export class AuthMiddleware {
   private authProvider: PasswordAuthProvider;
   private authRouter: express.Router = express.Router();
   ...
    private setupRouter() {
        // Add OAuth router using the mcpAuthRouter function
        this.authRouter.use(
            '/',
            mcpAuthRouter({
                provider: this.authProvider,
                issuerUrl: new URL(config.baseUrl),
                baseUrl: new URL(config.baseUrl),
                scopesSupported: ['read', 'write'],
            })
        );
        ...
    }
}

PasswordAuthProvider​

Here are the three functions that will actually be called, corresponding to the three necessary endpoints mentioned above:

export interface OAuthServerProvider {
		// /register
    get clientsStore(): OAuthRegisteredClientsStore;
    
    // /authorize
    authorize(client: OAuthClientInformationFull, params: AuthorizationParams, res: Response): Promise<void>; 

    // /token
    exchangeAuthorizationCode(client: OAuthClientInformationFull, authorizationCode: string, codeVerifier?: string, redirectUri?: string): Promise<OAuthTokens>;
}

The clientStore deals with register and read through registerClient and getClient functions, it simply writes and reads the OAuthClient model from the database.

The actual authorization flow begins with authorize. Its job is to redirect to the actual authorization server with all the necessary parameters. Since in our case, the authorization server is itself, let’s redirect to the/auth/login path:

      const loginUrl = new URL('/auth/login', config.baseUrl);
      ...
      res.redirect(loginUrl.toString());

Therefore, we need to create a login.html to serve it. It’s a typical login form like below:

After clicking Login, it combines all the URL parameters passed from the authorization flow along with the email and passwords to post to the server endpoint /auth/login.

The server endpoint /auth/login would eventually call into the function handlelogin of PasswordAuthProvider. It verifies the user identity. If it is correct, then create an auth code, return to the client, and store it in an AuthorizationCode instance in the database

  // Generate authorization code
  const authCode = crypto.randomBytes(32).toString('hex');

  // Store authorization code in database
  await this.prisma.authorizationCode.create({
      data: {
          code: authCode,
          clientId,
          userId: user.id,
          codeChallenge,
          redirectUri,
          expiresAt: new Date(Date.now() + 600000), // 10 minutes
          scopes,
      },
  });

After getting the auth code returned from the server, login.html will redirect to the MCP client with the auth code. Finally, the MCP client will use the auth code to call the /token endpoint to exchange for the access token, which will call into the exchangeAuthorizationCode function.

In exchangeAuthorizationCode, the server will first verify that the auth code it just granted is valid, and the client’s identification, such as PKCE. If everything is correct, it will generate both access token and refresh token, store them in the database, and return to the MCP client.

// Store tokens in database
await this.prisma.accessToken.create({
    data: {
        token: accessToken,
        clientId: client.client_id,
        userId: authData.userId,
        scopes: authData.scopes as any,
        expiresAt,
    },
});

await this.prisma.refreshToken.create({
    data: {
        token: refreshToken,
        clientId: client.client_id,
        userId: authData.userId,
        scopes: authData.scopes as any,
        expiresAt: new Date(Date.now() + 86400 * 30 * 1000), // 30 days
    },
});

// Clean up authorization code
await this.prisma.authorizationCode.delete({
    where: { code: authorizationCode },
});

return {
    access_token: accessToken,
    token_type: 'Bearer',
    expires_in: expiresIn,
    refresh_token: refreshToken,
    scope: (authData.scopes as string[]).join(' '),
};

Stateful Multi-connections Streamable HTTP Server​

After the MCP client gets the access token, each time it communicates with the server through the main endpoint, it will put the access token in the Authorization header. The server should use it to verify the client and get the client’s identity. Let’s choose the conventional /mcp endpoint as the main endpoint and getFlexibleAuthMiddleware to do so.

The first request sent by the MCP client to the server is an initialize request. The server should respond with server information and a generated session ID, which the client would always include to maintain the session. As a production-ready MCP server, it definitely should support multiple simultaneous connections. Therefore, we use a map to store each client by its session ID.

const transports: { [sessionId: string]: StreamableHTTPServerTransport } = {};

To manage the session for each user, we will create a dedicated MCPServer for it. Since it’s per user per MCP server, we could store the userId in it, which will be used for Authorization when executing tools.

if (sessionId && transports[sessionId]) {
    transport = transports[sessionId];
  } 
else if (!sessionId && isInitializeRequest(req.body)) {
    // Handle new MCP connection initialization
    transport = new StreamableHTTPServerTransport({
        sessionIdGenerator: () => crypto.randomUUID(),
        onsessioninitialized: (sessionId: string) => {
            console.log(`New MCP session initialized: ${sessionId}, User ID: ${userId}`);
            transports[sessionId] = transport!;
        },
    });

    const mcpServer = createMCPServer(userId);
    await mcpServer.connect(transport);
    console.log(`MCP server connected for User ID: ${userId}`);
    // Handle connection close
    transport.onclose = () => {
        if (transport?.sessionId) {
            console.log(`MCP session closed: ${transport.sessionId}`);
            delete transports[transport.sessionId];
        }
    };
}
else {
  // invalid request
  ...
}
// Handle the request
await transport.handleRequest(req, res, req.body);

Tool​

We will fully rely on the ZenStack to do the job. Remember the two parts of the Tool: schema and execution.

Schema​

ZenStack has a native Zod plugin to generate the Zod schema for its CRUD API. We can enable it by adding the one below to the schema.zmodel :

plugin zod {
    provider = '@core/zod'
}

Then, after running zenstack generate, it generates the Zod schema for all the operations it supports for every model in @zenstackhq/runtime/zod/input. For example, this is the one for Post :

import { z } from 'zod';
import type { Prisma } from '.zenstack/models';
declare type PostInputSchemaType = {
    findUnique: z.ZodType<Prisma.PostFindUniqueArgs>;
    findFirst: z.ZodType<Prisma.PostFindFirstArgs>;
    findMany: z.ZodType<Prisma.PostFindManyArgs>;
    create: z.ZodType<Prisma.PostCreateArgs>;
    createMany: z.ZodType<Prisma.PostCreateManyArgs>;
    delete: z.ZodType<Prisma.PostDeleteArgs>;
    deleteMany: z.ZodType<Prisma.PostDeleteManyArgs>;
    update: z.ZodType<Prisma.PostUpdateArgs>;
    updateMany: z.ZodType<Prisma.PostUpdateManyArgs>;
    upsert: z.ZodType<Prisma.PostUpsertArgs>;
    aggregate: z.ZodType<Prisma.PostAggregateArgs>;
    groupBy: z.ZodType<Prisma.PostGroupByArgs>;
    count: z.ZodType<Prisma.PostCountArgs>;
};

So each operation for each model will become a Tool of our MCP server.

Execution​

The execution of each function is very straightforward; just dynamically invoke the function with the argument generated by the LLM. Therefore, the whole Tool creating logic is simply one lambda expression in less than 30 lines of code:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import crudInputSchema from '@zenstackhq/runtime/zod/input';
...
export function createMCPServer(userId: number) {
    const server = new McpServer(
        ...
    )
    Object.entries(crudInputSchema)
        .filter(([name]) => modelNames.includes(getModelName(name)))
        .forEach(([name, functions]) => {
            const modelName = getModelName(name);

            Object.entries(functions as Record<string, any>)
                .filter(([functionName]) => functionNames.includes(functionName))
                .forEach(([functionName, schema]) => {
                    const toolName = `${modelName}_${functionName}`;
                    server.tool(
                        toolName,
                        `Prisma client API '${functionName}' function input argument for model '${modelName}'. ${currentUserPrompt}`,
                        {
                            args: schema,
                        },
                        async ({ args }) => {
                            console.log(`Calling tool: ${toolName} with args:`, JSON.stringify(args, null, 2));
                            const prisma = getPrisma(userId);
                            const data = await (prisma as any)[modelName][functionName](args);
                            console.log(`Tool ${toolName} returned:`, JSON.stringify(data, null, 2));
                            return {
                                content: [{ type: 'text', text: JSON.stringify(data, null, 2) }],
                            };
                        }
                    );
                });
        });

    return server;
}

One thing that needs to be mentioned is that the Prisma client that is used to call that operation is the ZenStack-enhanced one that contains the current user identity, which is the userId stored in the MCPServer during initialization. This will completely eliminate unauthorized data access, no matter what parameters LLM generates for the function, even if hallucination happens:

import { enhance } from '@zenstackhq/runtime';
// Gets a Prisma client bound to the current user identity
export function getPrisma(userId: number | null) {
    const user = userId ? { id: userId } : undefined;
    return enhance(prisma, { user });
}

There is another benefit that since these Tools are actually the standard Prisma Client API, it works well for the LLM:

• First, its declarative and well-structured nature makes it easy to understand and reason about, allowing LLMs to generate accurate and predictable queries with minimal ambiguity
• Second, the API's flexibility allows one single call to access multiple models (database tables), enabling LLMs to efficiently navigate complex data relationships and perform sophisticated queries across different entities without requiring separate API calls or complex orchestration logic.
• Third, Prisma has been widely adopted for years, providing a rich ecosystem of documentation, examples, and community usage that LLMs can learn from—greatly increasing the chance of generating correct and context-aware code.

Test​

The sample project includes seed data for you to play around with. Simply run the below command to make it ready:

npx prisma db push
npx prisma db seed

It creates three users with posts. The passwords for all users are password123.

• alex@zenstack.dev
• sarah@stripe.com
• jordan@vercel.com

Enjoy playing it with whatever MCP client of your choice:

I’m really eager to hear about the results you achieved with your application! If you’re looking for any tips on writing the ZModel schema, please feel free to reach out to me or hop onto our Discord. I’m always willing to help!

Is SaaS Really Dead?​

Several months ago, the internet was abuzz with the Microsoft CEO Satya Nadella saying, “SaaS is dead.”

The conversation started with a question from Bill Gurley about whether Satya was worried that newer startups are building applications with an AI-first approach, which could obfuscate traditional infrastructure like Excel or CRM. Here is Satya’s response:

I think, the notion that business applications exist, that's probably where they'll all collapse, right in the agent era because if you think about it, right, they are essentially CRUD databases with a bunch of business logic. The business logic is all going to these agents, and these agents are going to be multi repo CRUD

Some people might assume he suggested that AI agents could or would replace SaaS. However, if you watch the entire podcast, you'll understand that he's actually discussing how AI agents will transform SaaS rather than replace it:

How? Let me share an example from my experience. At my previous company, we used Trello for project management. I was impressed by its clean and efficient UX design.

However, one drawback that consistently bothered me was the lack of flexibility in performing queries. For instance:

• How many cards were done last week?
• Who has the most incomplete cards?
• Which list has the most incomplete cards?

Trello doesn't provide a direct way to show the answer; you'll need to do the math manually. I understand that offering such flexibility from a UI design perspective is challenging, yet each encounter often brings a sigh of frustration. 😮‍💨

Balancing flexibility and simplicity is a core challenge for SaaS. This is where an AI agent can play a role. The most straightforward solution is to introduce a chatbot that can easily provide answers to all the questions mentioned, without altering any existing features.

Challenge of Building an AI Chatbot​

We are all aware of the hallucinations that AI causes. But there is another level of hallucination:

AI makes many things seem easily accomplished on the surface, but you will see the challenge under the iceberg when it comes to production.

My previous company tried to integrate a chat agent into their SaaS product, and was struggling with those challenges:

1. LLM Failed to Generate the Correct API Call

   The initial plan was to have the LLM generate an API call directly based on user input. However, probably because the existing API is not well designed, LLM often struggles to interpret and generate the correct parameters. Sometimes, it even calls the wrong API.

2. The Complexity of Transforming the LLM Result

   Since the initial plan fails, they ask LLM to create the intermediate structured query object, then use code to convert this object into an actual database query. The good thing is that it is the code that makes the final call; the bad thing is that the code can become highly complex as it needs to account for all possible cases the LLM might produce.

   One critical issue that needs to be addressed is authorization. You have to scrutinize and ensure the generated query doesn’t break the authorization rule of the current system, which can sometimes be quite complex. Any oversight could lead to significant security breaches, potentially disastrous for a B2B SaaS.

The fundamental issue seems to be that the current infrastructure is not friendly enough for AI agents, as Bill questioned Satya. So, what type of infrastructure would be suitable for AI?

Schema-First Fit AI-First​

Among all the discussions regarding Satya’s statement:

They are essentially CRUD databases with a bunch of business logic.The business logic is all going to these agents.

Many people focus solely on the business logic that will be handled by the agent, often neglecting the essential prerequisite: the CRUD database. In other words, AI must accurately and precisely translate the business logic to the CRUD operation to ensure success. This is where the challenges arise, as illustrated in the previous example. It seems there is a missing layer that focuses on 'what' rather than 'how' to make AI better work: a schema. AI excels at declarative schemas over imperative code. Therefore, if we could make the CRUD database a well-designed schema for AI to manipulate, that could provide a robust foundation for the mission to be done.

The ZenStack schema-first toolkit is well-suited for the task. The core part is a DSL that unifies data modeling and access control, two essential parts of CRUD databases. Here is an example of what a simple blog post looks like:

enum Role {
    USER
    ADMIN
}

model Post {
    id        String  @id @default(cuid())
    title     String
    published Boolean @default(false)
    author    User    @relation(fields: [authorId], references: [id])
    authorId  String  @default(auth().id)

    @@allow('all', auth() == author)
    @@allow('read', auth() != null && published )
    @@allow('read', auth().role == 'ADMIN')
}

model User {
    id       String  @id @default(cuid())
    email    String? @unique
    password String  @password @omit
    role     Role    @default(USER)
    posts    Post[]

    @@allow('create,read', true)
    @@allow('update,delete', auth() == this)
}

Based on the schema, ZenStack automatically generates well-structured, type-safe, and authorized CRUD APIs to the database. Not only can AI understand and manipulate it better with less chance of hallucination, but also developers will be able to build the AI agent on top of it easily.

I know talk is cheap, so let me show you the code!

Building an AI Chatbot from Scratch​

Let’s build an AI chatbot for a Todo app to address the pain points of Trello earlier. To keep this concise, I'll focus on the key steps. You can find the link to the completed project on GitHub at the end of the post. Here is the final outcome:

Here is the tech stack we are using:

• Next.js - React framework
• ZenStack - Full-stack toolkit with access control
• NextAuth - Authentication for Next.js
• AI SDK - AI integration for chat features

1. Creating the project​

Create a Next.js project with create-t3-app with Prisma, NextAuth, and TailwindCSS:

npx create-t3-app@latest --prisma --nextAuth --tailwind --appRouter --CI todo-ai

2. Initialize the project for ZenStack​

Run the zenstack CLI to prepare your project for using ZenStack.

npx zenstack@latest init

Replace the schema.zmodel with the below content:

generator client {
    provider = "prisma-client-js"
}

datasource db {
    provider = "sqlite"
    url      = env("DATABASE_URL")
}

plugin zod {
    provider = '@core/zod'
}

/*
 * Model for a Todo list
 */
model List {
    id        String   @id @default(uuid())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
    owner     User     @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId   String   @default(auth().id)
    title     String   @length(1, 100)
    private   Boolean  @default(false)
    todos     Todo[]
    // can be read by owner or space members (only if not private) 
    @@allow('read', !private)

    // owner can do anything
    @@allow('all', owner == auth())
}

/*
 * Model for a single Todo
 */
model Todo {
    id          String    @id @default(uuid())
    createdAt   DateTime  @default(now())
    updatedAt   DateTime  @updatedAt
    owner       User      @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId     String    @default(auth().id)
    list        List      @relation(fields: [listId], references: [id], onDelete: Cascade)
    listId      String
    title       String    @length(1, 100)
    completedAt DateTime?

    // full access if the parent list is readable
    @@allow('all', check(list, 'read'))
}

model User {
    id       String  @id @default(cuid())
    name     String?
    email    String? @unique
    password String  @password @omit
    todo     Todo[]
    list     List[]

    // everyone can signup, and user profile is also publicly readable
    @@allow('create,read', true)
    // only the user can update or delete their own profile
    @@allow('update,delete', auth() == this)
}

This represents a multi-user Todo app. Todo list can be private or public; list owners have full control over their list. If a user can see the list, they can manipulate all the todos under that list.

3. Implement Signup/Signin​

The tasks here are configuring NextAuth to use credential-based auth and creating the signup/signin form. Check out the code for details.

4. Implement the chatbot logic with Vercel AI SDK and ZenStack​

We will primarily utilize the AI SDK to develop the chatbot. It not only standardizes integration across various LLM providers but also offers a range of hooks for creating chat and generative user interfaces. With that, building a chatbot with real-time message streaming requires just a few lines of code. Here is the official doc.

Simply put, it provides a userChat hook for the client and a corresponding server endpoint in src/app/chat/route.ts. I will skip the UI part and focus on implementing the endpoint, which is essentially the complete functionality of this bot.

Every AI agent typically consists of two components: Tools and Prompts. As previously discussed, Tools in this context refer to the CRUD APIs of the database. So let’s see how it is getting implemented.

The AI SDK allows Zod Schema to be used to define the parameters of the Tool. So, have you noticed a Zod plugin defined in the schema.zmodel ?

plugin zod {
    provider = '@core/zod'
}

This is a ZenStack native plugin that generates Zod schemas for models and input arguments of Prisma CRUD operations. For instance, it will generate the CRUD schema for every model as below:

declare type TodoInputSchemaType = {
    findUnique: z.ZodType<Prisma.TodoFindUniqueArgs>;
    findFirst: z.ZodType<Prisma.TodoFindFirstArgs>;
    findMany: z.ZodType<Prisma.TodoFindManyArgs>;
    create: z.ZodType<Prisma.TodoCreateArgs>;
    createMany: z.ZodType<Prisma.TodoCreateManyArgs>;
    delete: z.ZodType<Prisma.TodoDeleteArgs>;
    deleteMany: z.ZodType<Prisma.TodoDeleteManyArgs>;
    update: z.ZodType<Prisma.TodoUpdateArgs>;
    updateMany: z.ZodType<Prisma.TodoUpdateManyArgs>;
    upsert: z.ZodType<Prisma.TodoUpsertArgs>;
    aggregate: z.ZodType<Prisma.TodoAggregateArgs>;
    groupBy: z.ZodType<Prisma.TodoGroupByArgs>;
    count: z.ZodType<Prisma.TodoCountArgs>;
};

Therefore, all we need to do is convert each CRUD operation to an AI SDK tool. Let’s create a createToolsFromZodSchema function iterates all the models:

import prismaInputSchema from "@zenstackhq/runtime/zod/input";
import { type Tool, tool, zodSchema } from "ai";

async function createToolsFromZodSchema(prisma: PrismaClient) {
  const tools: Record<string, Tool> = {};
  const functionNames = ["findMany", "createMany", "deleteMany", "updateMany"];
  for (const [inputTypeName, functions] of Object.entries(prismaInputSchema)) {
    // remove the postfix InputSchema from the model name
    const modelName = inputTypeName.replace("InputSchema", "");
    for (const [functionName, functionSchema] of Object.entries(
      functions,
    ).filter((x) => functionNames.includes(x[0]))) {
      const functionParameterType = zodSchema(
        functionSchema as z.ZodObject<z.ZodRawShape>,
        {
          useReferences: true,
        },
      );
      tools[`${modelName}_${functionName}`] = tool({
        description: `Prisma client API '${functionName}' function input argument for model '${modelName}'`,
        parameters: functionParameterType,
        execute: async (input: unknown) => {
          console.log(
            `Executing ${modelName}.${functionName} with input:`,
            JSON.stringify(input),
          );
          // eslint-disable-next-line
          return (prisma as any)[modelName][functionName](input);
        },
      });
    }
  }

The execute function inside is quite simple, just invoke the corresponding prisma client API function using the passed in PrismaClient object. Here comes the most crucial part, which is also the most exciting part of ZenStack:

The PriamClient object should be the enhanced Prisma client that contains the current user identity instead of the regular Prisma client:

export async function POST(req: Request) {
  // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment
  const { messages }: { messages: CoreMessage[] } = await req.json();

  const authObj = await auth();
  const enhancedPrisma = enhance(db, { user: authObj?.user });
  const tools = await createToolsFromZodSchema(enhancedPrisma);
  ...
}

The benefit is that no matter what parameters AI generates for a function, you never have to worry about unauthorized access. This is because the access policy defined in the schema will always be injected under the hood before reaching the database.

The system prompt is straightforward and general; you can review the code and tailor it to suit your specific requirements.

Thanks to the AI SDK and ZenStack, the entire server implementation of this chatbot was completed in less than 100 lines of code! Even more impressive, this implementation is completely app-agnostic. In other words, regardless of your app (zmodel), it works seamlessly.

So if you're a ZenStack user, you now know the best practice for implementing an AI Chatbot. 😉

Try It for Your Own Application​

Here is the final project that you can run directly:

https://github.com/jiashengguo/zenstack-ai-chatbot

The benefit is that you can easily test this AI chat agent for your own application — all you need to do is customize schema.zmodel to fit your application.

I would love to hear your feedback on it!

In the previous post, we discussed the new extensibility opportunities of the core ORM by adopting Kysely. In this post, we'll continue exploring the plan for v3's new plugin system that allows you to deeply customize ZenStack's behavior in a clean and maintainable way.

Plugin Composition​

ZenStack v2 provided a rudimentary plugin system that allows you to participate in the process of zenstack generate. It's sufficient for use cases like generating OpenAPI specs or TanStack Query hooks. However, there's no well-defined way to extend the ORM's runtime behavior in a pluggable way.

V3 aims to provide a more complete plugin system that allows you to contribute at the schema, generation, and runtime levels. A plugin can include the following parts:

1. A plugin.zmodel file that can define attributes, functions, procedures, etc. V2 already offers this. When running zenstack generate, all ZModel contributions from plugins will be merged with the user ZModel files.

2. A generator function that's called during generation V2 already offers this. The function will be called at zenstack generate time and given the ZModel AST (and potentially the Prisma DMMF too, TBD) as input. The generator can interpret attributes, functions, etc. defined in plugin.zmodel.

3. A runtime plugin class that implements various callbacks This provides great flexibility for a plugin to hook into the ORM's lifecycle at various levels - more about this in the next section.

Runtime Plugin​

A runtime plugin is an object satisfying the following interface. It may look a bit complex because it contains callbacks for different purposes. Don't worry, we'll dissect them shortly.

interface RuntimePlugin {
  /**
   * Plugin ID.
   */
  id: string;

  /**
   * Intercepts an ORM query.
   */
  onQuery?: (
    args: PluginContext,
    proceed: ProceedQueryFunction
  ) => Promise<unknown>;

  /**
   * Kysely query transformation.
   */
  transformKyselyQuery?: (
    args: PluginTransformKyselyQueryArgs
  ) => RootOperationNode;

  /**
   * Kysely query result transformation.
   */
  transformKyselyResult?: (
    args: PluginTransformKyselyResultArgs
  ) => Promise<QueryResult<UnknownRow>>;

  /**
   * This callback determines whether a mutation should be intercepted, and if so,
   * what data should be loaded before and after the mutation.
   */
  mutationInterceptionFilter?: (
    args: MutationHooksArgs
  ) => MaybePromise<MutationInterceptionFilterResult>;

  /**
   * Called before an entity is mutated.
   */
  beforeEntityMutation?: (
    args: PluginBeforeEntityMutationArgs
  ) => MaybePromise<void>;

  /**
   * Called after an entity is mutated.
   */
  afterEntityMutation?: (
    args: PluginAfterEntityMutationArgs
  ) => MaybePromise<void>;
}