If your agency runs Azure SQL, SQL Server or Oracle today and PostgreSQL keeps coming up in conversations about cost, this is the question that decides whether those conversations go anywhere: can it meet your Essential Eight obligations? The answer is yes — and the path there is shorter than you may expect.
Most government technology leaders we speak with aren't asking whether PostgreSQL is a capable database. That argument is over — it runs critical workloads across government and finance worldwide, and Microsoft operates it as a first-class managed service on Azure, sitting in the same portal, the same subscriptions and the same governance framework as the Azure SQL estate you are likely to be already be running.
The real question is a governance one: if we adopt Azure Database for PostgreSQL Flexible Server, can we still demonstrate Essential Eight Maturity Level Two?
It deserves a straight answer, so here it is: yes — with additional configuration we detail below. Not with defaults, and not with any third-party product either. ML2 on Flexible Server is a matter of roughly a dozen configuration and process decisions, all made with tools your teams already use: Entra ID, Azure Policy, Azure Backup and Azure Monitor.
One caveat before the detail, because accuracy matters when assessors are involved: no database product "is" ML2 compliant by itself. The Essential Eight is assessed across your environment, and the database layer is in scope for four of the eight strategies. What follows maps exactly what an assessor will look for at the database layer, what Flexible Server does out of the box, and what closes the gap.
ML2 requires MFA for privileged users of systems. A freshly provisioned Flexible Server authenticates administrators with a PostgreSQL username and password — no MFA, and an immediate assessor finding.
The fix: enable Microsoft Entra ID authentication and set the server to Entra-only. Every administrative connection then flows through the same Conditional Access policies — and the same MFA — that already protect your Microsoft 365 and Azure estate. Database access stops being a separate identity silo with its own passwords and becomes part of the identity governance you already operate. This is, frankly, a stronger position than most on-premises SQL Server and Oracle estates ever reach, where database passwords often are outside the corporate identity system entirely.
ML2 requires that privileged access is limited, requested and revalidated, and that privileged access events are centrally logged. The Information Security Manual is also explicit (ISM-1815, tagged to ML2 and ML3) that event logs are protected from unauthorised modification and deletion.
Out of the box, Flexible Server records almost nothing about what administrators do, and what it does record stays on the server.
The fix is three settings and one design decision:
The ML2 requirements here are less about taking backups — every platform does that — and more about who can access, modify and delete them. The default Flexible Server backups have a weakness an assessor will find in minutes: they live with the server, so an administrator (or attacker) who can delete the server destroys the backups with it.
The fix: protect the server with an Azure Backup vault, with long-term retention aligned to your records obligations, vault immutability enabled, and vault access RBAC-separated from database administration. The people being backed up cannot be the people who can delete the backups. Only allow separate administrators to manage the backup storage (including any immutable vaults), whilst the DBAs are likely to be included in their initial configuration, verification and documentation, after that implementation, revoke all privileges and document this.
Everyone's favourite! Don't we all love patching? Here the managed platform does most of the work for you — and this is where the comparison with your on-premises estate becomes uncomfortable in PostgreSQL's favour. Microsoft applies engine patches in your nominated maintenance window; there is no patch bundle for your DBAs to schedule, stage and apply, and no quarterly patching project. What your agency still owes the assessor is evidence: that instances are on supported versions, and that major-version upgrades happen before support retirement. That's a report and a process, not an engineering effort. Goto https://learn.microsoft.com/en-us/azure/postgresql/configure-maintain/concepts-version-policy for details of PostgreSQL's lifecycle policy on Azure. The PostgreSQL community supports each major version for approximately five years from release, with a new major version arriving annually and minor security and bug-fix releases issued regularly in between. Azure Database for PostgreSQL Flexible Server supports each major version from the date Azure begins offering it until the community's end-of-life date, applying minor-version patches automatically during scheduled maintenance. For workloads that can't upgrade in time, Azure offers paid Extended Support, which continues critical security patches for up to three years beyond community end-of-life — a bridge for upgrade planning, not a destination.
Anyone who has lived through a year of Oracle monthly or quarterly patching cycles, or SQL Server cumulative update regression testing, will recognise the size of what just left the to-do list.
There's another point worth mentioning: ASD's own assessment guidance ranks evidence quality — from excellent (a control tested in operation) down to poor (a policy document). Most agencies demonstrate database controls with screenshots and configuration exports, which sit in the middle of that scale.
Everything described above is assessable. But how efficiently it's assessed — and how confidently it holds at ML3, where requirements extend to monitoring, actioning and stronger log protection — depends on how the evidence is produced. That's a topic we'll return to in a future article, because we think the PostgreSQL ecosystem can do something here that no other database platform currently offers.
Everything above establishes that Flexible Server can carry your compliance obligations. What makes the exercise worth doing is what it removes:
For most Oracle workloads we assess, and a substantial share of SQL Server ones, the total cost reduction is not a close call. It's routinely the largest line item a database strategy review surfaces.
We've spent years on both sides of this fence. Our consultants come from deep Oracle and SQL Server backgrounds — licensing, patching, high availability, the lot — and we now migrate those workloads to PostgreSQL, including onto Flexible Server, for government and regulated-sector clients. That means the migration conversation starts from what your estate actually does today, not from a product brochure.
We also put our understanding of PostgreSQL on the public record. Pebble IT builds and releases open-source PostgreSQL extensions, designed specifically to work on managed platforms like Flexible Server where conventional extensions can't be installed:
There are others, but we feel these are the most relevant for an Azure Flexible Server for PostgreSQL implementation. We have been working on these for some time and we have others in the pipeline. These translate to capability that would otherwise require custom development or additional products — and because they're open source, they arrive with no licence cost and full transparency for your security reviewers. It also demonstrates a deep understanding of PostgreSQL that translates to being able to solve your current challenges on PostgreSQL.
PostgreSQL on Azure Flexible Server is not a compromise you accept to save money. Configured intelligently, it meets Essential Eight ML2 at the database layer using the Azure governance tools your teams already know — while removing the licensing cost and patching burden that your current platforms impose. The work is a defined, bounded configuration exercise, and it's one we've done.
If ML2 is on your agenda and PostgreSQL is in the conversation, we're happy to walk your team through the control mapping against your actual environment — assessor's lens, no obligation.
