Ship on Australian-owned Postgres.

Everything starts at the console — console.wattledb.com.au. It's where you create databases, grab connection strings, run SQL, and manage billing.

WattleDB is in private beta, so public sign-ups are closed. If you have an invite, use Log in with your email and password. First time in, you'll confirm your email address before the workspace opens.

From Databases → New database, pick a plan and click create. WattleDB provisions an isolated PostgreSQL 17 instance in Sydney — usually ready in a minute or two.

• Free — kick the tyres. One per workspace, auto-pauses when idle, no card needed.
• Hobby / Launch / Scale — always-on production tiers with more CPU, RAM, storage and pooled connections. Scale additionally unlocks masked clones (step 9).

Every database — on every tier — gets daily backups, point-in-time recovery, TLS, a connection pooler, and the instant REST API. See the full plan table for specs. Prices are in AUD and exclude GST (10% is added at checkout).

Once the database shows Active, click Connection on its row to reveal two connection strings. Use the right one for the job:

• Pooled (DATABASE_URL) — routed through PgBouncer in transaction mode. Use this for your app at runtime; it handles many short-lived connections efficiently.
• Direct (DIRECT_URL) — a session-mode connection straight to Postgres. Use this for migrations, psql, and anything needing session features (advisory locks, LISTEN/NOTIFY, prepared statements across calls).

Both are TLS-encrypted — always keep sslmode=require. Connect with anything that speaks Postgres:

# Connect with psql (use the Direct string for interactive work)
psql "postgresql://app:YOUR_PASSWORD@ab12cd34.db.wattledb.com.au:31234/app?sslmode=require"

# You're in:
app=> select version();

import { Pool } from 'pg';

// Pooled connection string from the console → your app's DATABASE_URL
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

const { rows } = await pool.query('select now() as ts');
console.log(rows[0].ts);

Click Open on a database to enter Database Studio. The SQL editor tab runs any SQL against your database — schema changes, queries, seed data.

create table employee (
  id     bigint generated always as identity primary key,
  name   text,
  email  text unique
);

insert into employee (name, email)
values ('Ada Lovelace', 'ada@example.com');

Prefer your own tooling? Point any migration tool (Prisma, Drizzle, Flyway, psql -f) at the Direct connection string and manage schema from code. The Studio and your migrations see the same database.

The Tables tab is a full data browser. Pick a table from the searchable list on the left — even with hundreds of tables — and the right pane shows its rows. Toggle between Data and Schema, adjust how many rows to load, or hit Query to drop that table straight into the SQL editor.

It's read-and-explore for quick checks; reach for the SQL editor when you want to change data.

The REST API tab turns every table into a REST endpoint — no backend code. It's powered by PostgREST and served from <id>.api.wattledb.com.au. Click Enable REST API, and each table becomes an endpoint supporting GET · POST · PATCH · DELETE with filtering, ordering and pagination via query params.

Authentication & security

• Requests with no token use the anon role.
• A JWT with role=authenticated unlocks the rows your policies allow. Mint a test token from the tab.
• Click Secure (RLS) on a table to require a token and enforce Row-Level Security — the same policies apply to the REST API and to direct SQL, because it's one database.

# Read (filter, sort, paginate with query params)
curl "https://ab12cd34.api.wattledb.com.au/employee?select=*&order=id.desc&limit=10" \
  -H "Authorization: Bearer <TOKEN>"

# Insert
curl -X POST "https://ab12cd34.api.wattledb.com.au/employee" \
  -H "Authorization: Bearer <TOKEN>" \
  -H 'Content-Type: application/json' \
  -d '{"name":"Grace Hopper","email":"grace@example.com"}'

Who can read your data — and how to check

The REST API tab tells you the state of every table. Two badges, two different problems:

You can always confirm it yourself from a terminal, with no credentials at all:

# 401 = this table needs a token.  200 = anyone can read it.
# One table at a time — the REST API tab is the full picture.
curl -s -o /dev/null -w '%{http_code}\n' \
  "https://ab12cd34.api.wattledb.com.au/employee"

Make private doesn't cover everything

Make private withdraws the grants we made. It deliberately leaves alone anything you granted from inside your own database, because removing it would break something you built on purpose. The tab names whatever remains and which of these it is; the fixes run in the SQL editor:

Row-Level Security: replace the default policy, don't add to it

Secure (RLS) turns RLS on and creates one policy, authenticated_all, which allows everything — so nothing breaks the moment you press it. It is a starting point, not the destination. Write your own policy and drop authenticated_all:

-- each end-user sees only their own rows (sub = the JWT's subject claim).
-- the claim is text, so cast it to match your column's type (::uuid, ::int, ...)
CREATE POLICY own_rows ON public.employee FOR ALL TO authenticated
  USING (owner_id = (current_setting('request.jwt.claims', true)::json->>'sub')::uuid);

-- essential: policies are OR'd together, so leaving the allow-all one
-- in place means your new policy changes nothing at all
DROP POLICY authenticated_all ON public.employee;

Every database ships with one credential, app, and it owns the database — it can read and write every table, and change the schema. That's the right credential for your migrations. It is the wrong one to give a reporting tool, a contractor, or a script you're debugging.

The Roles tab creates additional logins, each with its own password and its own level of access. Pick a name, pick an access level, and you get a connection string back.

Or do it in SQL

The app role holds CREATEROLE on your database, so you can manage roles from the SQL editor or psql as well. Roles you make this way appear in the Roles tab alongside the rest.

create role reporting_ro login password '…';
grant connect on database app to reporting_ro;
grant usage on schema public to reporting_ro;
grant select on all tables in schema public to reporting_ro;

-- and for tables you create later. FOR ROLE app matters:
-- a default privilege only applies to objects created by the role that set it.
alter default privileges for role app in schema public
  grant select on tables to reporting_ro;

What you can't do, by design: create a superuser, grant BYPASSRLS, or alter WattleDB's own roles (anon, authenticated, authenticator). PostgreSQL enforces those limits itself — a role you create can never hold more than the role that created it.

If a connection string leaks

Committed to a repository, pasted into a ticket, or held by someone who's left? On the Roles tab, Rotate app password replaces the built-in credential and hands you the new connection strings. Anything still using the old one stops being able to reconnect — which is the point, so deploy the new value first if you can. Extra roles you created are rotated or deleted individually, without touching app.

Deleting a role never takes data with it: anything it created is handed to app first.

One thing to know: app can change its own password with alter role app password … in SQL, but the console won't know you did — the Connection panel would keep showing the old string. Use the button and both stay in step.

The Storage tab gives each database its own private, S3-compatible bucket on Australian-owned infrastructure. Grab the endpoint, region (au-syd-1), bucket name and access keys, and use any S3 client — path-style addressing.

aws --endpoint-url https://storage.wattledb.com.au --region au-syd-1 \
  s3 cp ./report.pdf s3://tenant-ab12cd34/report.pdf

import { S3Client } from '@aws-sdk/client-s3';

const s3 = new S3Client({
  endpoint: "https://storage.wattledb.com.au",
  region: "au-syd-1",
  forcePathStyle: true,   // required
  credentials: { accessKeyId: "…", secretAccessKey: "…" },
});

Each key can access only that database's bucket, and files never leave Australian-owned infrastructure.

Every database is backed up daily (02:00 AEST) with continuous WAL archiving, stored cross-state in Melbourne for disaster recovery. The Backups page lists every backup and lets you trigger an extra one anytime.

Restore to any moment in the last 7 days

Restore creates a new database recovered to the point you choose — your current one is never touched. Pick Latest or a specific backup, choose a plan (at least the source's storage), confirm, and a fresh database provisions. Verify it, repoint your app to its connection string, then delete whichever you no longer need. It's billed as a normal database — no restore fee.

Need production-shaped data in a staging environment without exposing real PII? A masked clone copies a Scale database into a new one and anonymises personal fields on the copy — emails, names, phone numbers, addresses and dates of birth are replaced with realistic but fake values. Your source is never modified.

From a Scale database's Studio, choose Masked clone, pick a plan and an expiry (minimum 7 days, AEST), and confirm. It's billed pro-rata for the days you keep it and auto-expires — extend anytime if you need it longer.

Change plan resizes a database without a data migration — same database, same connection string. CPU, RAM and pooled connections apply after a brief restart; storage grows immediately.

The Logs tab is a read-only viewer with two streams:

• REST API — every request to your auto-generated API (method, path, status).
• Database — Postgres connections, disconnections, errors and notices.

Filter in place, download the current window, and know it's collected into a durable store in Sydney (retained 30 days) that never leaves Australian-owned infrastructure.

Under Settings: enable two-factor authentication (scan the QR with any authenticator app and save your recovery codes), change your password (which signs out other devices), sign out everywhere if you lose a device, and manage your workspace. Changing your password rotates your session automatically.