Microsoft's September 25, 2026 Azure update confirms that Azure HorizonDB now includes PostgreSQL 18 support in public preview. It is a new engine-version milestone for the managed PostgreSQL-compatible service, not an announcement of general availability. Read the Azure update.
For teams already evaluating HorizonDB, this creates a useful opportunity to revisit application compatibility. My recommendation is to make the next evaluation specific: prove one representative workload, its required extensions, and its operating requirements on the intended version.
A version number is a starting point for that work. It is not the acceptance test.
What Is New, and What Is Not
The news is PostgreSQL 18 support in HorizonDB, not the original PostgreSQL 18 release. The upstream project released version 18 on September 25, 2025. Its release notes describe changes including asynchronous I/O, additional multicolumn B-tree skip-scan opportunities, timestamp-ordered UUID generation, and virtual generated columns. PostgreSQL 18 release notes.
Those upstream capabilities are useful inputs to an evaluation. They should not be converted into a blanket claim that every engine feature, configuration option, or performance result is available unchanged in a managed Azure service.
My proposed test plan would connect each feature of interest to an application requirement. If a capability does not improve a query, simplify a supported workflow, or address a real compatibility need, it does not need to dominate the pilot.
Watch the Documentation Mismatch
As checked on September 27, 2026, Microsoft's cluster-creation quickstart still says only PostgreSQL 17 is supported, while the newer Azure update announces version 18. Current cluster quickstart.
That is a documentation mismatch, not evidence that your existing cluster has already upgraded or that a particular upgrade procedure is supported.
Before scheduling the pilot, I would confirm the version options exposed for the intended subscription and region, and seek clarification from Azure support if they do not match the announcement. Record the actual server version after connecting.
Keep the deployment method and configuration with the test results. If another engineer cannot reproduce the target environment, it will be difficult to separate an engine-version difference from a deployment difference later.
Start with Extensions and Application Behavior
HorizonDB supports a subset of PostgreSQL extensions, requires extensions to be allowlisted, and does not support bringing arbitrary extensions into the service. Microsoft's documentation points to supported-extension lists by name and PostgreSQL version. Extension support and creation requirements.
My first compatibility review would inventory extension names and versions, schema objects, client libraries, connection settings, and the application's most important transactions. Include background jobs and reporting paths rather than testing only the application's landing page.
For each dependency, distinguish between confirmed support, a successful test, and an unresolved question. Those are different forms of evidence. A successful import does not establish that every scheduled task or maintenance operation behaves as expected.
I would also test with the intended application account. An administrator-level smoke test can hide missing permissions or assumptions that only surface when the normal workload starts.
Benchmark a Question You Can Answer
The upstream release notes describe potential performance improvements; they do not establish an application's results on HorizonDB. Engine changes in PostgreSQL 18.
My suggested benchmark would begin with a concrete question, such as whether a frequently executed query meets its latency target under representative concurrency. Keep the dataset, query parameters, client location, and connection behavior comparable between runs.
Record query plans and resource use alongside timings. Repeat warm and cold runs where they reflect actual application behavior, and report the spread of results rather than only the fastest execution.
Avoid changing the engine version, schema, indexes, application code, and capacity simultaneously in the first comparison. A large improvement is much more useful when the team can explain which change produced it.
These are proposed evaluation steps, not benchmark results from a deployment I have performed.
Preview Limits Still Matter
The current HorizonDB overview lists seven-day backup retention, no configurable retention or long-term retention, no cross-region read replicas, no customer-managed encryption keys, and no configurable maintenance windows. It also says built-in PgBouncer is not yet available, although an external pooler can be used. These are documented service limitations, separate from the engine-version announcement. HorizonDB preview limitations.
I would review those boundaries before expanding a technical pilot into a production proposal. Write down which requirements are mandatory and which are negotiable; do not turn an unavailable mandatory capability into an undocumented exception.
Keep sensitive production data out of an exploratory test unless the organization has explicitly approved its use and controls. A representative synthetic or appropriately sanitized dataset can often answer the first compatibility questions without broadening the exposure.
Practical Cloud Engineer Takeaway
My proposed adoption checklist is:
Confirm PostgreSQL 18 availability for the actual deployment target.
Record the running server version rather than inferring it from a news headline.
Check required extensions and their supported versions.
Exercise important transactions, jobs, and client-library behavior.
Compare query results and performance with a controlled baseline.
Review backup, maintenance, encryption, and recovery requirements separately.
Keep a clear decision record: proceed with evaluation, resolve a gap, or defer.
Who Should Care?
PostgreSQL application teams and Azure platform engineers evaluating HorizonDB, particularly those whose next design depends on PostgreSQL 18 behavior.
Bottom Line
PostgreSQL 18 broadens the HorizonDB evaluation conversation. The next useful milestone is a reproducible workload test with explicit compatibility and operational evidence, while keeping the public-preview boundary visible.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments