Frequently asked questions.

WattleDB is a wholly Australian-owned Backend-as-a-Service (BaaS): one platform giving you managed PostgreSQL, auto-generated REST APIs, JWT-based row-level security and S3-compatible object storage, with a hosted authentication service and transactional email coming soon. It is built by RR Sols Pty Ltd, a 100% Australian-owned company, and runs entirely on Australian-owned infrastructure in Sydney and Melbourne. One Australian company is behind it, with no foreign parent.

A Backend-as-a-Service provides the common backend components every application needs (database, authentication, APIs, file storage and email) as a managed, pre-integrated service, so developers build applications without provisioning and operating that infrastructure themselves. Firebase and Supabase are well-known examples. WattleDB is the wholly Australian-owned equivalent. See How to build a SaaS in Australia for the full stack.

WattleDB is built and operated by RR Sols Pty Ltd, an Australian-owned and operated company with no foreign parent entity. Support and administration are handled onshore under Australian law.

WattleDB is live. Create a workspace and start on the free sandbox tier, no credit card required. We would love your feedback as we grow.

Yes. What makes a provider Australian is corporate ownership, not just server location. WattleDB is owned by RR Sols Pty Ltd, an Australian company with no foreign parent, and runs on Australian-owned infrastructure in Sydney and Melbourne with backups kept cross-state within Australia. Owned here, hosted here and supported here, with one Australian company behind it, so you always know exactly who runs the thing your data sits on. Read the full explainer: Australian-owned data, in plain terms.

Your database, its backups and your object storage are held in Australia and never leave it. Primary infrastructure is in Sydney and backups are held cross-state in Melbourne, both within Australian-owned data-centre facilities, so a single-city incident cannot take out both your primary and your backups.

Yes, those regulated sectors are exactly who WattleDB is built for. Your data stays in Australia, in Australian hands, with one Australian company behind it, and the platform is architected for IRAP assessment at the PROTECTED level. That gives you a clean, simple answer for your customers and your compliance team, and helps meet Privacy Act obligations and sector-specific requirements. See Industries for the rules by sector.

No. A Sydney region gives you data residency (the geography), while Australian ownership is about the company behind the service. With a foreign-owned provider your data can sit in Australia, but the company that owns, runs and supports it is overseas. WattleDB is an Australian company on Australian-owned infrastructure with an Australian team, so ownership, operation and support are all here.

PostgreSQL, the world's most advanced open-source relational database. Each tenant gets an isolated managed Postgres database with enforced CPU and memory limits, a plan storage allowance, connection pooling, Row-Level Security for multi-tenant isolation, automated backups and point-in-time recovery.

WattleDB uses simple, flat AUD pricing with unmetered bandwidth on paid tiers, so there are no surprise egress bills. There is a free tier to start building, and paid tiers scale up in resources as your application grows. All prices are quoted ex-GST. See the pricing page for the current tiers.

A masked clone is a one-click copy of your production database with common contact fields (names, emails, phone numbers, addresses, dates of birth) automatically replaced by realistic fake values, matched by column name. Your team tests against production-shaped data with far less real customer PII in staging. Identifiers such as Medicare, TFN or member numbers, free-text notes, and PII stored in numeric columns are not masked automatically, so review the mask against your schema. It is a WattleDB feature that Supabase and Firebase do not offer.

No. Unlike usage-based platforms that meter egress bandwidth (which can produce bill shock), WattleDB uses flat AUD tier pricing with unmetered bandwidth. You pick a tier and know the price.

Similar developer experience (managed database, instant APIs and object storage today, with hosted auth coming soon) but 100% Australian-owned with no foreign parent. Supabase Inc. is US-incorporated and Firebase is a Google (US) product, so both are owned and run from overseas even with an Australian region. WattleDB is one Australian company with no foreign parent in the chain, and uses flat AUD pricing instead of usage-based egress. Compare in detail: WattleDB vs Supabase and Firebase alternatives for Australia.

Yes. WattleDB is built on the same open-source core as Supabase (PostgreSQL and PostgREST). Its REST API uses the same PostgREST protocol, so PostgREST clients and tooling work against it, and migrating is the standard pg_dump/pg_restore of your schema and data over WattleDB's DIRECT_URL, then repointing your connection string. Auth uses JWT tokens with Postgres Row-Level Security.

Yes. Migrating from Firebase involves moving from Firestore's NoSQL model to PostgreSQL. That is more involved than a Supabase move, but it also frees you from NoSQL lock-in and unpredictable scaling costs, and gives you the full power of SQL, relations and Row-Level Security.

Each database gives you a pooled connection string (DATABASE_URL) and a direct session connection string (DIRECT_URL), both over TLS at an Australian endpoint. Connect with standard PostgreSQL tooling and libraries (psql, Prisma, Drizzle, or any Postgres driver) and download the CA certificate for verified TLS.

WattleDB provides an auto-generated REST API via PostgREST: full CRUD, filtering, pagination and OpenAPI docs straight from your schema. It does not include a built-in GraphQL endpoint, but because you get direct access to your Postgres database you can run any GraphQL layer of your choice, such as Postgraphile or Hasura, against it.

Authentication uses JWT tokens with PostgreSQL Row-Level Security (roles anon and authenticated), so your access policies live in the database rather than in application code. You can reveal your database's JWT secret and sign your own tokens with custom claims for per-user access. All authentication runs onshore, with no third-party identity provider.

Sign up in the console and create a database on the free tier. It provisions in a couple of minutes. Define your schema in the built-in SQL editor, copy your connection strings from the Connection tab, and point your app at them. To expose an instant API, enable the REST API and query your tables directly with a JWT. Our Build a SaaS fast guide walks the whole path end to end.

DATABASE_URL is your pooled connection string. It routes through PgBouncer in transaction mode. Use it for your application and serverless functions: it lets many short-lived connections share a small pool, so a traffic spike will not exhaust the database's connection limit. It is the connection string most of your app should use day to day, and it is TLS-encrypted, so keep sslmode=require.

DIRECT_URL is a direct session connection to the database, bypassing the pooler. Use it for schema migrations, psql, and bulk jobs, anything that sets session state or holds a long transaction, which a transaction pooler would break. A common setup: point your ORM's runtime at DATABASE_URL and its migration command at DIRECT_URL (Prisma, for example, supports both).

Row-Level Security is standard PostgreSQL. Run alter table your_table enable row level security;, then create a policy. For multi-tenant isolation, tie each row to a claim in the caller's JWT, for example tenant_id = (current_setting('request.jwt.claims', true)::json ->> 'tenant_id')::uuid. The database then filters every query by that policy, so the REST API and any direct query both enforce it. See Build a SaaS fast for a worked example.

Yes. Every database gets a private, S3-compatible bucket with scoped access keys, hosted in Australia. Use it with the standard AWS SDK or CLI, or any S3 client, alongside your database, REST API and access rules on the same wholly Australian-owned platform.

Every database has automated backups with point-in-time recovery, so you can restore to a moment before an incident. Backups are held cross-state in Melbourne, separate from the Sydney primary, so a single-city event cannot take out both your database and its backups. All backups stay in Australia. We still recommend keeping your own copies of critical data.

Yes, in transit and at rest. Every connection uses TLS, and passwords are stored only as salted hashes. At rest, the Sydney primary runs LUKS encryption on the volume that holds your databases (the host root filesystem itself is not encrypted), and your Melbourne backups are encrypted object by object (SSE-KMS). Disk-level encryption protects a stolen or decommissioned drive; on its own it does not stop someone with access to the running system, which is what our opt-in client-side encryption (coming soon) is for. Combined with Australian-only hosting, this supports your obligations under Australian Privacy Principle 11.

Yes. The console includes a read-only log viewer for both REST API request logs and database logs, so you can debug your app and see connection activity. Statement-level audit logging (pgaudit) is enabled on new databases and currently records schema changes and writes; read queries are not audited yet. Logs are retained for 30 days and stay onshore. Auditing of reads, and attribution of administrative access, are on our roadmap.

WattleDB offers a written Service Level Agreement for paid, always-on databases: a 99.5% monthly uptime commitment with service credits if we miss it. You can see component status and our declared incident history on the status page — which is upfront that we do not yet publish continuously measured uptime. Free-tier databases and features still marked coming soon are excluded, and we're upfront that recovery today is a restore from the cross-state Melbourne backups rather than instant failover, with a high-availability standby being added. If your project needs specific availability terms, talk to us.

You stay in control. Because it's standard PostgreSQL, you can export at any time while your database is running using pg_dump over your DIRECT_URL, in a commonly used format and with no proprietary lock-in. Take your export before you delete, deleting a database destroys it immediately and permanently, backups, object storage and the REST API included, and you type the database name to confirm. If you only want to stop paying, use Cancel instead: the database keeps running until the end of the period you've already paid for, and you can change your mind until then. Either way, if you're within 7 days of paying for the month, that month's payment is refunded — that month only, not earlier months you have already used. Backups and archived write-ahead logs are destroyed at the same time as the database, normally within minutes, except where we must retain data by law. A one-click export in the console is coming soon. See the Refund & Cancellation Policy, Terms of Service and Privacy Policy.

WattleDB complies with the Notifiable Data Breaches scheme under the Privacy Act. If an eligible breach likely to cause serious harm occurs, we notify affected individuals and the OAIC as soon as practicable, and we notify you promptly where the breach affects data you control. See our Privacy Policy.

We invoice you, and you pay the invoice. At the start of each billing period we email a GST tax invoice payable within 7 days. Pay it by bank transfer or PayID, quoting the invoice number as your payment reference so we can match it. Everything is billed in Australian dollars.

No. We do not keep card or bank details on file, and nothing is ever charged automatically. There is no direct debit to authorise, no stored card to manage, and nothing to cancel if you leave: each month is simply an invoice you choose to pay.

Yes, you are billed per database: each paid database is its own monthly subscription in AUD, and free databases are always free. A workspace with several paid databases gets one invoice with a line per database, so you pay once. Prices are quoted ex-GST, with 10% GST added.

A paid database is invoiced when you create it, then monthly on its anniversary, in advance. The invoice is issued and emailed before you pay, not after — your database runs from the moment you create it, and you have 7 days to settle each invoice.

Prices are quoted ex-GST. 10% GST is added and you receive a valid GST tax invoice showing our ABN and the GST breakdown. The invoice is in the console from the moment it is raised, and is marked paid once we have matched your payment.

Nothing is deleted without warning. We remind you before the due date. If an invoice is still unpaid a few days after it falls due, the database is paused: it stops running, but all your data is kept, and paying at any point brings it straight back. While it is paused we send two more warnings, the last naming the exact date, and only then is the database deleted. If we could not deliver your invoice at all, we do not suspend you over it — your first notice of a bill should never be your application going down.

No. Free databases need no card, no bank account and no payment details at all, so you can start building immediately. You are only invoiced when you create a paid database.

Yes, there is no lock-in contract. Cancelling takes effect at the end of the current billing period, so the database keeps running until then; deleting removes it immediately. If you do either within 7 days of paying, we refund that month’s payment. The refund covers the month you have just paid for and nothing before it — earlier months are months you used, and stay paid. See our Refund and Cancellation Policy for how part-periods are handled.

Refunds follow our Refund and Cancellation Policy and your rights under the Australian Consumer Law. Note that some irreversible actions, like deleting a masked clone early, are non-refundable, and we warn you before you confirm them.