Service & subsystem information.

Current subsystem readiness ahead of our November 1 general rollout, plus diagnostic steps when Studio or content delivery is interrupted.

Platform subsystems

Because SCHMA connects to your own PostgreSQL database, your data plane runs in your chosen provider while SCHMA operates the Studio and API control layer.

Early Access Rollout
Studio Control Plane & Auth
Workspace management, RBAC (Owner, Admin, Editor), and AES-256-GCM credential vault
Operational · Early Access
PostgreSQL Data-Plane Migrator
Idempotent schma_* table provisioning, search_path environment isolation, and pgvector indexing
Operational · Early Access
Delivery REST & GraphQL API
Edge-cached GET /v1/delivery/entries, POST /v1/delivery/graphql, and draft preview tokens
Operational · Early Access
SCHMA AI & Changeset Compiler
Schema generation, staged batch previews, and RFC 8785 canonical changeset hashing (Pro & Max)
Operational · Early Access
BullMQ Durable Webhook Workers
Outbound HMAC-SHA256 signed event delivery with 10s timeout and jittered exponential backoff
Operational · Early Access
Local MCP Server (@schmadev/mcp-server)
Stdio Model Context Protocol bridge for Cursor and Claude Desktop
Experimental · Pro & Max

If you’re experiencing an interruption

  1. Check whether the issue affects the Studio, Delivery API requests, or only your frontend build pipeline.
  2. Check your PostgreSQL provider’s status page (such as Supabase, Neon, Railway, or AWS RDS) and confirm that your workspace database is accepting connections.
  3. Review the HTTP status code (401, 403, or 429) and X-Quota-Remaining headers in your server logs.
  4. Record when the issue began, the affected workspace slug, and the action that failed. Redact database credentials and API keys from any logs you share.
Open the troubleshooting guide →