Permissions & row-level security

SurrealDB lets you declare permissions alongside your schema so access is enforced in the database, not only in application code. You attach a PERMISSIONS clause to DEFINE TABLE and DEFINE FIELD to describe which operations are allowed under which conditions.

For each table, you set independent rules for create, select, update, and delete. Each clause is a SurrealQL expression that must succeed for that operation to proceed; if it fails, the operation is rejected for the affected rows. Field-level permissions refine this: you can constrain select, create, and update on individual columns—useful for sensitive fields that should not be readable or writable under the same rules as the rest of the row.

Row-level security is implemented by writing expressions that depend on the authenticated context. The $auth variable holds the current identity and claims after sign-in, so you can compare it to columns on the row (for example owner = $auth.id) and ensure each user only sees or changes their own data.

Example: users read only their own records

DEFINE TABLE order SCHEMALESS
	PERMISSIONS
		FOR select
			WHERE customer = $auth.id
		FOR create
			WHERE customer = $auth.id
		FOR update, delete
			WHERE customer = $auth.id
;

Example: a field only administrators may update

DEFINE FIELD internal_note ON order TYPE string
	PERMISSIONS
		FOR select FULL
		FOR update WHERE $auth.role = 'admin'
;

Together, table- and field-level PERMISSIONS give you flexible authorisation without duplicating policy in every client. For full syntax and options, see DEFINE TABLE and DEFINE FIELD.