superapp vs ZenStack

Both superapp and ZenStack solve a similar problem: giving full-stack TypeScript apps a secure data layer with declarative access control. They take fundamentally different approaches to get there.

This page provides an honest, detailed comparison so you can choose the right tool for your project.

Summary

Key Differences

1. Architecture

superapp acts as a middleware proxy. Your frontend sends parameterized SQL (via Drizzle Proxy protocol) to the superapp backend, which authenticates, applies permission filters, executes the query through DuckDB, and returns results. The authorization logic lives entirely on the server and is invisible to the client.

ZenStack operates as an ORM enhancement. You create an "enhanced" ORM client by wrapping the base client with enhance(client, { user }). This enhanced client transparently injects WHERE clauses and validates writes based on policies declared in the schema. The authorization logic runs wherever the ORM client runs (server-side).

Pros and Cons

2. Schema and Configuration

superapp uses pure TypeScript for everything. Permissions, roles, database connections, and auth are all configured in a single createEngine() call. No custom DSL, no code generation step for the permission layer.

// superapp: TypeScript config
const engine = createEngine({
  connections: {
    main: { type: 'postgres', url: process.env.PG_URL! },
  },
  permissions: {
    view_own_orders: {
      table: 'main.orders',
      operations: { select: true },
      filter: { customer_id: { $eq: '$user.id' } },
    },
  },
  roles: { viewer: ['view_own_orders'] },
})

ZenStack uses ZModel, a custom DSL that extends Prisma's schema language. Models, relationships, and access policies are all co-located in .zmodel files. This requires a compilation step (zenstack generate) and a VS Code extension for editor support.

// ZenStack: ZModel DSL
model Order {
  id         Int    @id @default(autoincrement())
  amount     Float
  customerId String
  customer   User   @relation(fields: [customerId], references: [id])

  @@deny('all', auth() == null)
  @@allow('read', customer == auth())
  @@allow('all', auth().role == 'ADMIN')
}

Pros and Cons

3. Access Control Model

superapp uses MongoDB-style operators ($eq, $in, $gte, $or, $and, $not) with $user.* variable substitution. Permissions are standalone objects keyed by slug, mapped to roles separately. Multiple permissions on the same table merge with OR logic. Supports FK relationship traversal in filters.

// superapp: Permission with FK traversal and array membership
{
  read_org_data: {
    table: 'main.orders',
    operations: { select: true },
    columns: ['id', 'amount', 'status'],
    filter: {
      organization: {
        members: {
          user_id: { $eq: '$user.id' }
        }
      }
    },
  },
}

ZenStack uses expression-based policies with @@allow / @@deny attributes. Rules are evaluated as: (1) any @@deny true = denied, (2) any @@allow true = allowed, (3) otherwise denied. Supports collection predicate expressions (?[] any, ![] all, ^[] none) for traversing relations.

// ZenStack: Policy with collection predicate and relation traversal
model Order {
  organization Org @relation(fields: [orgId], references: [id])
  orgId        String

  @@deny('all', auth() == null)
  @@allow('read', organization.members?[userId == auth().id])
}

Pros and Cons

4. Query Engine and ORM

superapp runs all queries through DuckDB, an embedded OLAP engine that natively attaches to Postgres, MySQL, SQLite, and CSV files. Clients write standard Drizzle ORM queries that are sent as parameterized SQL over HTTP. The Drizzle Proxy driver serializes queries and deserializes results transparently.

ZenStack V3 replaced the Prisma engine with a custom ORM built on Kysely. It exposes a Prisma-compatible high-level API (findMany, create, update, delete) and also provides direct Kysely query builder access via $queryBuilder() for complex queries. The ORM is pure TypeScript with no Rust/WASM dependencies.

Pros and Cons

5. Authentication

superapp has a pluggable auth provider interface with better-auth as the default. The auth pipeline is explicit: verifyToken() → findUser() → resolveSession(). The resolveSession step enriches the JWT with application-specific data (org IDs, roles, custom fields). Auth UI components (AuthCard, UserButton) are provided out of the box.

ZenStack is auth-agnostic. It does not provide authentication — you bring your own (Auth.js, Clerk, Better Auth, Supabase Auth, etc.) and pass the current user object to enhance(). Official guides exist for several providers.

Pros and Cons

6. API Layer

superapp exposes a single HTTP endpoint (POST /data) that accepts Drizzle Proxy protocol messages (parameterized SQL + params). Additional endpoints exist for schema introspection (GET /schema) and auth (/auth/*). There is no auto-generated REST or GraphQL API — the Drizzle Proxy protocol is the API.

ZenStack auto-generates CRUD APIs from the schema with server adapters for Express, Next.js, Fastify, Hono, SvelteKit, Nuxt, Elysia, and TanStack Start. APIs follow REST or RPC patterns. An OpenAPI plugin generates 3.x specs. A tRPC plugin generates typed routers.

Pros and Cons

7. Frontend Integration

superapp provides no frontend-specific hooks. You use Drizzle ORM directly from your frontend (or server components). Auth components (AuthCard, UserButton, AuthProvider) are provided for authentication flows, but data fetching is standard Drizzle.

ZenStack generates type-safe frontend hooks via plugins:

• TanStack Query hooks for React, Vue, Svelte, and Angular
• SWR hooks for React
• Hooks include useFindMany, useCreate, useUpdate, useDelete with automatic cache invalidation and optimistic updates

Pros and Cons

8. Database Support

superapp connects through DuckDB which natively attaches to multiple databases simultaneously:

A key differentiator: superapp can query across databases — e.g., join a Postgres table with a CSV file or SQLite database in a single query.

ZenStack V3 supports databases via Kysely dialects:

Pros and Cons

9. Multi-Tenancy

Both tools support multi-tenancy through their access control layers, but with different patterns.

superapp uses resolveSession to enrich the user context with tenant data (e.g., org_ids), then references those values in permission filters with $user.* substitution:

// superapp: Multi-tenant via session enrichment
auth: betterAuthProvider({
  resolveSession: async (user, db) => ({
    ...user,
    org_ids: await getOrgIds(user.id),
  }),
}),
permissions: {
  read_org_orders: {
    table: 'main.orders',
    filter: { organization_id: { $in: '$user.org_ids' } },
  },
},

ZenStack uses auth() in policy expressions with relation traversal:

// ZenStack: Multi-tenant via policy expressions
model Order {
  org   Org @relation(fields: [orgId], references: [id])
  orgId String

  @@allow('all', org.members?[userId == auth().id])
}

Pros and Cons

10. Developer Experience

Pros and Cons

11. Plugin and Extensibility

superapp does not have a formal plugin system. Extensibility comes through:

• Custom auth providers (implement the provider interface)
• Custom database providers (implement the provider interface)
• Permission middleware (wrap individual permission checks with custom logic)
• Server adapters (Hono, Express, Next.js, generic handler)

ZenStack has a three-level plugin system (V3):

1. Schema level — plugins define custom attributes, functions, and procedures in plugin.zmodel
2. Generation level — plugins participate in zenstack generate to produce artifacts
3. Runtime level — plugins leverage Kysely's query tree transformation

Built-in plugins include: policy enforcement, Zod schema generation, TanStack Query hooks, SWR hooks, tRPC routers, and OpenAPI specs.

Pros and Cons

12. Type Safety

superapp achieves type safety through Drizzle ORM's type system. The CLI introspects your database schema and generates Drizzle table definitions. All queries are fully typed — select, where, insert, update, and delete operations benefit from TypeScript inference. Permissions are not type-checked at compile time (they reference tables and columns by string).

ZenStack V3 generates a full TypeScript schema from ZModel with complete type inference. The enhanced client provides typed CRUD methods with select/include inference. Policy expressions are type-checked at compile time by the ZModel compiler. Zod schemas are auto-generated for runtime validation.

Pros and Cons

When to Choose superapp

• You want to use Drizzle ORM as your query interface
• You need multi-database queries (join Postgres + SQLite + CSV)
• You prefer pure TypeScript configuration with no custom DSL
• You want built-in auth with UI components and session management
• You need audit logging and admin capabilities out of the box
• Your team is comfortable with MongoDB-style filter operators
• You want a clear client/server separation where the backend is the single enforcement point

When to Choose ZenStack

• You want policies co-located with your data model in a single schema file
• You need auto-generated APIs (REST, tRPC, OpenAPI) from your schema
• You want frontend hooks (TanStack Query, SWR) generated automatically
• You need to deploy to edge runtimes (Cloudflare Workers, Vercel Edge)
• You prefer compile-time validation of access control rules
• You want a plugin ecosystem for code generation (Zod, tRPC, OpenAPI)
• Your team is coming from Prisma and wants a familiar API
• You need polymorphic models with OO-style inheritance