Learn VoidQL

The mental model

VoidQL treats database access as a policy-constrained operation rather than a raw query. Five inputs determine the outcome:

Input	Purpose
Structure	Connects table objects to operation endpoints and role policies
Request	Describes the intended read or mutation
user	Supplies session-dependent values such as $user.id
role	Selects the permission branch for an endpoint
db	Provides the Drizzle database or transaction used to execute

The engine does not ask only “does this user have a role?” It also asks which operation, fields, rows, incoming values, and lifecycle hooks are allowed.

Requests, policies, and queries

• A request describes intent: table, operation, fields, conditions, data, joins, ordering, grouping, returning fields, and limit.
• A policy is the endpoint configuration embedded in the table structure.
• A query plan is the result of compiling the two with role and user context.
• Execution happens only when execute() is called.

Authorization layers

Role, field, and row checks compose. A role can be allowed to perform PUT, restricted to specific writable fields, and limited to rows it owns. Payload-aware conditions can additionally decide whether the requested change is valid.

Compared with adjacent approaches

Approach	Main difference
Hand-written middleware	Checks are typically distributed and separated from query construction
Query builder alone	Builds database operations but does not define the application authorization model
Basic RBAC	Usually answers operation access, not field, row, payload, and transition rules together
Database-native RLS	Lives in the database and may not directly express application payload or trigger context
GraphQL engine	Usually exposes a schema-driven API layer; VoidQL is intended for an existing TypeScript backend

VoidQL is most useful when authorization complexity already exists. For a small application with one or two static role checks, a simpler design may be easier to operate.

← Status & Limitations · Build with VoidQL →