Tip: select any text on this page to bring up the Ask tooltip and question the Synedrix OS assistant about it.
What Supabase PG17 is
Supabase is a platform built around Postgres rather than a database in its own right. A deployment is a dedicated Postgres instance plus a set of services attached to it: PostgREST for auto-generated APIs, Auth for identity, Realtime for change streams, Storage, Edge Functions, and Studio, fronted by an API gateway.
Supabase auto-generates an API directly from the database schema, reflected from the schema as it changes, with GraphQL available through pg_graphql.
Row Level Security is the part that matters most for a governed system. RLS is a Postgres primitive providing defence in depth even when data is accessed outside the application, and it must always be enabled on tables in an exposed schema.
What it is normally used for
How Supabase PG17 is used generally, before Synedrix OS enters the picture.
- A Postgres database with the plumbing already attached, without assembling auth, storage, and realtime by hand
- Auto-generated, self-documenting data APIs reflected from the schema
- Application authentication and identity, mapped onto Postgres roles
- Realtime change streams over the same rows the application writes
- Multi-tenant data isolation enforced in the database through RLS policies
What it owns, and what it does not
Every platform in the stack has a non-overlapping responsibility. The boundary is as much a part of the design as the capability.
Owns
- Business entities
- Workflow state snapshots
- Policies and approvals
- Audit trails
- Operator configuration
- Domain-pack data models
- Agent definitions
Does not own
- Hot execution state, coordination, idempotency keys
- → Redis (Layer 7)
- High-volume time-series and temporal aggregation
- → QuestDB (Layer 7)
- Queryable lineage and relationship graph
- → Neo4j (Layer 7)
- Semantic retrieval and similarity search
- → Qdrant (Layer 7)
- LLM traces, prompts, evaluations
- → Langfuse (Layer 10)
- Workflow sequencing, retries, approval routing
- → n8n (Layer 3)
Why Supabase PG17
It is Postgres, undisguised
The platform needs one trustworthy place to store its core data, with real transactions, constraints, and version-controlled schema changes. Supabase doesn't hide the database behind an abstraction: it's ordinary Postgres, and the full power of SQL is still there.
Data separation between customers is enforced by the database itself
Row Level Security means every customer's data stays isolated at the database level, for every single request, instead of that isolation being re-implemented (and possibly forgotten) in each service that touches the data.
One store, several access shapes
The same rows are reachable three ways: plain SQL for the platform itself, an auto-generated API for operator tools, and a live stream for anything that needs to react to changes as they happen. Nothing is copied between systems, so nothing can drift out of sync.
Postgres extensions avoid the need for extra systems
Postgres can handle scheduling, queues, and even vector search through its own extensions. That keeps those capabilities inside the database Synedrix OS already runs, instead of adding yet another platform to operate.
Licence position
Supabase PG17 questions, answered
Short, citable answers drawn from this page.
What role does Supabase PG17 play in Synedrix OS?
Supabase PG17 (Relational system of record) is mapped to Layer 7: Memory & Data in Synedrix OS. Canonical relational truth. It is Postgres, undisguised.
What does Supabase PG17 own in Synedrix OS?
Supabase PG17 owns: Business entities; Workflow state snapshots; Policies and approvals; Audit trails; Operator configuration; Domain-pack data models; Agent definitions.
What does Supabase PG17 not own in Synedrix OS?
Supabase PG17 does not own: Hot execution state, coordination, idempotency keys (owned by Redis (Layer 7)); High-volume time-series and temporal aggregation (owned by QuestDB (Layer 7)); Queryable lineage and relationship graph (owned by Neo4j (Layer 7)); Semantic retrieval and similarity search (owned by Qdrant (Layer 7)); LLM traces, prompts, evaluations (owned by Langfuse (Layer 10)); Workflow sequencing, retries, approval routing (owned by n8n (Layer 3)).
What licence is Supabase PG17 under?
Supabase PG17 is released under Apache 2.0 (components: PostgreSQL License, Apache 2.0, MIT). The licence claim holds. Self-hosted Supabase ships Postgres 17 by default (the reference docker-compose.yml pins supabase/postgres:17.6.1.136), so the platform name matches the self-hosted default. The self-hosted feature set is still incomplete relative to cloud, though: branching, advanced metrics, managed backups and point-in-time recovery, analytics buckets, and the management API are cloud-only, and self-hosting is community-supported.
The full reference page, with the operating model, deployment detail, and links to every canonical specification this platform touches, lives in the documentation repository, which is private while the platform is being built.