Skip to content
SMTA

Schema Boundaries

SMTA uses five PostgreSQL schemas to enforce security boundaries and separate concerns. Direct table access from the public schema is removed — all activity is routed through public.* functions.

core Schema

Section titled “core Schema”

The heart of SMTA. Contains:

  • core.organizations — top-level tenants
  • core.organizations_meta — extended metadata for organizations
  • core.units — sub-groups within organizations
  • core.unit_meta — extended metadata for units
  • core.memberships — links users to organizations with roles
  • core.unit_memberships — links users to units with roles
  • core.roles — named roles scoped per organization
  • core.invitations — pending invitations to join an organization
  • core.audit_logs — immutable record of data changes
  • core.organization_files — file metadata scoped to organizations
  • core.users_meta — extended profile data for authenticated users

RLS is enabled on all core tables. Policies use core.get_current_user_id() to determine the authenticated user.

platform Schema

Section titled “platform Schema”

Service-role-only tables for SaaS-wide management. Application code cannot read or write platform tables — only database service roles (your backend, not your end users) can access them.

Contains:

  • platform.billing_customers — links organizations to payment processor customer records
  • platform.billing_subscriptions — active subscription records per organization
  • platform.subscription_products — billable products synced from the payment processor
  • platform.platform_subscription_overrides — admin-applied subscription overrides
  • platform.platform_organizations — SaaS-wide organization registry for admin use
  • platform.platform_users — SaaS-wide user registry for admin use
  • platform.platform_roles — global role definitions
  • platform.platform_feature_flags — org-level feature flag overrides
  • platform.platform_settings — global SaaS configuration settings
  • platform.platform_action_logs — admin action audit trail
  • platform.platform_system_events — system-level event log
  • platform.tenant_secrets — per-tenant secret references (vault IDs)

utils Schema

Section titled “utils Schema”

Shared utility functions used across all schemas. Contains helpers for soft deletion, timestamp management, and audit log insertion. Not called directly by client code.

public Schema

Section titled “public Schema”

The RPC interface. Contains only functions — no tables. These are the only entry points for client code. In Supabase, PostgREST exposes them automatically as REST endpoints. In Payload, you call them via your database client.

See the Public RPC Reference for all available functions.

app Schema

Section titled “app Schema”

Created by SMTA but not populated — this is your domain. You define your application tables here and write RLS policies that reference core tables and call core.get_current_user_id(). SMTA’s RLS enforcement cascades into your app schema through the session context.