Lakebase became PCI-DSS and HITRUST compliant in every AWS region where it runs on 8 September 2026, for workspaces with the compliance security profile enabled. Until then the attestation covered one region, us-east-1, which for a lending platform in Charlotte or a health system in Nashville meant the operational half of the stack was still off the table.
It's on the table now.
Four release notes in five weeks #
The September change is the last of a run. On 5 August Databricks made Lakebase enabled by default in compliance security profile workspaces, including those using the HIPAA, C5 and TISAX standards, so a regulated workspace no longer has to ask for it. On 10 August the first PCI-DSS and HITRUST attestation arrived, for us-east-1. On 14 August the Postgres APIs went generally available, meaning projects, branches, endpoints, databases, roles, credentials, synced tables and catalogs can all be managed through the REST API, the CLI and the Python, Java and Go SDKs, with the console no longer the only route. And on 8 September the attestation reached every AWS region Lakebase serves.
Read together, that is a database moving from "you may try it" to "you may build on it". Each one on its own is a line in a changelog. The sequence is a decision Databricks made about where Lakebase sits in the platform, and the numbers page shows the same decision from the funding side, where Lakebase is one of three products the August round is named for.
Who this was blocking #
Every regulated client we've talked to about Lakebase in the last year had the same first question, and it had nothing to do with Postgres. They asked whether the operational store could hold cardholder or patient data at all, and until August the honest answer was only in one region and only if you enabled it by hand. Teams in payments and healthcare heard that answer and stopped listening, which was the correct thing for them to do at the time, and it cost every one of them a second database, a second set of grants and a second audit that the platform was supposed to have made unnecessary. That conversation is different now. The attestations are the ones the auditors ask for, they apply wherever the workspace lives, and the profile is on by default. What remains is engineering judgment, which is where it should have been all along.
What still needs assessing #
The compliance question closing doesn't close the others, and the Lakebase chapter is deliberate about them. It's Postgres-compatible rather than your existing Postgres, so the extensions and version behaviours you rely on are a real assessment before a migration. The synchronisation with the lakehouse is a pipeline with its own latency and failure modes, and each dataset needs an owner on one side or the other. And the bill accrues like a database rather than per query, which surprises teams who think about spend as cluster uptime.
The APIs going generally available matters for exactly this work. A branch per pull request, a restore timed in seconds, a credential rotated on a schedule: those are the things you'd want scripted before trusting a database with regulated data, and until 14 August scripting them wasn't a supported path.
What to do this month #
If you're building on Databricks in payments, lending or healthcare, check whether your workspace carries the compliance security profile, because if it does, Lakebase is already enabled and already attested in your region. Then take the largest table you'd want an application to write to, put it in a Lakebase project through the API, and measure the three things the chapter says to measure. That is an afternoon.
It replaces a year of assuming.
Update, 23 September 2026 #
Two more Lakebase APIs landed since we wrote this. On 15 September the snapshots API went into beta, letting you create, get, list and delete point-in-time snapshots of a project branch and restore one by creating a new branch from it. On 22 September the backup schedule API followed, also in beta, which reads and sets a root branch's automated snapshot cadence, daily, weekly or monthly, and how long each cadence keeps its snapshots (release notes). The schedule API is available to all Lakebase workspaces.
This fills in the part of the note that said you should time a restore and script the project before trusting a database with regulated data. Until now the recovery story you could write down in a runbook was manual. A cadence you set through an API, with a retention you chose, is the thing an auditor asks to see evidence of, and it is now something you can put in Terraform or a deployment script alongside the rest of the project.
Our position doesn't move, and the reason is the word beta. Attestations are the ones the auditors ask for and they hold in every AWS region, but a backup schedule in beta is not yet a control you should point at in an audit. Set one in a non-production project, take a snapshot, restore it into a new branch and time that, then keep whatever backup arrangement you already trust until the API is generally available.