Dated entries, newest first · Last updated 8 September 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.
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.