Practical guides for Australian founders and developers, building the backend, choosing the stack, and keeping your data Australian-owned under the Privacy Act.
Every SaaS backend has the same six layers, database, auth, APIs, storage, email, backups. In Australia there's a seventh that decides which customers you can sell to. Here's how to build all of it, Australian-owned from day one.
Nearly every slow query gives itself away in its plan. The three numbers that matter, the loops trap that makes a "fast" node cost two seconds, and the five plan shapes behind most slowdowns, with the fix for each.
You added the index and the query is still slow. Ten rules that cover most cases: composite column order, expression and partial indexes, the casts and wildcards that hide an index, and how to find the ones you don't need.
The migration that takes your site down is rarely the slow one, it's the instant ALTER TABLE that waited behind a long query and queued every request behind it. Lock timeouts, NOT VALID constraints, batched backfills, expand-contract.
Before you add a search cluster and a sync pipeline, check what the database already does: tsvector generated columns, GIN indexes, user-safe query parsing, ranking, snippets and fuzzy trigram matching, plus the honest limits.
Postgres will store your whole app in one JSONB column. That doesn't mean you should. Where JSONB genuinely wins, GIN vs expression indexes, promoting hot keys to generated columns, and the gotchas that bite six months in.
One column-type decision decides whether yesterday's total is correct, whether it's correct in Perth, and whether it stays correct after the first Sunday in October. What Postgres really stores, and the three rules that keep Australian data straight.
2024 was Australia's worst year on record for reported breaches. The causes repeat: exposed surfaces, stolen credentials, over-broad access. What the OAIC numbers and the Optus and Medibank cases show, and the infrastructure controls that address each one.
Most managed databases can read every row you store, because the provider holds the keys. Why "encryption at rest" doesn't change that, and how client-side encryption where you hold the key does.
If a field is encrypted, how do you still find a user by email? Blind indexes. How keyed hashes let a database match encrypted values it can't read, what they leak, and the honest limits.
At-rest encryption protects against a stolen disk, not against your provider, an insider, or a legal demand, because the provider still holds the key. What each layer of database encryption actually defends against.
The fastest honest path with WattleDB: a real Postgres schema, an auto-generated REST API and JWT + Row-Level Security for multi-tenant isolation, plus a straight answer on what you still bring yourself today.
An honest step-by-step: dump and restore the database, carry your RLS, re-point the REST API, copy Storage, and handle Auth, Realtime and Edge Functions, which don't map one-to-one. What's clean, what takes effort, what has no equivalent yet.
Assess, provision, dump, restore, verify, cut over, the full step-by-step playbook for moving Postgres with minimal downtime, with the exact pg_dump / pg_restore commands. Provider-agnostic, Supabase included.
The scariest bug in a multi-tenant app shows one tenant another's data. A worked example of enforcing isolation in the database with RLS and JWT claims, so a forgotten WHERE clause can't become a breach.
Enable the REST API and PostgREST turns your schema into a full HTTP interface, filtering, ordering, pagination, embedded relations and writes, all respecting Row-Level Security. Skip the CRUD layer.
Connections are expensive and there's a hard limit, ignore it and a spike takes you down with "too many clients." What a transaction-mode pooler does, and which of the two connection strings to use where.
WattleDB is standard Postgres, so your ORM just works, once the right URL does the right job. The clean setup: pooled DATABASE_URL for the app, direct DIRECT_URL for migrations, TLS throughout.
A nightly backup answers "what did it look like last night?" PITR narrows the gap after a 4pm bad migration. How continuous WAL archiving works, what the console actually lets you pick, your recovery window, and why you restore to a new database.
Cloning production into staging quietly parks real customer PII where it was never meant to live. Masked clones give you production-shaped data with the common contact fields anonymised, matched by column name and kept in Australia — review the mask against your own schema before you rely on it.
A plain-English, global guide to the concept behind everything else here: what data sovereignty is, why it's become a board-level priority worldwide, and what an organisation really risks by neglecting it.
One set of rules pulls your data one way, the Privacy Act pulls it the other, and Australian businesses on US clouds get caught in the middle. The clean structural way out: an Australian-owned stack.
Relational or document? Predictable or per-operation pricing? Australian-owned or US-owned? A practical comparison for Australian teams choosing a database in 2026.
More than a database you didn't have to install. Automated backups, point-in-time recovery, Row-Level Security, pooling and audit logs, and why they separate a hobby project from production.
AWS RDS, Supabase, Neon, DigitalOcean, Firebase and WattleDB, six real options ranked for Australian teams on the axis global lists skip: who actually owns the company behind your data.
Supabase, Appwrite, PocketBase, Nhost, WattleDB, ranked on the axis most lists skip: who owns the company, and whether an Australian business stands behind your data.
Residency is geography; ownership is who's actually behind the platform. Why a US provider's Sydney region isn't an Australian company, and what the 2024 reforms mean for your data.
Same developer experience, genuine Australian ownership. A full feature-by-feature comparison, plus an honest take on when to choose each.
Supabase has a Sydney region, so you can keep data onshore. But a Sydney region is not the same as an Australian company. What running Supabase in Australia really means, and your options when you want an Australian-owned stack.
The cloud made infrastructure borderless; Australian ownership puts a name and a place back on it. How to keep the cloud's convenience while knowing exactly who owns and runs the platform your data sits on.
Retention is two duties at once, keep some records long enough, delete the rest on time. The obligations that set the clocks, the capabilities that enforce them, and why the data layer's Australian ownership matters.
Health, childcare, construction, telco, education, legal, accounting, real estate, aged care, the specific regulations that make Australian ownership a requirement, not a preference.
Start building on a wholly Australian-owned Backend-as-a-Service.
Get started →