SCHMA is designed around full customer data ownership. Unlike traditional cloud CMS platforms that store your structured data in multi-tenant shared proprietary databases, SCHMA persists all your content models, entries, and versions directly inside your own PostgreSQL database.

The customer-owned database model

When you create a workspace in SCHMA, you connect a PostgreSQL instance that you control. This can be hosted on a managed cloud platform (such as Neon, Supabase, AWS RDS, GCP Cloud SQL, or Azure Database for PostgreSQL) or self-hosted in your own infrastructure via Docker, Kubernetes, or a virtual private server.

SCHMA connects to your database over standard PostgreSQL wire protocols, executes automated table provisioning during workspace setup, and writes your content entries into dedicated tables.

Connection string format and components

SCHMA accepts standard PostgreSQL connection URI strings starting with either postgres:// or postgresql://. The connection string must contain all required authentication parameters:

postgresql://username:password@hostname:5432/databasename?sslmode=require

• username: The database role with privileges to create tables, indexes, and write rows.
• password: The user's password. If the password contains special characters like @, :, #, or /, they must be percent-encoded (for example, @ becomes %40).
• hostname: The fully qualified domain name or IP address of your PostgreSQL server.
• port: The PostgreSQL port, typically 5432 for direct connections or 6543 for connection poolers like PgBouncer.
• databasename: The target database name inside your PostgreSQL instance.
• sslmode: SSL configuration mode, typically require for encrypted connections over the public internet.

SSL configuration and network security

All connections between SCHMA's API services and your PostgreSQL database are encrypted via TLS. When configuring your connection string, ensure that ?sslmode=require is appended to the URI unless you are connecting within an isolated VPC or internal testing network.

Table isolation and schema provisioning

SCHMA isolates all system and content tables by namespacing them within your database. During onboarding, SCHMA creates and manages its own internal tables (such as schema definitions, revision history, and entry collections) without interfering with any existing tables in your database.

This architectural isolation means you can safely connect a database that already houses other application tables, or dedicate a clean, isolated database solely to your SCHMA workspace.

Verifying the connection in Studio

To test or update your database connection at any time: navigate to Settings → Database in your SCHMA Studio workspace. Enter your connection string and click Test Connection to verify reachability, authentication credentials, and table provisioning status.