Database and RLS

Each app receives one PostgreSQL schema exposed through same-origin PostgREST. Migrations use unqualified object names because OpenCloud selects the schema.

Owner-isolated records

create table items (
  id uuid primary key default gen_random_uuid(),
  owner_id uuid not null default auth.uid(),
  title text not null check (length(title) between 1 and 200),
  created_at timestamptz not null default now()
);

create index items_owner_created_idx
  on items(owner_id, created_at desc);

create policy items_owner_access
  on items for all
  using (owner_id = auth.uid())
  with check (owner_id = auth.uid());

OpenCloud enables and forces RLS, then adds a restrictive app boundary. Application policies are still required for business access.

Shared member records

For data shared with every authorized app member:

create policy items_member_access
  on items for all
  using (true)
  with check (true);

The permissive policy does not cross the platform’s restrictive app boundary. Exercise the intended shared behavior with distinct synthetic users in the isolated development environment before promotion.

Data patterns

Read:

const items = opencloud.data.table("items");
const rows = await items.list({
  select: ["id", "title", "created_at"],
  orderBy: { column: "created_at", direction: "desc" },
});

Insert:

const created = await items.create({ title: "New item" });

Update:

const updated = await items.updateById(id, { title: "Updated item" });

Use getById, createMany, and deleteById for their corresponding tasks. The SDK validates table and column identifiers, owns auth and response parsing, and prevents broad update/delete helpers. Equality filters are available through list({ where: { state: "open" } }). Do not build raw PostgREST paths or request headers in frontend code.

Migration safety

Deployments preflight the full migration history in a disposable schema using the pinned runtime and constrained migration role before changing the live app schema. Static policy validation still runs first.

Incremental migrations run as the app's restricted table owner and can update existing rows. The migration transaction temporarily removes forced RLS from the app's tables, then restores forced RLS and the restrictive app boundary before committing. A failure rolls back both the data changes and the policy changes; other apps' data remains inaccessible to the migration role.

See Migration SQL for supported and forbidden capabilities.