PostgreSQL compatibility starts a semantics audit

A PostgreSQL client connecting successfully to a new database proves that a connection worked. It does not prove that an application preserves its business rules. Aurora DSQL's December 2024 preview made that distinction especially useful: familiar interfaces can reduce migration work, while transaction and schema assumptions still need an explicit audit. Compatibility should begin that audit rather than close it.

Writing in November 2026, the relevant historical event is AWS's 3 December 2024 preview announcement. It described a serverless distributed SQL database with PostgreSQL compatibility and active-active operation. Preview geography was US East (N. Virginia), US East (Ohio) and US West (Oregon). Those are launch conditions, not a statement of the service's current geographical availability.

Start with the rule the database protects

Imagine a booking application that must never allocate the same place twice. Its correctness depends on what happens when two transactions overlap, which constraints the database enforces and how the application handles a transaction that cannot commit. Recognizable SQL syntax does not answer those questions. The example is a proposed review scenario, not an AL+ deployment or a test performed for this article.

A useful audit begins with a business invariant written in ordinary language. Then trace the database operations that protect it. Identify the read that informs a decision, the write that records it and the constraint that rejects an invalid outcome. Record the assumptions connecting those operations. A migration can preserve every table name while changing whether that reasoning still holds.

Next inspect what happens outside the database. If the application sends a confirmation before a transaction commits, retrying the transaction can have consequences beyond SQL. A retry strategy must account for external effects and user-visible outcomes. This is general application design reasoning; it is not evidence that DSQL specifically caused duplicate confirmations or that a particular retry policy has been validated.

Treat the preview's omissions as historical evidence

AWS's launch article establishes the December introduction. A contemporary note by Simon Willison recorded unsupported features including views, triggers, sequences, foreign keys and extensions. That list describes the preview as reported on 3 December 2024. It must not be copied into a present-day procurement checklist as if support had remained unchanged.

The list nevertheless explains why a semantics audit matters. A foreign key can carry a business rule that an application author no longer thinks about every day. A trigger can perform work absent from the application's explicit queries. Removing either obligation from a migration inventory does not remove it from the product. Someone must decide where the rule will live and how every write path will respect it.

An extension can be equally decisive. If a reporting or search feature depends on behavior supplied by an extension, a compatible connection protocol cannot replace that dependency. Inventory the feature actually used, including its operational behavior. Broad labels such as “uses PostgreSQL” conceal precisely the details that determine migration scope.

Geography belongs in the same review

Launch-region availability is not an incidental footnote when a database is selected for distributed operation. The locations where a service can run shape the architecture available to the application. A team serving users elsewhere must evaluate network paths and operating requirements rather than assume that a multi-region product offers every desired region combination.

This does not establish a legal conclusion about data location, nor does it quantify latency. It identifies a dependency to investigate. A database's advertised architecture, the regions actually available and the application's deployment topology are separate facts. A migration proposal should connect them explicitly before estimating effort or promising an outcome to the business.

The cost of missing that connection can appear as redesign work after the initial proof of connection succeeds. A team may discover that its assumed deployment location is unavailable or that a particular schema mechanism carries more of the product's behavior than expected. These are plausible failure modes to prevent, not reported customer incidents.

A supported subset can be enough

The strongest counterargument is that many applications use a modest relational subset. A new service need not reproduce every PostgreSQL feature to serve them well. If the required operations and geography fit, distributed operation and reduced infrastructure responsibility may justify deliberate constraints. Demanding complete equivalence can reject a useful architecture for capabilities the product never needs.

The answer is a bounded compatibility claim. State which business operations are included, which database features they use and which deployment locations are required. Do not let a successful narrow prototype become evidence for unrelated reports, imports or administrative scripts. Those paths often exercise different parts of the schema even when the user interface looks simple.

For a present-day decision, refresh the vendor's support matrix and service conditions. This retrospective does not establish current feature support, pricing, an availability guarantee or migration readiness. It uses the preview to show how to separate a familiar development surface from the behavior a product relies on.

In custom software development, a useful first deliverable is an inventory of invariants and their enforcement points. Choose one consequential operation, describe its overlapping-transaction case and trace its failure response through to the user. Only then ask whether the candidate database supports that contract. PostgreSQL familiarity makes the investigation easier to start; the application's semantics determine whether it is finished.