Microsoft is betting that the integration of HorizonDB, the cloud-native PostgreSQL alternative it is developing, with Azure will attract more enterprise AI and agentic workloads to its cloud services.

Enterprises may not be willing to take that bet.

It’s been nine months since Microsoft unveiled HorizonDB, but the service remains in public preview with no announced general availability date. Why put AI projects on hold waiting for HorizonDB to arrive, when AWS, Google, Databricks, Snowflake, and others already have production-ready PostgreSQL services positioned for the same AI workloads that Microsoft says it is building HorizonDB to handle?

AWS has had the longest head start. Aurora PostgreSQL became generally available in 2017 and has since evolved from a cloud-native PostgreSQL database into an AI-ready service with vector search and integrations with Amazon Bedrock. Similarly, Google’s AlloyDB, which followed in 2022, now includes AlloyDB AI with vector search, embeddings and model interaction for generative AI and agentic applications.

Databricks and Snowflake, too, have their own platform-centric services in the form of Lakebase, which became generally available on AWS and Azure this year, and Snowflake Postgres, which was made generally available in February 2026.

As the latecomer, when Microsoft pitched HorizonDB at Ignite in November 2025 it talked up its new architectural approach to cloud-native PostgreSQL, built around disaggregated compute and storage and a database-as-log design. The hyperscaler also positioned native vector search and deep integration with Foundry and Fabric as key differentiators for AI-heavy workloads.

No reason to wait

Those architectural differences may not be compelling enough for CIOs to wait for HorizonDB to become generally available, though.

“Most enterprises with urgent needs will not wait. A long preview window creates uncertainty around SLAs, pricing, operational maturity, and roadmap confidence,” said David Linthicum, an independent cloud consultant.

And, said Stephanie Walter, practice lead of AI stack at Hyperframe Research, enterprises cannot build mission-critical production plans around an undefined GA date, regional footprint or support commitment.

Given the difficulty of unwinding a poor database choice, enterprises will approach unknown quantities with caution.

“Database platforms eventually become sticky control points. Once the database is connected to the rest of the application, analytics, AI, and governance stack, switching becomes a business transformation rather than just an infrastructure swap,” said Michael Ni, principal analyst at Constellation Research.

In the case of a cloud database, there’s also the unwelcome possibility of “huge egress fees” in case of change, said Bradley Shimmin, lead of the data and analytics practice at The Futurum Group.

All that uncertainty is likely to lead enterprises to restrict HorizonDB to experimental use cases for now, Shimmin added.

Performance anxiety

Analysts also questioned whether HorizonDB’s technical differences will show up in performance benchmarks.

Microsoft has said HorizonDB can deliver up to three times the throughput of open-source PostgreSQL, but makes no comparisons with rival offerings such as Aurora or AlloyDB that it will compete with, Walter said.

The bigger question, according to Igor Ikonnikov, advisory fellow at Info-Tech Research Group, is whether those performance advantages, still largely on paper, translate into a meaningful difference in production.

“A database with a better compute benchmark can still be more expensive once resilience and ecosystem costs are included,” Ikonnikov said.

The economics also point to another HorizonDB limitation, particularly for workloads that are not continuously running, said Advait Patel, senior site reliability engineer at Broadcom.

HorizonDB currently uses provisioned compute rather than a serverless, scale-to-zero model, meaning customers continue to incur compute charges while an instance is provisioned, even if its workload is intermittent or idle, Patel said.

There are developer considerations too.

HorizonDB’s PostgreSQL compatibility does not necessarily mean every existing PostgreSQL application will move cleanly as in its current form the database supports only an approved set of PostgreSQL extensions rather than arbitrary ones, Walter said.

Who should wait?

For enterprises already deeply invested in Microsoft’s Azure ecosystem, those limitations may not be enough to rule out waiting for HorizonDB, Patel said: The chance to integrate the database with AI services and the wider Microsoft stack may outweigh immediate availability, he added.

That calculus also reflects how enterprises typically make database decisions in the first place: not by comparing databases in isolation, but by weighing how well they fit into the broader technology stack, including the cloud platform they have standardized on, Ikonnikov said.

For Azure shops, the choice may therefore be less about moving an existing workload away from Aurora or AlloyDB and more about whether a new Azure workload should start on Azure Database for PostgreSQL today or wait for HorizonDB when it becomes available, he said.

That may be an open question for some enterprises, said Devin Pratt, research director at IDC. “Plenty of organizations are still mid-decision, not locked in,” he said.

Microsoft finally offers a timeframe

Microsoft still won’t say exactly when HorizonDB will launch, with Shireesh Thota, corporate vice president for Azure Databases at Microsoft, saying only, “General availability for Azure HorizonDB is currently targeted for the second half of 2026.”

That narrows it down to a period of a little over four months, including Microsoft’s FabCon and Ignite conferences — an eternity in AI.

This article first appeared on InfoWorld.

Oracle on Tuesday described new EBCDIC character set compatibility features in Oracle AI Database for customers transitioning from legacy databases on IBM mainframes.

In its post, Oracle noted that EBCDIC compatibility has historically been one of the top technical challenges for enterprises re-platforming to use newer, ASCII-based databases while continuing to use proven legacy applications.  

“Achieving this goal requires more than simply moving data. It requires preserving the EBCDIC compatibility on which existing applications depend,” wrote Michael Yau, VP for Oracle Database Globalization Engineering. The feature rollout “addresses two fundamental challenges of preserving EBCDIC compatibility: accurate character encoding conversion and preservation of EBCDIC binary ordering.”

He added: “These client character sets implement IBM Character Data Representation Architecture (CDRA) code page definitions, providing source-to-target character mappings that are compatible with IBM’s published standards. This enables accurate and predictable character encoding conversion during data migration and subsequent database client/server communication.”

Yao observed that this is important because these mainframe migrations can be very complex.

“Many legacy EBCDIC applications, such as those written in COBOL, implicitly rely on the EBCDIC binary ordering defined by IBM EBCDIC code pages. SQL predicates that compare character values, perform range searches, or sort query results often assume this ordering,” he wrote. “After migration to an ASCII-based Oracle AI Database character set, these same SQL statements can produce different results, not because the data changed, but because the database’s default binary ordering follows that of the ASCII-based database character set rather than the source EBCDIC code page.” 

Compatibility repair, not modernization

While consultants generally applauded the new features, some questioned whether this will simply shift enterprise dependency on IBM to dependency on Oracle. 

Sanchit Vir Gogia, chief analyst at Greyhound Research, is one of the fans.

“Oracle has repaired one of the oldest silent faults in mainframe migration: EBCDIC ordering, the muscle memory of the legacy estate. Preserve the data and lose the ordering, and a query returns the wrong record while every dashboard stays green,” he said. “The application runs and the query completes. The answer is simply wrong.”

Gogia noted that the new feature is “not a modernization suite. It is a compatibility repair, narrow and genuinely useful, which CIOs who have bled on past migrations will read with equal parts relief and suspicion.”

AJ Thompson, CCO at UK IT consulting firm Northdoor, agreed that the Oracle announcement addresses a genuine technical barrier rather than just being a marketing gimmick, so it is worth taking seriously as a re-platforming enabler. “The two problems it solves, EBCDIC to ASCII character conversion and preserving EBCDIC binary sort ordering, have historically been real blockers for allowing COBOL to move away,” he said.

But, he cautioned, CIOs must also take resiliency challenges seriously. “Mainframes are not chosen primarily for character encoding, they are chosen for benefits like decades of proven uptime, IBM Z’s redundancy architecture, and workload isolation,” he pointed out.

“Oracle’s announcement solves a data compatibility problem, not a resilience or availability one. A client with genuinely mission-critical, zero-downtime workloads will still need convincing on the availability and disaster recovery side before moving [to the cloud], and Oracle’s own resilience claims would need scrutiny on their own merits, quite separate from this EBCDIC work.”

Leverages IT desperation

Mike Wilkes, enterprise CISO at Aikido Security, added that Oracle is leveraging IT desperation to squeeze long-term value from legacy systems. 

“I have always believed that Oracle will own the very last white-knuckle-grip workloads that migrate from on-premises data centers into the cloud,” he said. “This announcement certainly demonstrates that they understand their position in the world of cloud service providers. They are not the biggest, they are not the oldest, and they are not the most technically advanced. But they do own the market share for the trailing edge of cloud adoption.”

He pointed out that the greatest barrier to cloud migration is not containerizing modern applications, it is the decades of business logic buried inside COBOL applications and EBCDIC-encoded data.

“Oracle’s EBCDIC compatibility features acknowledge a practical reality: organizations are not rewriting these systems from scratch,” he said. “If Oracle can reduce the cost, risk, and operational disruption associated with moving those workloads, the announcement represents meaningful value for IT teams that have been delaying modernization because the migration path was simply too complex or too expensive.”

Could cause vendor lock-in

Then again, Wilkes noted, there is the potential for increasing vendor lock-in.

“Compatibility layers almost always increase long-term dependence on the platform providing them,” he said. “Rather than eliminating legacy technology, they abstract it behind Oracle’s database and cloud ecosystem, making future migrations potentially more difficult. Enterprises should view these tools as transition accelerators rather than permanent architecture.”

Thus, he said, if they use the opportunity to gradually modernize applications and data models, there is substantial value, but if they simply relocate technical debt into Oracle Cloud, they may find that they have exchanged one form of legacy lock-in for another.

Easier, but not easy

Matt Kimball, VP and principal analyst with Moor Insights & Strategy, also saw the Oracle move as a good one, but stressed that while it should make things easier for organizations, re-platforming still won’t be easy because EBCDIC migration isn’t just a character-conversion exercise. However, “Oracle’s built-in character-set support and EBCDIC collations move part of that compatibility burden into the database, making it easier to preserve existing application behavior,” he said.

Ishraq Khan, CEO of coding productivity tool vendor Kodezi, agreed. 

“One of the biggest obstacles to leaving mainframes is decades of applications built around EBCDIC encoding and legacy data formats. If these compatibility features reduce the amount of code that needs to be rewritten, they can lower migration risk, cost, and implementation time,” Khan said. But, he added, organizations should also consider whether these features simply make migration easier, or make future moves more difficult.