WattleDB  /  Changelog

What we have shipped

Dated entries, newest first · Last updated 8 October 2026

Only things that are live for customers appear here, with the date they went live. Work that is built but not switched on does not, because a roadmap dressed as a changelog is how a platform ends up describing something it cannot do. Incidents are recorded on the status page.

Hosted Auth and client-side encryption in early access; masked clones paused

  • Hosted Auth is in early access, by invitation. Sign-up, sign-in, password reset, magic links and authenticator-app two-factor for your own app’s users, stored in your own database. It is on the Hobby, Launch and Scale plans, and each plan has a limit on active users a month and on Auth emails a day. Ask us at support@wattledb.com.au to try it.
  • Client-side encryption is in early access, by invitation, on Launch and Scale. Your server encrypts the fields you choose with keys WattleDB never receives, and the console walks you through it, including encrypting rows you already have. The exceptions are stated on the encryption page.
  • Masked clones are paused. On 7 October we said masked clones work again. We believe none has been able to copy its data since then: a missing permission (fixed in this release) and the network isolation added that day both stopped the copy. No masked clone with copied data has existed since then, and clones are not charged at present. Until copying is fixed, creating a masked clone is turned off in the console.
  • The connection pooler now resets each connection between clients, so a session setting made by one client (for example SET search_path) can no longer carry over to another client sharing the pool.
  • A database that has been live is never deleted automatically when it fails to start. It stays marked failed with its data kept, so you can retry or contact support.
  • The console speaks more plainly. SQL results say what happened (“31 rows updated.”), errors say what to do next, and the Auth and Encryption pages use simpler words.
  • The release restarted no customer database, and nothing was required of anyone.

Website update (no database change)

  • This website is easier to use with a keyboard or a screen reader. Every page has a skip link and a main content area, buttons and small text meet the WCAG contrast minimum, links in running text are underlined, and the question-and-answer sections on articles work without a mouse. The new accessibility statement says what we checked and what is not finished yet.
  • Our hosting comparison is corrected. It recommended WattleDB for government and regulated work, which our FAQ says we are not the right fit for yet, and its table counted hosted sign-in, which has not shipped. Both are fixed, and two details about other providers were updated.
  • The developer guide is rewritten as step-by-step instructions with screenshots of the console.

The old shared backup credential no longer works

  • Until 25 September every customer database wrote its backups with one shared storage credential. Its secret has now been changed. The old secret is now refused, so a copy of the shared credential taken before 7 October no longer works.
  • Since 25 September each customer database has used its own credential, which reaches only its own backups (25 September).
  • WattleDB’s own platform credentials can still reach backups, which is how restores and disaster recovery work.
  • No customer database restarted, and nothing was required of anyone.

Masked clones work again, and the Dashboard shows each database’s real state

  • Masked clones work again. From early September, a masked clone could not be created: it stopped before copying any data. The copy and the masking now happen in one step, so a clone that fails is left empty. Masked text is cut to fit its column, and the source database’s pg_cron schedules are not copied onto the clone.
  • Masked clones are not charged at present. The clone and extend pages showed a price “added to your next invoice”, and no invoice ever included it. The pages now say what happens.
  • The Dashboard’s Status column shows each database’s real state. It could say OK for databases that had failed, were paused or suspended, or were still being set up. Its colours are also easier to read in both light and dark themes.
  • A plan can be changed only while the database is running or paused. For any other database, the plan page now says why.
  • Security advisories in three components the console and the platform are built on are cleared. None of them could be reached the way WattleDB uses those components.
  • The release itself restarted no customer database, and nothing was required of anyone.

The console runs on Next.js 15

  • The console now runs on Next.js 15. It was on 14.2.35, the last release of that line, which carried 23 published security advisories with no patched 14 available, two of them rated critical. One critical advisory is in the framework’s image-optimisation feature, which the console never used, and we checked the running image for the image library it needs and found none; the other affects only servers running on Windows, and the console runs on Linux. The upgrade clears all 23, and the image-optimisation endpoint is now switched off outright.
  • Not cleared yet: four advisories in a build-time dependency of Next.js (postcss) are fixed only in the next major version. They need a stylesheet written by someone else to matter, and every stylesheet in the console is ours. We will clear it with that upgrade.
  • Nothing you see or do in the console changes, and no database was affected.

Restoring to a backup you choose works again, and the Backups page says what is true

  • Restoring to a specific backup from the list works again. Choosing a backup on the Backups page did not do what it said. The restore either never started, or came up recovered to a moment slightly different from the one you chose. Restoring to Latest was never affected. This was wrong from 18 September, when choosing a specific backup was added, until now. A restore that never came up was never billed.
  • A backup taken minutes ago can now be restored straight away. Taking a backup by hand and restoring it immediately was refused with a message about recent changes not having reached the backup archive yet. That limit applies to a moment you type in, not to a completed backup you pick from the list.
  • Backups older than your plan’s recovery window are now shown as unavailable in the restore list, instead of being offered and then refused after you had already confirmed a new database.
  • A failed database can now be deleted from the console, under Settings on the database’s own page. Until now a failed build offered only Retry, so there was no way to clear it away yourself.
  • A build the platform can already tell will never finish now stops sooner, instead of sitting on “provisioning” for a further twenty minutes with nothing you could do to it.
  • Several wrong messages on the Backups page have been corrected, including one that said a database’s scheduled backups stop while a restored copy of it exists. They do not, and have not since 9 September. A restore only ever creates a new database: the one it is taken from is never written to and is never paused.

Every database backs up with its own storage credential

  • A database’s backups are now written and read with that database’s own storage credential, and that credential reaches only that database’s own backups. It cannot read, write or delete the backups of any other database.
  • It was applied to every existing database during the release: no database restarted, no connection was dropped, and nothing was required of anyone.
  • Know the scope: this is a limit on what each database’s own credential can reach. It is not a claim that nothing else can reach your backups. WattleDB’s own platform credentials can, which is how restores and disaster recovery work, and the docs and the SLA have always said so.

A year of logs in the console, and planned maintenance announced ahead

  • The Logs tab now searches the full 365 days we keep, not only the last 30.
  • Planned maintenance that could interrupt a running database is now approved at least 72 hours ahead, emailed to everyone in the workspace and posted in the console. The SLA aims for at least 48 hours.
  • Turning on two-factor authentication now signs you out on your other devices, so each of them has to log in again with a code.
  • A workspace in its first month could be sent to add a payment method before creating a masked clone, with no way to do so. That is fixed.
  • A paid invoice now shows the date it was paid.

The recovery path was tested, and the date is published

  • We ran a restore drill and it passed. A marker row was written, a second was written later, and the database was then restored to a moment between them: the first row came back, the second correctly did not. That tests point-in-time precision, not just that a backup file exists.
  • The restore took 106 seconds on the drill database. Recovery time scales with database size, so treat that as proof the path works rather than as a recovery time for a large database.
  • The source database kept serving throughout, because a restore provisions a separate database and reads the archive rather than overwriting anything.
  • The date of the most recent drill is now shown on the status page, and is updated after each drill. Before this, no drill had ever been run, and the site did not claim one had been.

PostGIS, pg_cron and query statistics on every database

  • PostGIS 3.6 is installed and ready on every database, with raster, topology and pgRouting available. Geospatial types resolve without qualifying them.
  • pg_cron lets you schedule jobs inside the database with cron.schedule(). Jobs run as the role that created them, not as a superuser.
  • pg_stat_statements is enabled, so you can see which queries are actually slow rather than guessing.
  • Every database moved to PostgreSQL 17.11 on an image we build and maintain ourselves, which takes a third-party registry out of the path when your database starts.
  • The cross-state copy of object storage in Melbourne is running, verified by writing a file in Sydney and matching its checksum in Melbourne. It is a copy we restore from, not a second endpoint you can reach, and it guards against losing Sydney rather than against deleting a file.

pgvector, and extensions installed rather than requested

  • pgvector for embeddings and similarity search, enabled on every database.
  • Extensions are now installed for you rather than raised as a ticket. Because every database is its own PostgreSQL cluster rather than a schema inside a shared one, enabling one affects nobody else.

Cancel a paused database, and send feedback from the console

  • A subscription paused for an unpaid invoice can now be cancelled. Previously the only action left was Delete, which destroys the database and its backups; cancelling keeps your bucket readable so you can get your files out.
  • Feedback from any workspace member, straight from the console.

WAL archiving is checked, not assumed

  • Platform health checks now include the write-ahead log archive, so a backup pipeline that has quietly stopped is noticed rather than discovered at restore time.

Restore to the second, and masked clones

  • Point-in-time recovery is self-serve to the second from the console, rather than choosing from a list of backups.
  • Masked database clones: a copy of your database with personal fields masked, for giving developers or contractors something realistic to work against.
  • We also took a Free-tier database offline for 6 hours 51 minutes through our own bug on this day. It is written up in full at the incident report.

S3-compatible object storage

  • A private, S3-compatible bucket on every database with its own scoped access key, working with standard S3 tooling and presigned URLs. Deleted or overwritten files stay recoverable for 30 days.

Encryption at rest

  • Full-disk encryption on the Sydney data volume, and server-side encryption for backups held in Melbourne.