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 your database backups are held cross-state in Melbourne, both within Australian-owned data-centre facilities, so a single-city incident cannot take out both your database and its backups. Object storage is served from Sydney, with a cross-state copy in Melbourne that we restore from. It holds current versions only and is not an endpoint you can reach, so keep your own copy of any file you cannot re-create.

Health, NDIS and aged care, legal and accounting teams build on WattleDB today as the database layer. Your data stays in Australia with one Australian company behind it, and we provide the controls and contract terms your own obligations call for: residency, encryption, backups with point-in-time recovery, row-level security and a Data Processing Addendum. We do not hold ISO 27001, SOC 2, IRAP or PCI DSS attestations in our own name, so we are not the right fit for APRA-regulated, government or card-data workloads today, and we say so. See Industries for what each sector still has to do itself.

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 per database. There is a free tier to start building, and paid tiers scale up in resources as your application grows. All prices include 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 (emails, phone numbers, street addresses, postcodes, dates of birth, and every column whose name ends in _name, such as patient_name or customer_name) automatically replaced by realistic fake values, matched by column name. Technical and catalogue columns that merely end in _name, such as product_name, table_name or status_name, are left readable on purpose so the copy stays realistic, as are locality names such as city_name and suburb_name. Your team tests against production-shaped data with far less real customer PII in staging. Anything we do not recognise is not masked: username (no underscore), camelCase spellings such as firstName, identifiers such as Medicare, TFN or member numbers, free-text notes, and PII stored in numeric or jsonb columns. Review the mask against your schema. It is a WattleDB feature that Supabase and Firebase do not offer.

No. WattleDB bills a flat monthly price per database tier, in Australian dollars, and you pick the tier. We do not currently bill for data transfer. If that changes, allowances and rates will be published on the pricing page with notice before they apply.

Not inside WattleDB itself. WattleAddr is our sister product from the same company, RR Sols Pty Ltd: an Australian address autocomplete and verification API built on the open G-NAF dataset and hosted in Australia. WattleDB's own billing-address field uses it. If your app collects Australian addresses, pair the two.

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.

Removing someone from a workspace revokes their database login first and their console access second, so if the revoke fails they stay visible in your team list rather than disappearing with a working password. Be aware of two things. Removing a person signs them out of every WattleDB workspace, including their own, because a session identifies the person rather than the workspace. And there is no self-service way to change who owns a workspace: if the owner leaves your organisation, email support@wattledb.com.au and we will move it. We deliberately do not offer that as a button, because it moves the one permission that can delete everything.

Yes, on Launch and Scale. Launch workspaces can be shared with up to 5 people and Scale with up to 20, counting the owner. You invite someone by email and choose their role: a Developer can create and manage databases and connect to them, and an Analyst can see the workspace without being able to connect or change anything. Only the owner can change billing or delete a database. Everyone who can connect gets their own database login rather than a shared password, so removing someone actually revokes their access. Free and Hobby workspaces are for one person.

Yes, and we publish the date. The most recent restore drill was 9 September 2026 and it passed: we wrote a marker row, waited, wrote a second one, then restored to a moment between them and confirmed the first row came back and the second did not. The source database kept serving throughout, because a restore creates a separate copy rather than overwriting anything. The date of the last drill is on the status page, and we will keep it current. A backup nobody has ever restored is a promise, not a capability, and we would rather show you the receipt.

One limit worth knowing, and what it does not cover: if you type a moment to recover to, it cannot be inside the last 15 minutes, because those changes have not reached the cross-state archive yet. That limit does not apply to a completed backup you pick from the list, including one you have just taken by hand: the write-ahead logs that backup needs are archived as part of taking it, so it can be restored immediately. For a moment that has just happened and no backup covers, restore to “Latest”, which recovers as close to now as the archive allows.

A fair question, and the honest answer is structural rather than reassuring words. There is no lock-in to escape. WattleDB is standard PostgreSQL, the REST API is the open-source PostgREST project, and object storage speaks ordinary S3. No proprietary engine, format or API sits between you and your data. You can take a pg_dump and a copy of your bucket whenever you like, without asking us, and restore onto any PostgreSQL provider or your own hardware.

Contractually, Terms section 21 commits us to at least 30 days’ written notice if we discontinue the Services, with your data available for export throughout, and we will not withhold it over an unpaid invoice in that situation.

We are deliberately not claiming more than that. WattleDB is built and run by one person at RR Sols Pty Ltd, an Australian company with no foreign parent. We would rather you plan around that openly than discover it later.

About 16 MB before you create a single table. That is PostgreSQL's own catalogue plus the extensions we install for you, and the largest single part of it is PostGIS's coordinate-reference table at 7 MB. pg_cron's job tables add roughly 80 KB. It counts toward your plan's database allowance, so on Free (512 MB) about 3% is in use before you start, and proportionally less on the larger plans. Extensions occupy space whether or not you use them, which is true of every PostgreSQL platform: the space goes on the catalogue entries and reference data the extension ships with. If a lean database matters more to you than having PostGIS ready, tell us — we would rather hear it than guess. To estimate the rest, see how much storage your data needs, in records per GB by sector.

See the extensions page for examples. PostGIS (with raster, topology and pgRouting available), pgvector for embeddings, pg_cron for scheduling jobs inside the database, and pg_stat_statements for query statistics are installed and ready on every database. The trusted contrib extensions, such as uuid-ossp, citext, pg_trgm, hstore, pgcrypto and ltree, are yours to enable with CREATE EXTENSION; untrusted ones are not. PostGIS and pg_stat_statements live in a wattledb_ext schema that is on your search path, so geometry and pg_stat_statements resolve without qualifying them. To use pg_cron, schedule with cron.schedule(); jobs run as the role that created them, not as a superuser. Because every database is its own PostgreSQL cluster rather than a schema in a shared one, an extension is enabled for you alone.

Yes. Every database gets a private, S3-compatible bucket with its own scoped access key that cannot reach any other customer's bucket. It sits in Sydney on the same encrypted volume as your database, is private by default, and works with the standard AWS SDK or CLI, presigned URLs, or any S3 client, with no proprietary API to migrate off. Allowances are per plan: 512 MB on Free, 2 GB on Hobby, 5 GB on Launch and 10 GB on Scale. Know the scope: deleted or overwritten files stay recoverable for 30 days, and buckets are served from Sydney with a cross-state copy in Melbourne that we restore from. That copy holds current versions only and is not an endpoint you can reach, so it guards against losing Sydney rather than against deleting a file. Keep your own master copy of anything you cannot re-create. The backups, point-in-time recovery and cross-state Melbourne archive cover your PostgreSQL database. Object storage is not yet covered by the SLA.

Every database has automated backups with point-in-time recovery, so you can restore to a moment before an incident. A full backup is taken daily at 1am Sydney time, or every hour on Scale, and write-ahead logs are archived continuously in between so recovery is to the second. On Launch you can pick the hour that suits your application. A new database takes its first backup within minutes of being created. 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 365 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 not invoiced — if that ever changes we will give at least 30 days notice first. A workspace with several paid databases gets one invoice with a line per database, so you pay once. Prices include 10% GST.

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 include 10% GST, and you receive a valid GST tax invoice showing our ABN and the GST broken out separately. 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.