Build a SaaS fast: from a Postgres schema to a live REST API

Every SaaS needs the same unglamorous foundation before feature work can start: somewhere to store data, an API to reach it, and rules about who can touch which rows. Assemble that by hand and you lose a week. WattleDB gives you the first three as one managed unit, so you spend your time on the product instead of the plumbing. This is a practical walkthrough — and an honest one about what's ready today versus what's on the way.

1. Start with the data model

A SaaS lives or dies on its schema, so start there. Create a database in the console, open the built-in SQL editor, and define your tables in plain Postgres. For a multi-tenant app, put a tenant key on every row you'll isolate:

create table projects (
  id         uuid primary key default gen_random_uuid(),
  tenant_id  uuid not null,
  name       text not null,
  created_at timestamptz not null default now()
);

It's just PostgreSQL — indexes, foreign keys, JSONB columns, constraints and all. Nothing proprietary to learn, and nothing to unlearn if you ever move.

2. Get an instant REST API

Enable the REST API on your database and WattleDB generates a full CRUD interface over your schema with PostgREST — filtering, ordering, pagination and OpenAPI docs, straight from your tables. There's no API server to write or deploy. From your frontend it's an ordinary fetch:

// list this tenant's projects, newest first
const res = await fetch(
  `${API_URL}/projects?select=id,name,created_at&order=created_at.desc`,
  { headers: { Authorization: `Bearer ${jwt}` } }
);
const projects = await res.json();

Insert, update and delete work the same way. Your schema is your API — change a table and the endpoints change with it.

3. Secure it with JWT + Row-Level Security

An instant API is only useful if it's safe, and this is where WattleDB does the heavy lifting for you. The API authenticates requests with a JWT, and access is enforced by Postgres Row-Level Security (RLS) — a policy attached to the table itself, applied to every query. Turn RLS on for a table and write a policy that ties rows to the caller's tenant:

alter table projects enable row level security;

create policy tenant_isolation on projects
  for all to authenticated
  using  (tenant_id = (auth.jwt() ->> 'tenant_id')::uuid)
  with check (tenant_id = (auth.jwt() ->> 'tenant_id')::uuid);

Now a request can only ever see or change its own tenant's rows — even a query you forgot to guard in application code. This is the backbone of safe multi-tenant SaaS, and because it lives in the database, it can't be bypassed by a bug in your API layer.

4. Connect your app

You have two ways in, and they're for different jobs. The REST API (above) is perfect for a browser or mobile frontend. For server-side code, or anything that speaks Postgres directly, use the connection strings from the console:

• DATABASE_URL — the pooled endpoint (PgBouncer, transaction mode). Use this for your app and serverless functions; it survives traffic spikes that would otherwise exhaust connections.
• DIRECT_URL — a direct session endpoint, for schema migrations, psql and bulk jobs.

Both are TLS-encrypted — keep sslmode=require. Point your ORM (Prisma, Drizzle) or driver at DATABASE_URL and you're live.

5. What you bring yourself — for now

Being straight with you: WattleDB today is the data layer plus the API and access control. A few pieces of a full backend are on the roadmap, not shipped:

• A hosted auth service (sign-up, login, password reset UI) is coming soon. Today you mint your own JWTs — carrying a tenant_id and role claim — and RLS does the rest. Any standard JWT library works.
• Object storage and realtime subscriptions are on the roadmap. If you need file uploads or live updates right now, wire in a service for those while your data, API and rules live on WattleDB.

We'd rather tell you exactly where the edges are than have you discover them mid-build.

6. Ship it — sovereign and backed up

Everything above runs on 100% Australian-owned infrastructure in Sydney, with automated backups and point-in-time recovery held cross-state in Melbourne — encrypted at rest, and never outside Australian jurisdiction. You get the fast path and a production-grade foundation, without a US CLOUD Act exposure to explain in your next procurement round.