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.

It used to be that the value and reputation of coding contest winners was very high. That’s no longer the case. Who cares how fast you can produce code that implements an algorithm or solves a problem? Your competition is no longer other people, at least not by themselves, but AI combined with insightful prompting and good taste.

Historically we wrote all our code ourselves and then we tested it ourselves. Yes, there was a period when we outsourced punching our cards to what was essentially a secretarial pool, but we were still writing out the code and doing all the thinking involved in the programming. Over the years we outsourced some of the testing to a QA department, allowed software to guess at what we were typing and complete it, and allowed code-checking software to run in the background as we typed.

Allowing software to help us by guessing what we mean advanced from word completion to line completion to function completion to program generation over a matter of about a decade. Currently a good model running in a good agent harness or IDE can look at your code, suggest improvements, compile and test the improved code, iterate on that, and then come up with something better, faster, more efficient, and more solid.

That shifts the burden from actually programming to reviewing and testing the code. If you don’t even review and test the code, then what you’re doing is vibe coding. Vibe coding doesn’t give you a lot of control over the end product. It is only really efficient at generating quick prototypes and creating technical debt. It’s just not enough structure.

One attempt to add more structure and to control what the model actually generates is specification-driven development (SDD). SDD works, because a spec grounds the model in a single source of truth. However, SDD often comes at the expense of taking too much effort and really being overkill for what you usually need.

Developers are still floundering, wondering how to strike a balance between vibe coding and spec-driven development. One possible approach is behavior-driven development. Another is a variation on test-driven development, sometimes called “facts first.” A fact in this context is an executable invariant tested by a machine. Finally, there’s intent-driven software development (IDSD), which is a new take on the old craft of intent, context, and expectations (ICE).

Meanwhile, we have perhaps a dozen options for IDEs and another dozen options for agent harnesses and many dozens of models that do a good job of generating code. Here I’ll provide a brief tour of six of them: GitHub Copilot, Google Antigravity, JetBrains Air, Kiro, Zed, and Zenflow.

GitHub Copilot

First offered as a plug-in to Visual Studio Code in 2021, GitHub Copilot was one of the first AI plug-ins for coding assistance. Today, you can use GitHub Copilot in a slew of IDEs for code completion, generation, explanation, and debugging. In addition to VS Code, GitHub Copilot is available for Visual Studio, Vim, Neovim, and the JetBrains suite of IDEs. You can also use Copilot on the command line, both through the GitHub Copilot CLI and as an extension to the GitHub CLI. You can also use it directly on the GitHub website.

Currently there are about two dozen supported AI models in GitHub Copilot, including models from OpenAI, Anthropic, and Google. In Visual Studio Code you can add more models than the ones available by default with your Copilot subscription. For example, if you open the Manage Language Models panel in VS Code, you can select models from Foundry Local via AI Toolkit, GitHub Models via AI Toolkit, Microsoft Foundry via AI Toolkit, and, at least in my case, local models via Ollama. Local Ollama models don’t count against your Copilot plan, but they do occupy GPU or unified memory, depending on your hardware configuration.

GitHub Copilot currently has three default operating modes: Plan, Ask, and Agent. Plan mode researches and outlines multi-step plans. Ask mode chats with you without making changes. And Agent mode edits files in your workspace. You may also have custom modes, some of which are supplied by plug-ins; I have 16 of these. You can create your own custom modes if you wish.

GitHub Copilot currently has nine categories of default tools used by agents; each category may have many actual tools listed. Additional tools come from connected Model Context Protocol (MCP) servers and installed plug-ins. My installation currently has 346 tools available, which is nuts. At one point VS Code would warn you if you had too many tools active, but that doesn’t seem to be happening anymore.

AI agents are autonomous helpers that perceive their environment, decide on a course of action, and execute it. They break large tasks into smaller steps, draw on available tools and resources, reason about approach, and adjust their plans on the fly, all while following user directives until the goal is met. While most agentic code edits complete in seconds or minutes, some can run for hours with only a few requests for permission.

In light of that, it’s not surprising that GitHub switched to usage-based billing for GitHub Copilot. Effective June 1, 2026, GitHub tracks your token consumption rather than your Premium Request Units. Code completions and next edit suggestions are exempt from token limits.

Google Antigravity

The original Google Antigravity (from way back in November 2025) was built as an agentic development platform, essentially a version of the VS Code “Code – OSS” IDE that Google developers use internally, which was repurposed for the sorts of repositories that mere mortals work with on normal-sized products. (Google’s internal software mono-repository is so large and complex that ordinary software tools can’t work with it; Googlers use Piper, an internal tool for version control, rather than Git.)

On May 19, 2026, Antigravity became the basis for a new ecosystem. Google Antigravity 2.0 is a standalone desktop application that is an independent, agent-focused surface, evolved from Antigravity’s Agent Manager. The new Google Antigravity IDE is a separate download that looks similar to the previous Antigravity. The Google Antigravity CLI is a way to invoke, monitor, and interact with Antigravity agents from your terminal. In addition, the Google Antigravity SDK is available to build custom agents.

Google Gemini 3.6 Flash is the default model on Google Antigravity. According to Google it’s their strongest agentic and coding model yet, as well as being faster than other frontier models on Antigravity. Gemini 3.6 Flash can be selected at three effort levels: low, medium, and high. Antigravity also supports Gemini 3.5 at low, medium, and high levels; Gemini 3.1 Pro at two effort levels; Anthropic’s Claude Sonnet 4.6 and Opus 4.6 with thinking enabled; and GPT-OSS-120B at medium effort. The general guidance is to use the lowest level of effort that will successfully execute your task to minimize token use.

The “+” dropdown in the prompt box allows you to add context to the prompt. Both Antigravity 2.0 and Antigravity IDE allow you to add media, mentions, and actions. Antigravity 2.0 also allows you to enable the browser from the “+” dropdown; it simply adds the /browser slash command to the prompt.

The Antigravity browser subagent is the rough equivalent of Playwright or the Microsoft Foundry Browser Automation tool. It can click, scroll, type, read console logs, capture the DOM, take screenshots, and record video. The browser subagent also integrates natively with the Chrome DevTools MCP.

The other internal slash commands for both SKUs are /goal, which means to run until the specified task is completely finished, not asking for intermediate input from the user; /grill-me, which means to ask questions back to align on the specific details of the plan before implementing it; and /schedule, which means to run an instruction as a one-time timer in the future or on some recurring schedule (via Scheduled Tasks). Any skills provided by plug-ins or by installed Model Context Protocol servers can also be selected by typing a slash into the prompt box.

Antigravity 2.0 and Antigravity IDE support skills both at the workspace and global levels. A skill requires a SKILL.md file with YAML frontmatter at the top, and supports optional scripts, examples, and resources. The YAML description field is key to allowing an agent to recognize when the skill is relevant. Skills that come with MCPs or plug-ins take no effort to install. Creating custom skills requires you to add a named skill directory and the SKILL.md file.

JetBrains Air

JetBrains Air is an agentic development environment that allows you to delegate coding tasks to AI agents. It supports four agent providers: OpenAI Codex, Anthropic Claude, Google Gemini, and JetBrains’ own Junie. You can provide your own subscriptions or API keys for OpenAI, Anthropic, and Google to Air, or rely on JetBrains’ hosting via a subscription.

When you create a new task for JetBrains Air, it can run in a local workspace, a Git worktree, or an isolated Docker container. Once you have set it up properly, you can also run a new task in the cloud, starting either from your local machine or from a browser.

You can select an agent provider and model at this time. You can switch the agent only when you create a new task; you can change models within an agent at any time. There are four levels of permissions ranging from plan first to full access. For some agents you can select an effort level. You can provide context to the chat from a number of sources, including files and folders, documentation, Git branches, and several others.

To test Air, I gave it the prompt “try to improve on the performance of this pi calculator. Do your work in a new directory called air.” I used Claude Sonnet 4.6 (1M context window) and high effort with Ask permissions, running the task locally. It did a rather good job, although I got further optimizations later on with other environments.

Kiro

Developed by “a small, opinionated team within AWS” and described as an autonomous agent or virtual developer that learns over time while working independently, Kiro is available both as an IDE (based on Code OSS) and as a CLI tool. Kiro CLI (kiro-cli) doesn’t deal with specs at this point, although it does have a planner agent and agent steering. Kiro IDE (kiro) explicitly supports both vibe coding and spec-driven development (SDD). (See screenshot below.)

Kiro SDD generates three markdown files that together comprise the specification: requirements.md, which captures user stories and acceptance criteria in structured EARS (Easy Approach to Requirements Syntax) notation; design.md, which documents technical architecture, sequence diagrams, and implementation considerations; and tasks.md, which provides a detailed implementation plan with discrete, trackable tasks.

You can also import specs from other systems and iterate on your specs. You can even generate specs based on a vibe-coding session. Ideally, you would create a spec for each project feature.

EARS notation captures user stories and follows the pattern:

WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]

This format is clear and testable. Kiro can generate property-based tests (PBT) based on your EARS-formatted requirements. These are more comprehensive than the usual unit tests.

In addition, Kiro SDD can generate three markdown files that together define the steering for the agents. Steering gives Kiro persistent knowledge about your workspace and its conventions.

A product overview file (product.md) defines the purpose, target users, key features, and business objectives of your project. A technology stack file (tech.md) specifies your chosen frameworks, libraries, development tools, and technical constraints. And a project structure file (structure.md) documents your file organization, naming conventions, import patterns, and architectural decisions.

With my free plan, Kiro IDE currently supports two Anthropic Claude models, Sonnet 4.5 and Sonnet 4.0, plus five open-weight models. It can automatically select models if you wish. The documentation also lists OpenAI’s GPT-5.6 Sol, Terra, and Luna, Claude Opus 4.5, 4.6, 4.7, 4.8, and 5.0, and Claude Haiku 4.5, all of which can be activated with a Pro ($20/month) or better plan.

Kiro IDE supports over a dozen context providers for chat requests, including generic context such as #codebase and #spec and specific context such as #code (snippets). It supports skills that follow the open Agent Skills standard, and Model Context Protocol servers that follow the MCP standard.

Zed

Over the last few years my colleague Serdar Yegulalp and I have both reviewed Zed favorably, citing both its raw speed (it was written in Rust) and its integration with a flock of language models, mostly using a “bring your own key” paradigm. You need to subscribe if you want to use a Zed-hosted model.

The team behind Zed previously created the hackable text editor, Atom, and the software platform for building JavaScript-based desktop apps, Electron, both for GitHub. They also built Tree-sitter, an advanced syntax parsing framework that has become the standard mechanism for code analysis and syntax highlighting across modern code editors. While Atom has been discontinued, both Electron and Tree-sitter are still active.

It’s Wednesday so there’s a new release of Zed out; the current version (as I write) is v1.13.2. Recent milestones include support for Anthropic’s Claude Opus 5, OpenAI’s GPT-5.6, llama.cpp as a model provider, and automatic agent context compaction. Some older major features include support for skills, collaboration, and remote development. If you’re interested in particular features, read the Zed documentation or the Zed GitHub Repository.

To test Zed’s agentic capabilities, I pointed it at the C++ π calculation program I’ve been using to test agentic development tools, then used Zed’s new code-review skill to evaluate the program. After thoroughly reviewing Zed’s proposed changes, I gave it the go-ahead to implement and test them. I used the recommended model at the time, Claude Sonnet 4.6.

Zenflow

Zenflow is a free platform that coordinates AI agents to build software using spec-driven development (SDD) workflows. Another term for coordination is orchestration, hence Zenflow is also described as an orchestration layer.

Zenflow was developed by the Zencoder team. Thus Zencoder plug-ins work in Zenflow, and features from Zenflow (such as guided workflows) have been added to Zencoder. The CEO of Zencoder, Andrew Filev, told me that his team of experienced engineers had been using Zenflow for their own product development for over a year when I questioned whether it is ready for production code.

The high-level description of the relationship between Zencoder and Zenflow is that Zenflow is the workflow brain and Zencoder executes the work. You may have noticed some naming confusion: Zencoder is not only the name of the company and of its AI plug-in for IDEs, but it is also the name of its in-house coding agent, which is one of four options for Zenflow (the others are Claude Code, Codex, and Gemini) and one of about nine models available to the Zencoder plug-in.

When you start a Zenflow project, you’re offered a choice of standard workflows: Quick Change, Fix Bug, Spec and Build, or Full SDD Workflow, depending on scope. The wider the scope, the more structure you need in the workflow to keep the implementation from drifting away from the requirements. You can also define your own custom workflows, perhaps to conform to your shop’s standards.

Zenflow can run multiple tasks in parallel in isolated environments. The agents coordinate within workflows without corrupting your codebase.

Zenflow also automates verification of its changes. Every workflow runs automated tests and cross-agent code review. Failed tests trigger automatic fixes. Your code ships only after passing all the verification gates.

Zenflow projects are broken down into tasks, and those are divided into subtasks and chats. Each task runs inside its own isolated Git worktree. You can view the status of all tasks in Kanban boards or stacked list views.

Choosing an AI coding environment

Which AI-supported development environment should you choose? As we’ve seen, there are plenty of good options.

GitHub Copilot is one of the most mature AI coding plug-ins for VS Code, and it supports a wide range of AI models.

Google Antigravity 2.0 is a standalone desktop application that is an independent, agent-focused surface. Antigravity IDE is a separate download that looks and feels similar to the original Antigravity. Antigravity CLI is a way to invoke, monitor, and interact with Antigravity agents from your terminal. These tools are among the best ways to take advantage of Gemini models.

JetBrains Air is a relatively new agentic development environment that allows you to provide your own subscriptions or API keys for OpenAI, Anthropic, and Google models.

Kiro IDE supports both vibe-coding and spec-driven development flows. With my free plan, Kiro IDE currently supports two Claude models.

Zed is about the fastest IDE I have used, and it integrates with a flock of language models, mostly using a “bring your own key” paradigm. Its advanced features include collaborative coding and remote development.

Zenflow supports multiple workflows, from quick changes all the way up to full spec-driven development. You can also define custom workflows. Zenflow works with the Zencoder coding agent as well as Claude Code, Codex, and Gemini.

There is no winner: It’s really a matter of which tool fits your use case and makes you happy. If I could have everything I wanted in one tool, I would take the speed and power of Zed, the spec-driven development capabilities of Kiro and Zenflow, and the agentic capabilities of GitHub Copilot, Google Antigravity 2.0, and JetBrains Air.