The biggest news to emerge from the AI world this week was undoubtedly that Elon Musk’s SpaceX had agreed to acquire AI coding startup Cursor in an all-stock deal valued at $60 billion.

But on the very same day, at an invite-only developer conference hosted by Cursor in San Francisco, Tomas Reimers took to the stage to unveil a fledgling project that could prove just as consequential for the developer tools industry.

Origin, as it’s called, is a Git-compatible code-hosting platform designed from the ground up for a world where AI agents — rather than humans — do the bulk of the work.

Reimers, it’s worth noting, is co-founder of Graphite, a code-review startup that Cursor revealed it was acquiring back in December (a deal that apparently closed in January). At the time, some commentators noted the deal’s implications for GitHub — among them was Gergely Orosz.

Orosz, author of The Pragmatic Engineer newsletter and an investor in Graphite, who wrote on LinkedIn: “I’m telling you: GitHub’s biggest competitor could soon be Cursor. Graphite — in my view — is the best AI code review + stacked diffs + PR workflow product out there. GitHub is already playing catch-up to Cursor/Graphite.”

Put simply, Graphite had already built workflow tools that GitHub was scrambling to replicate — and with Cursor’s resources behind it, the gap was only going to widen. And now with the might of SpaceX, a $2.5 trillion company, behind it, things could be about to get very interesting.

The Origin origin story

On stage in San Francisco ahead of Origin’s unveiling, Reimers pointed to Graphite’s customer base — which includes Shopify, Snowflake, Notion, and Figma — as evidence of a problem already well underway before Origin existed.

“When we were acquired by Cursor, we accelerated our most ambitious project — to rebuild that tooling from scratch.”

“Over the past few years, we noticed the trend as these companies adopt AI tooling,” Reimers said. “The tools that they relied on started to become unreliable. That’s because over the past few years, AI tooling has totally changed our industry. It’s enabled every developer to be a 10 to 100x developer, but that change has required fundamentally different tooling. That’s why, when we were acquired by Cursor, we accelerated our most ambitious project — to rebuild that tooling from scratch.”

Amid all the hullaballoo of SpaceX hitting the public markets, becoming one of the world’s most valuable companies overnight, and doling out a cool $60 billion for a four-year-old startup, it’s easy to appreciate why Origin might have slipped under the radar. But the infrastructure problem it’s setting out to solve is real.

It’s easy to appreciate why Origin might have slipped under the radar. But the infrastructure problem it’s setting out to solve is real.

GitHub, the world’s dominant code hosting platform by some distance, is having a rough time of it. As The New Stack reported in June, the platform has logged hundreds of incidents over the past 12 months, struggling to keep pace with the volume of code that AI agents are generating. The company says it’s now processing about 1.4 billion commits per month — up from 1 billion across all of 2025 — with agents alone generating more than 17 million pull requests per month.

The irony isn’t lost on anyone: GitHub helped kickstart the AI coding era with the launch of Copilot in 2021, and it’s now buckling under the weight of it. And for some, the cracks are already showing in their day-to-day habits.

Brian Douglas, GitHub’s former director of developer advocacy who recently launched his own AI infrastructure startup called Paper Compute, tells The New Stack that the shift is already underway.

“Agents are quickly killing the will for doing open source.”

“Agents are quickly killing the will for doing open source,” Douglas says. “I’d love to see what GitHub’s [monthly active user] numbers look like today, because I am sure there are a number of folks choosing to do code reviews elsewhere — or exclusively collaborating with agents to get the work to the last mile — which is at an all-time high.”

Douglas, for what it’s worth, counts himself among them, saying he now does much of his review and PR work directly in AI coding tools.

“As a GitHub power user, I find myself using it less, and relying more on Claude and Codex for review and PR interactions,” he says.

A post-GitHub world?

Origin remains in waitlist-only mode ahead of a planned fall launch, and those present at Compile reported enough detail to sketch its ambitions. Developer advocate and independent commentator Shawn Wang Yuexian, known as swyx, described it as a “long-awaited Git competitor, scalable for agent workloads, extensible with API and MCP, and with built-in merge conflict and CI failure agent resolution.”

Whatever Origin looks like in its launch guise, it’s clear the appetite for an alternative to the status quo is growing. The software development world has changed considerably since GitHub popularized the pull request model back in 2008 — a feature that Douglas calls its “best ever.” But the pull request was designed for a world where humans deliberately wrote and reviewed code, one change at a time. That world is receding fast.

“Right now, the velocity of projects being created is overwhelming GitHub, and engineers are not looking at the code.”

“Right now, the velocity of projects being created is overwhelming GitHub, and engineers are not looking at the code,” Douglas says. “So if the goal is to put it in the cloud so agents are managing the code, I think that is absolutely an opportunity for disruption.”

So, as AI agents push code at a rate no human reviewer can keep up with, the pull request risks becoming a formality — a box to tick rather than a meaningful quality gate. Which raises a deeper question about how the industry should measure the value of software work at all.

For Douglas, the answer lies in a different unit entirely. Commits and lines of code — the traditional proxies for developer output — tell you little in a world where an agent can generate thousands of lines in seconds. Tokens, by contrast, map directly to compute cost and, therefore, to the real effort and value generated. It’s a reframing that suits Cursor rather well.

“Tokens are a better metric than commits.”

“Tokens are a better metric than commits,” Douglas says. “They align to a dollar spent that correlates to the effort of work. Previously, we pretended lines of code were the metric, and that was proven incorrect. But tokens plus agent sessions equals customer value — and Cursor is positioned well to own a deeper part of the collaboration stack.”

Cursor, though, isn’t alone in that conviction, and a slew of tangential efforts to rebuild that infrastructure for the agentic era are emerging.

At its Transcend conference in London on June 10, GitLab announced a private beta of what it calls Next Generation Source Code Management — known internally as Project Switch. Unveiled on stage by GitLab chief product and marketing officer Manav Khurana, the new backend keeps the Git protocol intact but redesigns the underlying architecture entirely, allowing agents to query repositories server-side rather than cloning them in full.

GitLab says it delivers up to 50 times faster task execution per agent, with up to 3 times fewer tokens consumed. And notably, Anthropic is a design partner on the project.

“The most popular Git platforms in the world are buckling under the load, not just because of your teams cloning, branching, and merging code, but also dozens, in some cases hundreds, of agents working simultaneously and putting a lot of pressure on those systems,” Khurana said.

The day after GitLab’s Transcend announcement, Zed co-founder Nathan Sobo published details of DeltaDB, a project the company had first teased the previous fall. A more radical proposition than either Origin or Project Switch, DeltaDB replaces Git’s commit-based model entirely with a continuous stream of fine-grained deltas — every operation an agent performs, linked directly to the conversation that produced it. Sobo confirmed that a beta version is just weeks away.

HashiCorp co-founder Mitchell Hashimoto, meanwhile, has seen this coming. Back in December, he wrote on X: “The AI companies are on track to become GitHub faster than GitHub is becoming an AI company.”

The AI companies are on track to become GitHub faster than GitHub is becoming an AI company. I'm sure there's a lot of sycophants within GH/MS showing off PowerBI dashboards to argue against this for their own personal gain, but wake the fuck up.

— Mitchell Hashimoto (@mitchellh) December 19, 2025

When Origin was announced this week, he retweeted himself with a single line: “Cursor announced Origin today. More will come.”

*taps sign* Cursor announced Origin today. More will come. https://t.co/MwLN0Q7dHX

— Mitchell Hashimoto (@mitchellh) June 16, 2026

Hashimoto, as it happens, is an investor in another agent-native code hosting startup called East River Source Control (ERSC), which is building a Git-compatible platform designed to land thousands of commits per second.

The model is the moat

For Douglas, the convergence of competing efforts to rebuild version control from the ground up isn’t hugely surprising. In the past year, he points out, a similar dynamic played out with developer sandboxes — the environments where code gets written and tested — as companies like Docker, Cloudflare, and Vercel moved into that space because that’s where developers were spending their time.

The same gravitational pull is now acting on version control. The way developers work has changed fundamentally — where once they wrote code directly inside their editors, many now spend their time directing AI agents that do the writing for them. The IDE is no longer primarily a place to type; it’s increasingly a place to watch, review, and steer.

“I think all the folks who are part of the story have a shot, and we need to rethink our infrastructure to prepare for this.”

“Now, IDEs are suffering from the fact that developers have evolved to foundational model harnesses writing code, and they need to position themselves as the tool you open to watch agents write the code,” Douglas says. “I think all the folks who are part of the story have a shot, and we need to rethink our infrastructure to prepare for this.”

Underpinning all of this, though, is a commercial reality. Cursor has been building toward this position for some time, having launched its own first-party coding model, Composer, in 2025 and iterating on Composer 2.5 in May, giving it cheaper, in-house inference rather than relying entirely on costly API calls to Anthropic and OpenAI. Composer 2.5 costs a fraction of Claude Opus at equivalent tasks — as much as a tenfold difference on output tokens. Owning the model, in other words, is what makes owning the rest of the stack viable.

Introducing Composer 2.5, our most powerful model yet.

It's more intelligent, better at sustained work on long-running tasks, and more reliable at following complex instructions.

For the next week, we’re doubling the included usage of the model. pic.twitter.com/N87ojcXlOC

— Cursor (@cursor_ai) May 18, 2026

“It’s clear you can’t just insert an OpenAI key and expect hyper-growth or longevity in this market anymore,” Douglas says. “Instead, you need to own the model to win.”

Whether SpaceX’s firepower accelerates that ambition or complicates it remains to be seen. But the companies placing bets on the next era of software development aren’t waiting for GitHub to catch up.

The post Cursor, GitLab and Zed agree GitHub is breaking. They disagree on how to rebuild it. appeared first on The New Stack.

Inference is now the dominant force in enterprise AI — and with it has come an inconvenient reality: Data is almost always transported to compute. Every inference call moves sensitive enterprise information out of the systems where it lives and into external environments optimized for GPU throughput rather than data governance. This creates friction that compounds at scale: rising costs, expanding security exposure, and a growing tangle of data copies that drift out of sync with operational reality.

What enterprises actually want is different: to keep data and IP intact within the database rather than creating multiple copies and managing the resulting inconsistencies.

Research across more than 2,050 senior executives from major enterprises worldwide suggests that 95% of organizations intend to become their own AI and data platforms within the next 780 working days. Yet only 13% have successfully reached that goal. The organizations that have succeeded are achieving almost five times the return on investment of those still struggling to operationalize AI.

What separates the leaders from the followers is not model quality. It is infrastructure strategy.

The most successful organizations have adopted a sovereign-by-design approach. More than 75% are operating across multiple clouds and on-premises environments rather than relying on a single hyperscale provider. They are building AI around their own business, regulatory, and operational requirements rather than adapting those requirements to fit a cloud vendor’s architecture.

As AI moves from experimentation into production, CIOs are discovering that training models is relatively easy. Running them efficiently, securely and compliantly across thousands of operational workloads is where the real challenge begins.

The shift from training to inference

Training is a discrete event. Inference is an ongoing business process.

A model may be trained once, but it could be called millions of times each day. Every fraud assessment, insurance claim review, customer service interaction, medical recommendation, sanctions check, or predictive maintenance event relies on inference occurring against live operational data.

“What separates the leaders from the followers is not model quality. It is infrastructure strategy.”

This distinction fundamentally changes enterprise infrastructure requirements.

Training workloads prioritize compute density and GPU availability. Inference workloads prioritize latency, governance, reliability and cost control. They must operate where business data resides and where compliance requirements can be enforced.

For heavily regulated industries such as financial services, healthcare, telecommunications, energy and the public sector, inference cannot simply occur in whichever region offers the lowest compute cost. Data sovereignty requirements, audit obligations and security mandates often dictate exactly where workloads must execute.

The challenge therefore becomes much larger than AI itself. Organizations need an operating model capable of bringing together compute, data and governance without sacrificing flexibility.

Why neoclouds are emerging as a critical layer to cross the chasm to production

This is where neoclouds have become increasingly important.

Unlike traditional hyperscalers, neoclouds are purpose-built around AI infrastructure. Their focus is not delivering hundreds of generic cloud services but rather optimizing for GPU access, AI performance, and flexible consumption models.

For many enterprises, neoclouds offer a compelling answer to the growing demand for specialized AI compute. They provide access to the latest accelerator technologies while enabling organizations to scale workloads without the complexity often associated with large cloud environments.

“The future of AI architecture therefore depends on bringing models closer to data rather than moving data closer to models.”

However, neoclouds solve only one part of the enterprise AI equation.

AI does not create value in isolation. Models require context. They need access to customer records, transaction histories, operational workflows, policy documents, supply chain information and enterprise knowledge. Moving these assets into separate AI environments creates duplication, latency and governance challenges.

The future of AI architecture therefore depends on bringing models closer to data rather than moving data closer to models.

Why Postgres has become the enterprise AI foundation

As organizations look for a common platform that supports both operational and AI workloads, Postgres has emerged as a natural foundation.

Postgres already serves as the operational backbone for many of the world’s most important applications. It combines transactional reliability, extensibility, and scalability with the openness that enterprises increasingly demand. 70%+ of AI-related application development is happening on Postgres.  

What makes Postgres particularly relevant in the AI era is its ability to become more than a database. It can serve as a governed memory layer for AI systems, integrating operational data, application context, permissions, observability, and retrieval capabilities into a single architecture.

This dramatically reduces complexity.

Instead of maintaining separate infrastructures for transactional systems, vector stores, AI memory layers, and governance frameworks, organizations can consolidate around a trusted operational platform that already supports their mission-critical workloads.

For CIOs seeking to balance innovation with control, this architectural simplification represents a significant strategic advantage.

Why sovereignty matters more than ever

Sovereignty has become one of the defining themes of enterprise technology.

For banks, sovereignty means maintaining control over financial data and regulatory obligations. For healthcare organizations, it means protecting patient information while enabling innovation. For governments, it means ensuring national and citizen data remains under appropriate jurisdictional control.

The rise of AI has amplified these concerns.

Organizations increasingly need assurance that models, data, policies and operational controls can remain within designated environments while still benefiting from advances in AI technology.

This requirement is driving demand for sovereign AI architectures capable of operating across clouds, private infrastructure and on-premises environments.

The challenge is creating consistency across these environments without introducing operational complexity.

EDB Postgres AI: connecting sovereign data and sovereign AI

EDB Postgres AI addresses this challenge by bringing together operational Postgres, AI capabilities and hybrid infrastructure management into a unified platform.

Rather than forcing enterprises to choose between innovation and control, EDB Postgres AI enables organizations to deploy AI where their data already resides. Through capabilities spanning operational databases, analytics, agentic AI workloads and hybrid management, organizations can create a consistent operating model across sovereign environments.

This approach is particularly relevant for regulated industries where moving sensitive information into external AI services may introduce compliance, security or governance concerns.

By enabling inference close to operational data, organizations reduce data movement, improve performance, and strengthen their compliance posture. At the same time, they maintain the flexibility required to leverage emerging AI technologies and modern infrastructure models.

“By enabling inference close to operational data, organizations reduce data movement, improve performance, and strengthen their compliance posture.”

The result is a platform that aligns with the realities of enterprise AI rather than the assumptions of consumer AI.

“The reality is that the new AI at scale world needs a new infrastructure. That isn’t just the compute; it’s the governance, heuristic data access and level of observational and orchestration control that are absolute, governed, agile and work for humans and agents.”  Nancy Hensley, CPO, EDB

The new enterprise AI stack

The emerging enterprise AI architecture is increasingly built around complementary rather than competing technologies.

Infrastructure layer	Primary role	Strategic value
Neoclouds	Specialized AI compute and GPU infrastructure	Access to cutting-edge AI acceleration and flexible scaling
Public Hyperscalers	Broad cloud services and global reach	Ecosystem breadth and service diversity
Postgres	Operational data foundation	Trusted, governed and scalable enterprise data platform
EDB Postgres AI	Sovereign AI and hybrid management layer	Enables AI, analytics and operational workloads to run consistently across sovereign environments
Enterprise Governance	Security, compliance and policy controls	Ensures AI aligns with regulatory and business requirements

Together, these layers create an architecture capable of supporting the complete AI lifecycle—from experimentation and model training through production inference and continuous optimization.

The CIO imperative

The organizations realizing the greatest value from AI are no longer asking how to train better models. They are asking how to operationalize AI across the enterprise while maintaining control over cost, governance, and risk.

Their answer is increasingly consistent.

They are adopting multi-cloud and hybrid strategies rather than relying on a single cloud. They are prioritizing sovereign architectures rather than centralized data movement. They are building around open operational foundations rather than proprietary lock-in. Most importantly, they are recognizing that AI success depends on bringing intelligence to data, not data to intelligence.

Neoclouds provide the compute layer required for modern AI. Postgres provides the operational foundation required for trusted enterprise systems. EDB Postgres AI connects these worlds through a sovereign architecture designed for the realities of regulated industries.

As AI transitions from experimentation to operational necessity, the winning enterprises will be those that can make inference secure, governed, low-latency, and economically sustainable at scale.

In the next era of enterprise AI, the greatest business value will not come from model selection or raw GPU access. It will come from infrastructure strategy built around data — keeping intelligence close to where data already lives, governed, trusted, and ready to act.

The post Neoclouds, sovereign AI and Postgres: The new operating model for regulated enterprises appeared first on The New Stack.

For most of its 30-year history, Postgres has been viewed as a transactional database. Organizations trust it with customer records, financial transactions, and countless other operational workloads. Its reputation was built on reliability, strong transactional guarantees, and a vibrant open-source community that has spent decades refining the database without compromising its foundations.

However, some of the most important innovations in the Postgres ecosystem today have little to do with storing data. They have to do with reducing the need to move it around.

“Some of the most important innovations in the Postgres ecosystem today have little to do with storing data. They have to do with reducing the need to move it around.”

Database innovation has historically focused on performance, scalability, and reliability. Increasingly, the harder problem is interoperability: how operational data can be shared across analytical systems, AI applications, and downstream services without creating yet another pipeline or copy.

Why Postgres keeps showing up

The reality of modern software architecture is that data rarely stays in one place. Information created in operational systems quickly finds its way into warehouses, search platforms, machine learning environments, and AI applications. Every new system solves a legitimate business problem, but it also creates another destination for data and often another copy to maintain.

The costs of this approach extend beyond infrastructure spending alone. Every additional copy introduces latency, creates another potential source of inconsistency, and increases the operational burden of keeping systems synchronized. Many organizations now spend as much effort moving data as they do storing it.

“Many organizations now spend as much effort moving data as they do storing it.”

For many businesses, Postgres serves as the system of record for customer interactions, transactions, application state, and other business-critical information. As organizations expand their analytical, machine learning, and AI capabilities, they are not looking to create another source of truth; rather, they’re looking for better ways to work with the one they already trust.

That shift is changing how Postgres fits into modern architecture. Historically, Postgres was viewed primarily as the place where operational data originated before being copied into downstream systems. Increasingly, organizations want those systems to work more seamlessly with operational data while reducing the pipelines, copies, and synchronization processes required to support them.

Technologies such as logical replication, change data capture, and foreign data wrappers have helped Postgres participate more directly in larger data ecosystems. As a result, organizations are no longer asking only whether Postgres can store their data. They’re instead asking how easily it can connect to everything around it.

That shift, from evaluating databases primarily on storage and performance to evaluating them on interoperability, may be one of the most important changes happening in the Postgres ecosystem today.

AI is exposing old problems

The recent focus on AI has brought renewed attention to data movement. AI didn’t create the problem. If anything, it exposed a limitation that has been quietly growing for years. For decades, organizations built architectures around the idea that data would move between systems through pipelines and periodic synchronization. That model worked because most analytical workloads could tolerate some degree of delay.

AI is changing those expectations. Many AI applications depend on access to current operational context. The challenge is not that organizations lack data. In many cases, they already have it. The challenge is that the data is spread across multiple systems, each with its own copy, latency profile, and synchronization process.

“AI is forcing organizations to confront a broader question: How many copies of the same data are actually necessary? The answer increasingly appears to be fewer than most architectures maintain today.”

As a result, AI is forcing organizations to confront a broader question: How many copies of the same data are actually necessary? The answer increasingly appears to be fewer than most architectures maintain today. As expectations around freshness rise, reducing unnecessary data movement becomes just as important as accelerating it. The underlying challenge is not new. AI has simply made it harder to ignore.

What’s next

The database industry spent decades solving storage. Databases became more reliable, storage became cheaper, and infrastructure became dramatically easier to operate. The next challenge is not where data lives, but how easily it can be shared across systems without introducing additional pipelines, copies, and synchronization overhead. Increasingly, the goal is not simply moving data faster. It is reducing unnecessary movement altogether.

Postgres has a habit of outlasting predictions about its replacement. For years, members of the community have joked that every year is “the year of Postgres.” The joke works because it keeps turning out to be true. 

Three decades after its creation, Postgres continues to adapt to new workloads, new architectural patterns, and new ways of building applications.

That longevity is not an accident. Enterprises continue to rely on Postgres because it provides a stable and trusted foundation for operational data.  While that foundation is unlikely to change, the scope of what organizations expect Postgres to do will continue to expand.  

As new workloads continue to emerge, much of the innovation will come through extensions that expand Postgres’s capabilities without sacrificing the stability that made it successful. In that sense, the future of Postgres may not be about reinventing the database itself, but continuously expanding what can be built on top of it.

The post The database storage problem is solved. Here’s what comes next. appeared first on The New Stack.