In user-facing distributed systems, latency is often a stronger signal of failure than errors. When responses exceed user expectations, the distinction between “slow” and “down” becomes largely irrelevant, even if every service is technically healthy.

I’ve seen this pattern across multiple systems. One incident, in particular, forced me to confront how much production behavior is shaped by defaults we never explicitly choose. What stood out was not the slowness itself, but how “infinite by default” waiting quietly drained capacity long before anything crossed a traditional failure threshold.

Details are generalized to avoid sharing proprietary information.

When slowness turned into an outage

The incident started with support tickets, not alarms. Early in the morning, they began to appear:

• Product pages don’t load.
• Checkout is stuck.
• The site is slow today.

At the same time, our dashboards drifted in subtle ways. CPU climbed, memory pressure increased and thread pools filled while error rates stayed low. Product pages began hanging intermittently: some requests completed, others stalled long enough that users refreshed, opened new tabs and eventually left.

I was on call that week. There had been a recent deployment, so I rolled it back early. It had no effect, which told us the issue wasn’t a specific change, but how the system behaved under sustained slowness.

Within a few hours, the impact was measurable. Product page abandonment increased sharply. Conversion dropped by double digits. Support ticket volume spiked. Users started switching to competitors. By the end of the day, the incident resulted in a six-figure loss and, more importantly, a visible loss of user trust.

The harder question wasn’t what failed, but why user impact appeared before our pages fired. The system crossed the user’s pain threshold long before it crossed any paging threshold. Our alerts were optimized for hard failures – errors, instance health, explicit saturation – while latency lived on dashboards rather than in paging.

The failure mode we missed

Product pages displayed prices in the user’s local currency. To do that, the Product Service called a downstream currency exchange API. That dependency did not go down. It became slow, intermittently, for long enough to trigger a cascade.

As I dug deeper during the incident, one detail stood out. The Product Service used an HTTP client with default configuration, where the request timeout was effectively infinite. On the frontend, browsers stopped waiting after roughly 30 seconds. On the backend, requests continued to wait long after the user had already given up.

Violetta Pidvolotska

That gap mattered more than I expected. The first few hung currency calls held onto Product Service worker threads and outbound connections, so new requests began queuing behind work that no longer had a user on the other end. Once the shared pools started to saturate, it stopped being “only the currency path.” Even requests that didn’t require currency conversion slowed down because they waited for the same thread pool and the same internal capacity.

At that point, the dependency didn’t need to fail to take the service down. It only needed to become slow while we kept waiting without a boundary. This wasn’t an error failure. It was a capacity failure. Blocked concurrency accumulated faster than it could drain, latency propagated outward and throughput collapsed without a single exception being thrown.

Some mitigations helped only temporarily. Restarting instances or shedding traffic reduced pressure for a short time, but the relief never lasted. As long as requests were allowed to wait indefinitely, the system kept accumulating work faster than it could complete it.

When we finally pinpointed the unbounded wait, the immediate fix sounded simple: set a timeout. The real lesson was deeper.

Defaults that quietly shape system behavior

At first glance, this looked like a simple misconfiguration. In reality, it reflected how common default settings influence system behavior in production.

Many widely used libraries and systems default to infinite or extremely large timeouts. In Java, common HTTP clients treat a timeout of zero as “wait indefinitely” unless explicitly configured. In Python, requests will wait indefinitely unless a timeout is set explicitly. The Fetch API does not define a built-in timeout at all.

These defaults aren’t careless. They’re intentionally generic. Libraries optimize for the correctness of a single request because they can’t know what “too slow” means for your system. Survivability under partial failure is left to the application.

Production systems rarely fail under ideal conditions. They fail under load, partial outages, retries and real user behavior. In those conditions, unbounded waiting becomes dangerous. Defaults that feel harmless during development quietly make architectural decisions in production.

When we later audited our services as a team, we found that many calls either had no timeouts or had values that no longer matched real production latency. The defaults had been shaping system behavior for years, without us explicitly choosing them.

The mental model behind long timeouts

What this incident revealed wasn’t just a missing timeout. It exposed a mental model many teams rely on, including ours at the time.

That model assumes:

1. Dependencies are usually fast
2. Slowness is rare
3. Defaults are reasonable
4. Waiting longer increases the chance of success

It prioritizes individual request success, often at the cost of overall system reliability. As a result, teams often don’t know their effective timeouts, different services use inconsistent values and some calls have no timeouts at all.

Violetta Pidvolotska

Even when timeouts exist, they are often far longer than what user behavior justifies. In our case, users retried within a few seconds and abandoned within about ten. Waiting beyond that didn’t improve outcomes. It only consumed capacity.

Long timeouts can also mask deeper design problems. If a request regularly times out because it returns thousands of items, the issue isn’t the timeout itself. It’s missing pagination or poor request shaping. By optimizing for individual request success, teams unintentionally trade away system-level resilience.

Timeouts as failure boundaries

Before this incident, we mostly treated timeouts as configuration knobs. After that, we started treating them as failure boundaries.

A timeout defines where a failure is allowed to stop. Without timeouts, a single slow dependency can quietly consume threads, connections and memory across the system. With well-chosen timeouts, slowness stays contained instead of spreading into a system-wide failure.

We made a set of deliberate changes:

1. Enforced timeouts on the client side

The caller decides when to stop waiting. Load balancers, proxies or servers could not reliably protect us from hanging forever, as the incident made clear.

2. Introduced explicit end-to-end deadlines for user-facing flows

Downstream calls could only use the remaining time budget; waiting beyond that point was wasted work with no chance of improving the outcome.

Violetta Pidvolotska

We made those deadlines explicit and portable. In HTTP flows, we propagated an end-to-end deadline via a single X-Request-Deadline header so each service could compute the remaining time and set per-call timeouts accordingly. We chose a deadline (not a per-hop timeout) because it composes cleanly across service boundaries and retries.

For gRPC paths, built-in deadlines allowed remaining time to propagate across service boundaries. We extended that same boundary through internal request context so background work stopped when the budget did.

3. Became deliberate about how timeout values were chosen

Connection timeouts were kept short and tied to network behavior. Request timeouts were based on real production latency, not intuition.

Rather than relying on averages, we focused on p99 and p99.9. When p50 was close to p99, we left room so minor slowdowns didn’t amplify into timeout spikes. This helped us understand how slow requests behaved under load and choose timeouts that protected capacity without causing unnecessary failures.

For example, if 99% of requests completed in 300 milliseconds, a timeout of 350-400 milliseconds provided a better balance than tens of seconds. What happened beyond that point became a conscious product decision. In our case, when currency conversion timed out, we fell back to showing prices in the primary currency. Users consistently preferred an imperfect answer over waiting indefinitely.

We also kept retries conservative in user-facing paths. A retry that doesn’t respect an end-to-end deadline is worse than no retry: it multiplies work after the user has already moved on. That’s how “helpful” retries turn into retry storms under partial slowness.

As a team, we codified these decisions into shared client defaults and a mandatory review checklist used across new and existing call paths so unbounded waiting didn’t quietly return.

Keeping timeouts honest

Timeouts should never be silent. After the incident, we focused on three things:

1. Making timeouts observable

Every timeout emitted a structured log entry with dependency context and remaining time budget. We tracked timeout rates as metrics and alerted on sustained increases rather than individual spikes. Rising timeout rates became an early warning signal instead of a surprise during incidents. Importantly, we updated paging to include user-impacting latency and “requests not finishing” signals, not just error rate.

2. Stopping the treatment of timeout values as constants

Traffic grows, dependencies change and architectures evolve, so values that were reasonable a year ago are often wrong today. We reviewed timeout configuration whenever traffic patterns shifted, new dependencies were introduced or latency distributions changed.

3. Validating timeout behavior before real incidents forced the issue

Introducing artificial latency in non-production environments quickly exposed hanging calls, retry amplification and missing fallbacks. It also forced us to separate two different questions: what breaks under load and what breaks under slowness.

Traditional load tests answered the first. Fault-injection and latency experiments revealed the second, a form of controlled failure often described as chaos engineering. By introducing controlled delay and occasional hangs, we verified that deadlines actually stopped work, queues didn’t grow without bound and fallbacks behaved as intended.

Lessons that carried forward

This incident permanently changed how I think about timeouts.

A timeout is a decision about value. Past a certain point, waiting longer does not improve user experience. It increases the amount of wasted work a system performs after the user has already left.

A timeout is also a decision about containment. Without bounded waits, partial failures turn into system-wide failures through resource exhaustion: blocked threads, saturated pools, growing queues and cascading latency.

If there is one takeaway from this story, it is this: define timeouts deliberately and tie them to budgets. Start from user behavior. Measure latency at p99, not just averages. Make timeouts observable and decide explicitly what happens when they fire. Isolate capacity so that a single slow dependency cannot drain the system.

Unbounded waiting is not neutral. It has a real reliability cost. If you do not bound waiting deliberately, it will eventually bound your system for you.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Sovereignty, locality, and “alternative cloud” strategies are often treated as simple settings in hyperscaler consoles. Pick a region, check a compliance box, and move on. IT consultancy Coinerella posted about replacing a typical US-centric startup baseline with a “Made in the EU” stack. They treat sovereignty as an architectural posture and an operating model that can save money. It still involves friction, compromise, and more responsibility than outsourcing to default ecosystems.

The Coinerella approach is to deliberately refuse to let the platform drift toward AWS and US-based hyperscalers, driven by practical considerations such as data residency, General Data Protection Regulation (GDPR) compliance, reducing concentration risk, and demonstrating the operational viability of European infrastructure. Leaders often talk about sovereignty until the first production incident, the first compliance review, or the first integration gap. Coinerella remains committed and is addressing the consequences.

A ‘made in the EU’ stack

Coinerella didn’t pursue sovereignty by inventing new patterns. They recreated a fairly standard modern platform using European providers and selectively self-hosted services. For core infrastructure, they moved primary compute and foundational services to Hetzner, including virtual machines, load balancing, and S3-compatible object storage. This is where the story gets interesting: The hyperscaler narrative suggests that leaving AWS is mostly about giving up features. Coinerella found something different, at least for the basics. Compared with what many teams experience on AWS, their new performance and capability were solid, and the cost profile was compelling.

When Hetzner didn’t provide a managed service they needed, they filled in the gaps with Scaleway. That included transactional email, a container registry, additional object storage, observability tools, and even domain registration. In many migrations, stitching together multiple providers is where complexity balloons; here, the company intentionally used that approach, choosing the best option available in the region rather than forcing a single vendor to do everything.

At the edge, they relied on Bunny.net for the content delivery network and related capabilities, including storage, DNS, image optimization, web application firewall, and DDoS protection. That choice is a reminder that edge services are not just an add-on; they are a major part of the platform’s reliability and security posture. Their blog suggests the experience felt approachable, coming from the more common Cloudflare-centric world, which is exactly what you want when you’re reducing risk in a migration.

Coinerella also addressed AI inference in a sovereignty-aware way by using European GPU capacity via Nebius rather than defaulting to US regions for inference calls. For identity, they used Hanko, a European authentication provider that supports modern authentication approaches like passkeys and handles common log-in expectations such as social log-ins.

Finally, and importantly, they self-hosted a meaningful set of internal services on Kubernetes, using Rancher as the management layer. They ran Gitea for source control, Plausible for analytics, Twenty for CRM, Infisical for secrets management, and Bugsink for error tracking. If you’ve ever advised an enterprise to self-host “just a few things,” you know what this really means: You’re accepting a different operational contract, where savings and control come with life-cycle ownership.

Surprises and extra hurdles

Coinerella’s post is most valuable where they write about difficulties in the “boring” services that often make or break developer productivity. Email was one of the major friction points. In the US ecosystem, transactional email options are plentiful, polished, and easy to integrate, with a deep bench of community guidance for deliverability and troubleshooting. Coinerella made it work with a European alternative, but the takeaway is clear: The long tail of integrations, templates, and community answers isn’t evenly distributed across regions. It’s not that the service can’t function; it’s that you may have to serve as your own integration team more often.

Source control was another challenge. Moving away from GitHub isn’t just about moving away from a Git remote; it’s about leaving an ecosystem: CI/CD defaults, actions, marketplace integrations, and the operational muscle memory of every developer who has internalized the GitHub way of doing things. Gitea can be a solid foundation, but it doesn’t automatically bring the full assembly line you get “for free” on the dominant platform.

There were also cost anomalies. The author notes that some top-level domains appeared to be significantly more expensive through European registrars—sometimes dramatically so—without a satisfactory explanation why. That’s not an architectural deal-breaker, but it’s exactly the kind of real-world detail that proves a point: These journeys aren’t clean-room exercises. You’ll encounter unexpected differences in market structure, and you’ll have to decide how much they matter.

Unavoidable dependencies

If you’re looking for a purity narrative that claims “we removed every US dependency,” this isn’t it. Coinerella acknowledged that some dependencies are structural. User acquisition may require Google’s advertising ecosystem, and mobile distribution routes may have to go through Apple’s developer program. Social log-ins often rely on Google and Apple infrastructure, and removing them can harm conversion rates. Even AI introduces pressure: If you want access to specific frontier models, you may be forced to use US-based APIs.

The smarter posture this blog implicitly recommends is to minimize what you can, isolate what you can’t, and be honest about the trade-offs. Sovereignty isn’t binary. It’s a spectrum of choices about where your core data and operational dependencies reside.

Moving to an alt cloud

Coinerella’s experience mirrors what many enterprises are learning as they move toward alt clouds, including sovereign clouds, private clouds, and other non-default platforms. The biggest lesson is that the economics of the move can be attractive precisely because you’re taking on more work. Lower infrastructure costs are real, but they come with increased integration responsibility, more platform engineering, and a higher need for operational maturity.

This is also where the “want versus need” conversation becomes unavoidable. Hyperscalers have trained teams to select managed services the way you pick items off a menu, often because it’s convenient, fast, and politically easy. Alt cloud strategies force prioritization. You may want the newest managed feature set, the deepest marketplace, and the broadest ecosystem, but you may not need them to meet your business outcomes. When you choose sovereignty or a private-cloud footing, you often end up selecting simpler technologies that meet requirements, even if they’re less glamorous or less feature-rich. This is not a retreat. It’s a form of architectural discipline.

However, none of this works without adding new practices. Finops becomes an engineering discipline that spans heterogeneous providers, self-hosted platforms, and capacity planning decisions you can no longer punt to a hyperscaler. Observability becomes a first-class design requirement because you’re building a platform that crosses boundaries and includes components you own end to end. You need consistent metrics, logs, traces, service-level objectives, and incident response procedures that work even when tools and APIs differ across providers. Because you’re doing more of the work, you need to be more explicit about patching, security, backups, recovery testing, and operational runbooks.

The point isn’t that this is too hard to do. The point is that it’s hard in predictable ways. Coinerella’s blog makes the case that the journey is worth the trouble, but it’s not easy—and that’s the framing enterprise leaders need. If you expect sovereignty to be a product feature, you’ll be disappointed. If you treat it as a strategic posture that comes with real engineering commitments, you can get the control, cost profile, and locality benefits you’re looking for without being surprised by the work required.

Google’s planned Android developer verification program, requiring Android apps to be registered by verified developers, is getting pushback, with opponents urging developers not to sign up for the program and to make their opposition known.

An open letter opposing the verification program was posted February 24 at Keep Android Open, a consortium that is fighting the Google verification program. Among the 41 signatories as of February 26 are the Electronic Frontier Foundation, the Free Software Foundation, the Center for Digital Progress, and the Software Freedom Conservancy. “Android, currently an open platform where anyone can develop and distribute applications freely, is to become a locked-down platform, requiring that developers everywhere register centrally with Google in order to be able to distribute their software,” said Marc Prud’hommeaux of the F-Droid Android development community in a blog post.

Google could not be reached for comment on February 26. The program was announced August 25, 2026. Starting in September, Android will require all apps to be registered by verified developers before they can be installed on certified Android devices. “To better protect users from repeat bad actors spreading malware and scams, we’re adding another layer of security to make installing apps safer for everyone: developer verification,” said Suzanne Frey, Google’s VP, Product, Trust and Growth for Android, in the blog post announcing the program. “This creates crucial accountability, making it much harder for malicious actors to quickly distribute another harmful app after we take the first one down” she said.

Keep Android Open disagrees. In the open letter, the organization calls upon Google to:

1. Immediately rescind the mandatory developer registration requirement for third-party distribution.
2. Engage in transparent dialogue with civil society, developers, and regulators about Android security improvements that respect openness and competition.
3. Commit to platform neutrality by ensuring that Android remains a genuinely open platform where Google’s role as platform provider does not conflict with its commercial interests.

Keep Android Open wants developers to resist by refusing to sign up for early access, refusing to perform early verification, and refusing to accept an invitation to the Android Developer Console. Instead, the group advises, developers should respond to the invitation with a list of concerns and objections. It encourages consumers to contact national regulators and express concerns.

Lightrun has announced Lightrun AI SRE, an AI-powered site reliability engineering (SRE) assistant designed to detect software production errors and performance degradations.

Introduced February 25, the Lightrun AI SRE correlates the service-level issues it finds with proven root causes to propose solutions. Drawing on on live, in-line runtime context, the AI SRE allows AI agents and engineering teams to create missing evidence dynamically, prove root causes with live execution data, and validate fixes directly in live environments, Lightrun said.

The company cited the folllowing key capabilities and benefits of AI SRE:

• Performs root cause analysis based on new evidence from live environments, without needing prior instrumentation.
• Suggests runtime-validated code changes to eliminate guesswork and reduce rollback-and-redeploy cycles.
• Performs live issue debugging in safe remote sessions with execution-level behavior inspections.
• Provides dynamic telemetry to running systems to fill visibility gaps that traditional, observability tools cannot address.
• Reduces reliance on expensive war rooms, due to autonomous remediation and the ability to receive a code fix of incidents before escalating to a human.
• Provides resilience to “unknown unknowns” introduced by multiple AI agents across the SDLC.

The Lightrun AI SRE safely interacts with live systems via Lightrun’s Sandbox to create new evidence, test hypotheses, and validate outcomes against real execution behavior, Lightrun said. This capability transforms AI SRE from a reactive, post-incident advisor into a trusted, runtime-verified autonomous engineer that ensures reliability by design, according to the company.

Once upon a time, we had mainframes with simple, nonprogrammable consoles. All the power was centralized. Then, Gates and Jobs put a personal computer on every desk. The power was distributed. Then, the internet came along, and the browser became the most popular application in the world. The power moved back onto the server, the cloud became king. Now, that pendulum is swinging back.

This article is a first look at the local-first movement, and the new technologies embedding feature-rich data storage options directly into web browsers.

PGLite: The database in your browser

The modern browser is a beast, the result of years of intensive development and real-world testing. Today’s browser typically runs on a very capable machine. Yet, like a pauper, it must ask the server every time it wants some data. Browser state is just a temporary shadow, eradicated every time the screen refreshes. The loading spinner, the UI waterfall, the click-and-wait; these are all effects of our ongoing dependency on the back end for persistent state.

But an alternative is emerging. The idea is to embed a relational database directly in the browser, with a slice of the data, and let a synchronization (sync) engine keep everything consistent. The browser interacts with a local datastore that is synced to the server in the background. This means instant interactivity on the front end while maintaining symmetry with the back end. This next-generation browser has a more resilient state-of-record, not just a temporary cache.

Several factors have emerged to make the browser a more robust datastore, including IndexedDB and WebAssembly, paving the way for tools like the in-browser NoSQL datastore, PouchDB. But probably the star of the show these days is the PGLite SQL database.

Of course, everything comes with tradeoffs. There are architectural implications to moving the database into the browser. But the most significant change is the gradual distancing from two of the bedrocks of web development: JSON and REST.

The isomorphic future

I recently wrote about how WinterTC moves us toward the dream of isomorphic JavaScript, where the server and client are exactly the same. The next stage is achieving similar homogeneity across datastores. That has only recently become possible with the maturation of WASM, which runs a fully-featured PostgresSQL instance in the browser. That instance, the WASM database, is PGLite.

Although SQLite can get you close to an enterprise database in the browser, PGLite is literally the same database you would run in the data center. It eliminates the friction of dialect. The WASM runtime (really a wonder of the modern programming world) makes PGLite a lightweight build of the actual Postgres codebase.

All of this means we are nearer than ever to a thick client. Of course, there are nuances to be considered, and there will be twists and turns along the path.

Shape-based syncing

Even if the API and implementation are the same, we can’t just create a shard of the entire database in the browser. It’s too big, and it would be insecure anyway. We only want the data the specific user needs for a given session.

An influential idea is “shape-based” syncing. This was popularized by ElectricSQL, which is also the force behind PGLite. A shape is something like a view. It takes one or more queries and uses them to populate the client-side database with a segment of the relevant data. Only the server holds the full truth. The client subscribes to a specific shape within the server (e.g., SELECT * FROM issues WHERE assigned_to = 'me').

Under the hood, syncing relies on Postgres’s native Logical Replication protocol. The sync engine is a middleware consumer. It listens to the database’s write-ahead log (the real-time stream of all changes happening on the server). When a change occurs that matches a client’s subscribed shape, the engine pushes that specific update down the background WebSocket to the browser’s PGLite instance. This activity is bidirectional. Local writes are applied instantly to the UI, then queued and streamed back upstream to the central database, while the engine handles the necessary conflict-resolution logic.

In the old days of progressive web apps (PWAs), you had to write imperative code to replay failed requests when the user came back online. The technique worked but it was brittle, and not a great developer experience. Modern sync engines offer a more elegant solution by doing the work themselves.

At this point, you might be thinking: “But the browser is ephemeral! Users clear their cache!”

The sync engine address this natural objection. To understand how, think about the architecture of Git:

• The remote database (GitHub) is the source of truth.
• The local database (your laptop) contains the working data.

If a user clears their browser cache, they haven’t lost their data. They’ve simply deleted their local repository. When they log in again, the sync engine essentially performs a git clone, pulling their “shape of data” back down to the device.

Conflict-free replicated data types

But what happens if two users edit the exact same data while offline? In a standard database, the last write would overwrite the previous one. The syncing logic needs to be very sophisticated indeed, to handle a multitude of clients operating on shapes and continually dumping their syncs to the central datastore.

This is where CRDTs (conflict-free replicated data types) come in.

CRDTs are an esoteric sounding set of mathematical constructs with practical applications for the syncing problem. These data structures (like a Map or a List) are designed to be merged mathematically. It’s the difference between a Git merge conflict (which stops work and requires human intervention) and Google Docs (which merges everyone’s typing automatically). By using CRDT logic, sync engines ensure users’ offline edits are never lost; instead, they are seamlessly combined when the connection is restored.

Now, let me preempt what you might be thinking next: This is a lot of additional architecture. I mean, now we have two databases, a syncing engine, and that “shape” appears to be a duplication of a SELECT statement that should live on the server.

We have in a sense taken distributed computing, a classic hard problem, and split it at the datastore. We are doing this to avoid the clunkiness of loading data, but at the expense of a known pattern: The JSON API (and REST).

If we are willing to do all this, we must be hoping to gain something of great value from it, right?

Outgrowing the JSON API

This new approach makes something possible that web developers have been chasing for 20 years: the desktop-class experience.

By interacting with local data, a responsiveness is attainable on the UI that is simply out of reach when relying on direct network calls. Pulling in a full-blown PostgreSQL instance is a thoroughgoing solution that avoids half-measures like local caches. On top of that, it produces another interesting potential win in developer experience.

By eliminating the back-end API, we toss out a whole layer of coupling that web developers have traditionally had to deal with. The goal is to somehow avoid manually translating client-side data into a transport format, then back into a datastore format, and then back again. (Frameworks like HTMX are also working toward this ideal, although they approach it differently.)

In the ideal of local-first data, we don’t have to do any of that marshaling of JSON. We just write the SQL statement that we want, and the sync engine automatically handles the transport (based on the rules we’ve defined). We no longer write a GET /todos endpoint. Instead, we write an SQL query in our component: SELECT * FROM todos.

IndexedDB and OPFS

While PGLite is fascinating technology, it isn’t the only story on the local-first data front. It’s actually part of a larger constellation of technologies. After all, developers have always found places to stash data: namely, localStorage, cookies, and IndexedDB.

IndexedDB is a real attempt to give the browser a database (and indeed, it can be used as a quick way to back a PGLite instance) but it’s hamstrung by a notoriously clunky API and performance limitations. It is more like a file system bucket than a database engine. It offers no support for complex queries, joins, or constraints. To do anything interesting, you have to write the database logic yourself in JavaScript, pulling data into memory to filter it, which destroys performance. All of which is to say, it’s messy for real-world use cases.

IndexedDB was a necessary stepping-stone, but it’s not a final destination. The foundation of the modern era was built by WebAssembly and the Origin Private File System (OPFS). These are the technologies that let us stop re-inventing databases in JavaScript and start porting proven engines directly into the client.

The high-speed file system: OPFS

While it sounds like an obscure browser spec, OPFS is important to modern local-first architecture. Where WASM provides the runtime, OPFS provides the file system.

OPFS finally gives the browser direct, high-performance access to the user’s hard drive. Unlike IndexedDB, which forces us to read/write entire files or objects, OPFS allows for random-access writes. This means a database like PGLite can modify a tiny 4KB page of data in the middle of a 1GB file without rewriting the entire thing. This is the missing link that allows server-grade databases to run in the browser with near-native performance.

The NoSQL alternative: RxDB

If PGLite is the champion of the “SQL on the client” movement, RxDB (Reactive Database) is the NoSQL equivalent. It inherits from PouchDB, an in-browser NoSQL database that has been in real-world use for many years.

While PGLite focuses on bringing the structure of the server to the client, RxDB focuses on the behavior of the modern UI. It is designed around reactivity (hence the Rx prefix). In a standard database, you run a query and get a result. In RxDB, you subscribe to a query:

// In RxDB, the database IS the state manager
db.todos.find().$.subscribe(todos => {
  render(todos);
});

When the sync engine pushes new data from the server, your UI updates instantly. You don’t need a state management library like Redux or Pinia because the database itself is the source of reactive truth.

Conclusion

The browser is no longer just a document viewer or simple terminal interface. But the emerging local-first architecture is a radical departure from our familiar REST and REST-like solutions. It brings its own complexities.

With the unification of the runtime (WinterTC) and the arrival of industrial-grade local databases (PGlite and RxDB), the browser could potentially be a full-bore application platform. But will it supplant the known way of doing things? Not all at once, and not quickly. Familiarity is a huge ballast in the programming world.

Local-first + syncing could someday knock the crown off JSON and REST. But first, it will have to prove its viability in the real world.

Available as a part of .NET 10, which was released last November, C# 14 brings a plethora of new features and enhancements that make it easier to write efficient, high performant code. Just as we walked through the new features and enhancements in C# 13 and C# 12, in this article we’ll take a close look at some of the best new features in C# 14.

To work with the code examples provided in this article, you should have Visual Studio 2026 or a later version installed in your system. If you don’t already have a copy, you can download Visual Studio 2026 here.

File-based apps

Support for file-based apps is perhaps the most striking new feature in this release of the C# programming language. Until C# 14, we’ve had to follow a multi-step process to run a minimal .cs file. Not only was this a multi-step process, but it incurred significant additional overhead because you had to create a solution file and a project file to run your application. Even if all you wanted to do was perform a quick calculation or process a piece of data quickly to test your code, you had to create additional files you may not need later. No longer.

With C# 14, now you can run a C# file directly from the command line without needing a project or solution file.

Let us understand this with a code example. Consider a file named Demo.cs that contains the following code.

Console.WriteLine("This is a sample text");
DateTime dateTime = DateTime.UtcNow.Date;
Console.WriteLine($"Today's date is: {dateTime.ToString("d")}");

You can execute the program using the following command at the console window.

dotnet run Demo.cs

When the program is executed, you’ll see the following text displayed at the console.

Foundry

Note that you can create file-based apps that reference NuGet packages and SDKs using preprocessor directives, without needing a project or solution file.

Extension members

Extension members are a new feature in C# 14 that let you declare extension properties as well as extension methods. In addition, extension members make it easier to declare extension methods than in previous versions of C#. Before we dive into extension members, let’s first understand extension methods.

In the C# programming language, extension methods are a feature that permits you to augment the capabilities of classes without the necessity of inheritance. You do not need to create subclasses to use extension methods, nor is it necessary to modify or recompile existing class definitions. In addition to improving code readability, extension methods help you add new methods to your existing types (i.e., classes, structs, records, or interfaces). Incidentally, extension methods were first implemented in C# 3.0.

There are numerous extension methods in .NET that allow you to expand the querying capabilities of both System.Collections.IEnumerable and System.Collections.Generic.IEnumerable by using the LINQ standard query operator. While you can take advantage of extension methods to extend a class or an interface in C#, you cannot override their methods. Extension methods can help you to extend the functionality of types even if they are sealed, such as the String class in C#.

For example, the where() extension method is defined in the Enumerable static class pertaining to the System.Linq namespace. The following code snippet creates an instance of the where() extension method:

public static IEnumerable Where(
    this IEnumerable source, 
    Func predicate)

Note the use of the this keyword. Prior to C# 14, to implement an extension method, you had to create a static method and pass the this reference as a parameter to the method. In C# 14, the code snippet above can be replaced using an extension block, without the need of specifying the this parameter. This is shown in the code snippet given below.

extension(IEnumerable source)
{
    public IEnumerable 
     Where(Func predicate)
}

The ability to define extension members has other advantages as well. Note that an extension member requires two types of information, i.e., the receiver to which the member should be applied and any parameters it might need if the member is a method. With the new extension member syntax, you can define an extension block and then write the receivers as needed. Most importantly, this new syntax enables you to define a receiver for your extension member that doesn’t require any parameter, i.e., if you’re using an extension property. 

Additionally, by using the new syntax, you can logically group extensions that apply to the same receiver. You can then define a new extension block if the receiver changes. Moreover, the static class in which you write your extension blocks or extension methods (if you’re using an earlier version of the C# language) can contain both the extension methods that require the this parameter and the extension members grouped inside extension blocks, as shown in the C# 14 code listing given below.

public static class StringExtensions
{
    extension(string value)
    {
        public bool ContainsAnyDigit()
        {
            if (string.IsNullOrEmpty(value))
                return false;
            return value.Any(char.IsDigit);
        }
        public bool ContainsAnySpecialCharacter()
        {
            if (string.IsNullOrEmpty(value))
                return false;
            return value.Any(c => !char.IsLetterOrDigit(c));
        }
    }

    public static bool IsNullOrEmptyOrWhiteSpace(this string str)
    {
        return string.IsNullOrWhiteSpace(str);
    }
}

In the preceding code snippet, the extension method IsNullOrEmptyOrWhiteSpace uses the legacy syntax (i.e., it requires the this parameter), whereas the extension methods ContainsAnyDigit and ContainsAnySpecialCharacter use the new syntax.

You can read more about extension members in C# 14 here.

Improvements to the nameof operator for unbound generics

C# 14 brings improvements to the nameof keyword by supporting unbound generic types (e.g., List, Dictionary). Now that nameof can take an unbound generic type as an argument, you no longer need to define dummy type arguments (such as List) merely to obtain the type name “List.”

Let us understand this with a code example. In the following piece of code, you’ll need to specify the type argument for the cast to work perfectly.

string typeNameList = nameof(List);
string typeNameDictionary = nameof(Dictionary);

With C# 14, unbound generics work directly. You no longer need to specify the type explicitly, as shown in the code snippet given below.

string typeNameList = nameof(List);
string typeNameDictionary = nameof(Dictionary);

Hence, with C# 14, the following lines of code will work perfectly.

Console.WriteLine(nameof(List));
Console.WriteLine(nameof(Dictionary));

User-defined compound assignment operators

C# 14 comes with support for compound assignment operators. This feature enables you to write code similar to x += y instead of having to write x = x + y, as you do in the previous versions of the language. You can use compound assignment operators in C# 14 to overload +=, -=, *=, /=, %=, &=, |=, ^=, , and >>= operators.

Consider the following code snippet that creates a ShoppingCart class in which the += operator is overloaded.

public class ShoppingCart
{
    public int TotalQuantity { get; private set; } = 0;
    public decimal TotalAmount { get; private set; } = 0m;
    public void operator +=(int quantity)
    {
        TotalQuantity += quantity;
    }
    public void operator +=(decimal amount)
    {
        TotalAmount += amount;
    }
}

The code snippet below shows how you can use the ShoppingCart class.

public class ShoppingCart
{
    public int TotalQuantity { get; private set; } = 0;
    public decimal TotalAmount { get; private set; } = 0m;
    public void operator +=(int quantity)
    {
        TotalQuantity += quantity;
    }
    public void operator +=(decimal amount)
    {
        TotalAmount += amount;
    }
}

Thanks to user-defined compound assignment operators, we get cleaner, simpler, and more readable code.

Set TargetFramework to .NET 10

Naturally, you must have .NET 10 installed in your computer to work with C# 14. If you want to change your existing projects to use C# 14, you will need to set the TargetFramework to .NET 10 as shown in the code snippet given below.

  
    Exe
        preview
    net10.0
    enable
    enable
  

You can learn more about the new features in C# 14 here and here.

The C# programming language has improved significantly since its initial release as part of Visual Studio .NET 2002. That was a time when you had to write a lot of verbose code to create C# programs. The new features introduced in C# 14 promise to boost your productivity and help you write cleaner, more maintainable, and more performant code. Whether you’re building an enterprise application, a mobile application, or a web application, this new version of C# provides you with all you need to create world-class contemporary applications.

We know that mobile development in 2025 was different. It shifted from a “front-end” concern to a massive, distributed headache in which the most vulnerable component could be any unmanaged, hostile endpoint. In fact, 43% of organizational breaches originate at the mobile edge.

The problem lies with the outdated web-centric security models that app developers rely on. With mobile platforms operating under fundamentally different trust assumptions, their DevSecOps pipelines need to account for these explicitly.

Here are three technical blind spots that current pipelines often fail to address, and that modern DevSecOps engineers should watch out for.

Blind spot #1: Vulnerability to man-at-the-end attacks

In web-first development, the server is the ultimate “fortress.” Because we control the hardware and software environment, security is focused on sanitizing inputs and hardening the perimeter. Traditional web-centric SAST (static application security testing) tools are designed for this model. They scan for logical flaws in the server binary, assuming the binary itself remains protected within the fortress. On the web, the “don’t trust your client” strategy is easily maintained because the client-side code typically has limited features and can be ephemeral.

In comparison, a mobile app is a “messenger in enemy territory.” The device and the end-user cannot be trusted, as the app binary is physically in the attacker’s hands. Unlike web servers, mobile clients are often responsible for more complex local functions, creating a much larger surface. An attacker can tamper with the binary through repackaging or use tools like Frida to perform dynamic instrumentation to bypass security controls in real time. Because web-centric SAST tools assume the binary is safe in a fortress, they often overlook these critical mobile-specific vulnerabilities and tampering scenarios. 

Frida injects a JavaScript engine into the target process’s memory space, allowing an attacker to intercept function calls in real time. Specifically, it leverages inline hooking and PLT/GOT (procedure linkage table/global offset table) interception. It allows the user to redirect the execution of the application code to attacker-controlled code. 

While static measures like control flow flattening (modifying the graph of a function to hide its logic) and symbol stripping (removing function names) increase the cost of initial analysis, they cannot stop a dynamic tool like Frida once the attacker identifies the correct memory offsets.

To counter these threats, developers need to do more than obfuscation. They need to add RASP (runtime application self-protection), which monitors the application’s state while it is running. RASP includes:

• Hooking framework detection: Most hooking framework leaves “artifacts” behind. So, a classical technique to detect them consists of looking for them. For example, Frida often communicates via specific default ports (e.g., 27042) or named pipes. Check /proc/self/maps to see if unauthorized .so or .dylib files (like frida-agent.so) have been injected into the process space. However, such detections are useful only as a first layer of defense. Attackers can bypass them quite easily by, for instance replacing “frida” strings by “grida” or changing the port used.
• Anti-tamper and hook detection: In addition to the framework detection, the app should actively scan its own memory. For example, it should periodically check the first few bytes of critical functions for “jump” or “breakpoint” instructions (0xE9 or 0xCC on x86) that indicate a trampoline has been inserted. Perform integrity checks on the .text section of the binary in memory to ensure it matches the signed disk version.
• Hardware-backed attestation: This provides a zero-trust verification of the client environment using the OS as a source of truth. Services such as the Android Play Integrity API generate a signed cryptographic token from the OS manufacturer. This token verifies that the binary is unmodified, the device isn’t rooted, and a debugger hasn’t compromised the environment before the back end grants access to sensitive resources.

Blind spot #2: Misunderstanding hardware-backed cryptography

Misuse of local device storage creates a common architectural blind spot. Standard encryption libraries often store the master key in the app’s private directory. It may be technically encrypted, but it also creates a blind spot, making the approach equivalent to leaving your house key under the doormat.

EncryptedSharedPreferences and the iOS Keychain are not magic bullets. If these are not explicitly configured to be hardware-backed, the keys remain in the software layer. On a rooted device, an attacker could perform a memory dump or use an Android device backup exploit to extract the keys and decrypt the entire local database. The OS’s “private” sandbox is only as secure as the kernel, and on many user devices, the kernel is an open book.

To address this blind spot, developers must enforce cryptographic binding to the hardware:

• TEE (trusted execution environment) and secure enclave integration: Force keys to be generated and stored within the TEE or secure enclave. This ensures that the private key never enters the application’s memory space. The app sends data to the hardware, the hardware signs or decrypts it and returns the result.
• User-presence requirements: For high-security apps (such as those developed for fintech or health care), the cryptographic key is to be unlocked only by a successful biometric prompt. So even if a device is stolen while “unlocked,” the app’s sensitive data remains cryptographically inaccessible without a secondary “proof of presence.”

Blind spot #3: Managing the logic entropy of AI assistants

The rise of AI-assisted vibe coding is introducing a new class of logic entropy. Gartner’s projection that 90% of engineers will use AI assistants by 2028 creates a systemic risk: the proliferation of “insecure by default” boilerplate.

AI models are trained on vast amounts of legacy code. When you ask an AI to implement a network call, it often ignores certificate pinning. Sometimes, it uses deprecated TLS (Transport Layer Security) versions because those patterns are statistically more common in its training set. For example, Stanford researchers found that AI-assisted developers are 80% more likely to produce code with vulnerabilities like plaintext credentials or insecure random number generators.

Furthermore, AI can “hallucinate” security configurations. This suggests that nonexistent parameters that appear valid can cause the OS to default to a “fail-open” state. A penetration test of AI-generated mobile code often reveals “shadow logic” that implements complex encryption. Still, the IV (initialization vector) is hardcoded, making the cryptography vulnerable to modern GPU-based brute-force attacks.

DevOps teams need to treat AI as an untrusted contributor:

• Custom linting or analysis for crypto-primitives: Implement custom rules (e.g., using mast tools or custom linting) that specifically target the usage of AllowAllHostnameVerifier or InsecureTrustManager, which are common AI “shortcuts” to make code work.
• SBOM (software bill of materials) enforcement: Developers must run an SBOM check to validate every dependency against a vulnerability database before entering the build stage.

Soon-to-be blind spot: An iOS sideloading surge

In 2026, the abuse of Enterprise Provisioning Profiles will become an additional blind spot. To comply with regulations such as the Digital Markets Act, platforms opened “sideloading” channels. This is not new for Android, but it is also becoming relevant for iOS platforms as they now have to support alternative app stores. So, while this helped with internal distribution, it has become a primary vector for repackaging attacks.

Sideloading itself is not the problem. The risk emerges when applications cannot verify their own integrity at runtime. Attackers can take a legitimate app, inject a malicious library (using the memory hooking techniques mentioned above), and re-sign it with a leaked or stolen enterprise certificate. Since the app is signed with a valid Apple or Google-issued developer certificate, it can bypass many OS-level warnings, leading users to install “cracked” versions that are actually surveillanceware.

App developers must monitor for certificate mismatch. Your app should self-verify the fingerprint of its signing certificate at runtime by comparing the active signing key against an embedded hash of your official production key. If the fingerprint doesn’t match, the app should assume it has been repackaged and immediately invalidate all local user sessions and clear the hardware-backed keystore.

Building for a hostile runtime

It’s common for developers to complain about security taxing performance. RASP checks increase the main thread’s load and can cause frame drops during UI transitions. Hardware-backed encryption adds latency to disk I/O as data must move across the bus to the processor.

Despite these hurdles, with 75% of organizations increasing mobile security spend, the industry is acknowledging that this “performance tax” is significantly cheaper than the average cost of a breach.

In 2026, a robust mobile pipeline doesn’t just “check for bugs” but assumes the app is being run in a laboratory by a malicious actor. Our job is to make the cost of data extraction higher than the value of the data itself.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Once envisioned as a bridge between Java and JavaScript, the Detroit project never got off the ground. Now, there are efforts at reviving it, adding a Python engine to the mix.

Intended to enable using JavaScript as an extension language for Java applications, the Detroit project fizzled out after losing its sponsoring group around 2018. But according to a new proposal dated February 25, there still is interest in bringing Java and JavaScript together. The proposal was gathering steam on an OpenJDK mailing list this week.

List participant Sundararajan Athijegannathan, who has offered to lead the project, wrote that “there is also interest in accessing AI functionality written in Python from Java applications.” In addition to extending JavaScript to Java applications, Java libraries would be accessed from JavaScript applications, according to Athijegannathan.

The Detroit project prototype, which involved developing a native implementation of the javax.script package based on the Chrome V8 JavaScript engine, has been revived, Athijegannathan said. Participants also have prototyped a Python script engine based on CPython. Using widely adopted JavaScript and Python implementations, rather than re-implementing the languages from scratch, ensures low long-term maintenance costs and compatibility with existing JavaScript and Python code, Athijegannathan wrote.

“We would like to move these prototypes into a proper OpenJDK project in order to accelerate development. We expect to leverage and push the boundaries of the FFM (Foreign Function & Memory) API, so this work will likely influence Project Panama,” he wrote. Panama looks to improve connections between the JVM and non-Java APIs. Over time, the project may consider implementing script engines for additional languages. Votes on the project, from current OpenJDK members only, are due by March 11.

Inception has introduced Mercury 2, calling it the world’s fastest reasoning LLM. Intended for production AI, the large language model leverages parallel refinement rather than sequential decoding.

Mercury 2 was announced February 24, with access requests available on Inception’s website. Developers can also try Mercury 2 using the Inception chat.

Inception says Mercury 2 is intended to solve a common LLM bottleneck involving autoregressive sequential decoding. The model instead generates responses through parallel refinement, a process that produces multiple tokens simultaneously and converges over a small number of steps, Inception said. Parallel refinement results in much faster generation and also changes the reasoning trade-off, according to the announcement. Higher intelligence typically leads to more computation at test time, meaning longer chains, more samples, and more retries. This all results in higher latency and costs. Mercury 2 uses diffusion-based reasoning to provide reasoning-grade quality inside real-time latency budgets, said the company.

Mercury 2 is OpenAI API-compatible and especially suited to latency-sensitive applications where the user experience is non-negotiable, the company said. Use cases include coding and editing, agentic loops, real-time voice and interaction, and pipelines for search and RAG operations.

Microsoft says it has uncovered a coordinated campaign targeting software developers through malicious repositories posing as legitimate Next.js projects and technical assessments.

The campaign employs carefully crafted lures to blend into routine workflows, such as cloning repositories, opening projects, and running builds, thereby allowing the malicious code to execute undetected.

Telemetry collected during an incident investigation by Microsoft suggested the campaign’s alignment with a broader cluster of threats using job-themed tricks. “During initial incident analysis, Defender telemetry surfaced a limited set of malicious repositories directly involved in observed compromises,” the company wrote in a security blog post. “Further investigation uncovered additional related repositories that were not directly referenced in observed logs but exhibited the same execution mechanisms, loader logic, and staging infrastructure.”

The campaign exploits developers’ trust in shared code, gaining persistence within high-value developer systems that often contain source code, environment secrets, credentials, and access to build or cloud infrastructure.

Multiple triggers for remote control

Microsoft researchers found that the malicious repositories were engineered with redundancy, offering several execution paths that ultimately result in the same backdoor behavior.

In some cases, simply opening the project in Visual Studio Code was enough. The attackers abused workspace automation by embedding tasks configured to run automatically when a folder is opened and trusted. This causes code execution without the developer running anything.

Other variants rely on build processes or server startup routines, ensuring that the malicious code runs when developers perform typical actions such as launching a development server. Regardless of the trigger, the repositories retrieve additional JavaScripts from remote infrastructure and execute it in memory, reducing traces on disk.

The retrieved payload operates in stages. An initial registration component identifies the host and can deliver bootstrap instructions, after which a separate C2 controller provides persistence and enables follow-on actions such as payload delivery and data exfiltration.

Infection through a fake “coding test”

Microsoft said the investigation started with analyzing the suspicious outbound connections from Node.js processes communicating with attacker-controlled servers. Correlating network activity with process telemetry led analysts back to the original infection through recruiting exercises.

One of the repositories was hosted on Bitbucket and presented as a technical assessment, along with a related repository using the Cryptan-Platform-MVP1 naming convention. “Multiple repositories followed repeatable naming conventions and project ‘family’ patterns, enabling targeted searches for additional related repositories that were not directly referenced in observed telemetry but exhibited the same execution and staging behavior,” Microsoft wrote.

When an infection is suspected, Microsoft warns that affected organizations must immediately contain suspected endpoints, trace the initiating process tree, and hunt for repeated polling to suspicious infrastructure across the fleet. Because credential and session theft may follow, responders should evaluate identity risk, revoke sessions, and restrict high-risk SaaS actions to limit exposure during investigation.

Long-term mitigations include a focus on tightening developer trust boundaries and reducing execution risk, Microsoft added. Other recommendations include enforcing Visual Studio Code Workspace Trust defaults, applying attack surface reduction rules, enabling cloud-based reputation protections, and strengthening conditional access.

It’s tough out here for a dev/tech writer.

Back in the before days (that is, about two months ago), you could always find a variety of topics to write about. “Seven ways to improve your database design,” say. Or  “Five things I never do in code.”  There were a ton of things that developers were concerned about when it came to writing code. The study of clean code and how to write it was a constant struggle for improvement. Diligent developers were eager for new ways to be better.

Now? You aren’t writing code, and you aren’t designing databases. Your coding agent is. 

So here I am, writing about coding agents again. Which, I guess, is a good thing, because, oh my, this is all quite electrifying.

I’ve had a bunch of ideas for websites, some for fun and some that could potentially generate a modest revenue stream. This past weekend, I decided to implement one of the revenue-generating ideas. It’s up and running today. (I’m not shameless enough to post a link here.) Suffice it to say, it’s a small tool to help developers do something that no one likes to do. 

Along the way, I learned an interesting lesson.

What Claude did

The whole experience was astonishing. I’m a Claude Code user. I feel comfortable that he (and yes, I anthropomorphize him) knows what he’s doing. Plus, I have an Enterprise account that I use with a client’s project. I have a pretty solid Claude.md file that I use as a base. I gave a pretty thorough description of the project that I wanted, and told Claude to get to work. 

And in about 20 minutes, he had a website up and running, doing exactly what I wanted. Exactly. Precisely. Correctly.

It was dumbfounding.

Then, being a man of entrepreneurial spirit, I told Claude to figure out a way for me to charge for the service. He suggested a system of credits—one credit, one transaction—and a common third-party service to do the credit card work.

Claude then gave me a set of instructions to set up the credit card service on the provider’s website. And because now, given Claude’s capabilities, I am far too lazy to do all this myself, I asked him to do it all. And he did. Yes, I realize I’m giving personhood to an abstraction that is doing what humans used to do.

But what Claude did was a real eye-opener. He downloaded the service’s command-line interface and used it to do all the work (except logging in—I had to do that). He couldn’t (yet, I suppose) use the website itself. But a CLI? Child’s play. 

And then it hit me: My website was not what potential customers would be looking for. Although what the site did was useful, no one in the age of agentic coding was going to use it. Instead, they would want some way to have their coding agent, or their build process, or some other automated thing, use my system. 

What I learned

So I told Claude to build a command-line tool to do the process. In about 20 more minutes, tools for Mac, Windows, and Linux, as well as variations for Arm and x86, were all built and ready. He changed the website to make the CLI the main thing and presented the correct download to the user depending on the OS that the incoming browser request was running on.

Again, all on a Saturday afternoon.

The lesson here isn’t that you can build a website in an afternoon—we already knew that. The lesson here is that much of what we are doing now is not coding for humans—we are now coding for other agents. (Inasmuch as what we are doing can be called “coding” anymore.)

In the coming days, and I think “days” is literal here, we will be spending a whole lot less time worrying about the usability of our websites and more time considering the efficiency of our APIs and CLIs. 

I didn’t want to deal with that credit card processor’s website. Instead, I wanted Claude to do it via their CLI, and he did. No one will want to go to my website to do the task I provide; they’ll want Claude to do it with my CLI. I imagine Claude soon will prefer to deal more efficiently with a REST API, and so I suppose I’ll have to build that. 

Or rather, Claude will build it for me. Maybe that’s why I call him “he.” It’s easier to be replaced by a someone than by a something.

MariaDB may have started as a MySQL fork, following Oracle’s acquisition of MySQL, but with time it’s charted its own path. Over the last few major revisions, the open source RDBMS has added unique functions, greater compatibility with MySQL, and a suite of behaviors designed to make it a migration target for Oracle SQL users. Here’s a quick look at some of the best and most powerful new features in MariaDB.

Also see: 4 self-contained databases for your apps.

Opt-in Oracle compatibility

Ever since version 10.3, MariaDB has been steadily adding Oracle compatibility features, making it easier to port Oracle to MariaDB as-is.

Oracle compatibility is opt-in. All you need to do is issue the command SET SQL_MODE='ORACLE' to activate it for a given set of SQL statements. Existing MariaDB behaviors will also be preserved wherever possible.

Most Oracle compatibility features are geared to supporting Oracle SQL syntax, especially where it deviates from ANSI SQL or MariaDB. For instance, Oracle SQL allows you to call stored procedures using the name of the stored procedure rather than the CALL keyword.

But other recent changes to Oracle compatibility mode involve underlying behaviors, not just syntax. As of MariaDB 12.0, single triggers can execute on multiple INSERT/UPDATE/DELETE events, an Oracle SQL feature that’s difficult to replicate manually.

MariaDB (the company) also offers a migration tool that analyzes an Oracle SQL DDL export file (just the data definition, no actual data) and assesses how well it will run with MariaDB’s Oracle compatibility mode.

AI features: MCP servers and vector types

AI features are finding their way into (some might say infesting) most every data-centric software product. While MariaDB is no exception, its AI features look to be actual tools, not just marketing glaze.

MariaDB 11.8 added a native VECTOR data type, a way to embed information about text similarity in a database. This lets you use MariaDB as an engine for building things like natural-language queries, recommendation systems, RAG solutions, and general-purpose machine learning tasks. Much of the heavy lifting for such work can be done directly in the database, avoiding round trips to external applications.

Another recent AI addition makes MariaDB an extension of existing AI agents. The Model Context Protocol (MCP), provides a common way for LLMs to talk to external tooling—for instance, to search the web. MariaDB now offers its own MCP server components to make it easy for LLMs to query MariaDB instances. It’s also possible to use embeddings (via OpenAI, Gemini, or open Huggingface models) to perform semantic searches on documents stored in the database.

More JSON features

NoSQL databases gave developers the freedom to use open-ended schemas, defined as JSON documents, to store data. Conventional SQL databases have since added their own native JSON functionality, a useful way to get NoSQL’s flexibility without ditching conventional SQL’s formal schemas.

In MariaDB, there’s a JSON column type, which accepts text in JSON format and can be automatically validated with a JSON_VALID CHECK constraint. If you want your JSON data to follow strict data types, you can add constraints for specific keys (e.g., key year should always be a valid INTEGER).

SELECT queries can extract data from JSON columns by key:

SELECT id, name, JSON_QUERY(attr, '$.dates.release') AS release_year FROM movies

They can also filter by values:

SELECT id, name FROM movies WHERE JSON_VALUE(attr, '$.dates.release') = 1981

For more performant operations against JSON, you can create virtual columns that map to keys in the document, and also build indexes from those virtual columns:

ALTER TABLE movies ADD COLUMN
    release_year SMALLINT AS (JSON_VALUE(attr, '$.dates.release'));
CREATE INDEX releaseyears ON movies(release_year);

It’s also possible to modify the data without extracting the JSON and manipulating it. JSON_INSERT(), JSON_ARRAY_APPEND(), and JSON_REMOVE() all let you perform these kinds of in-place transformations faster and more reliably than trying to fiddle with the data manually outside of MariaDB.

Expanded optimizer hints

Experienced database developers appreciate having granular control over how queries execute. MariaDB has long had hints, or “modifiers,” for SELECT statements, such as HIGH_PRIORITY and FORCE INDEX.

With MariaDB 12.0 came so-called new-style optimizer hints, a way to apply hints to specific tables or indexes as well as globally. These hints are formatted as inline comments with /*+ and */ delimeters.

Expanded hints aren’t for everyday use. They force-enable (or disable) behaviors that typically work fine as-is, but in certain scenarios work better when explicitly controlled. For instance, an INDEX_MERGE hint tells the query optimizer which specific indexes to use—and no others—when performing index scans on multiple columns. This can speed up queries on a table with many indexes, or no composite index to cover a specific query. But don’t assume your ideas about how these optimizations work in theory will play out in practice. It’s always best to use an EXPLAIN statement along with a query optimization to find out if it does, in fact, speed things up.

Other new hints are useful for troubleshooting as well as performance. For instance, the MAX_EXECUTION_TIME() hint can abort a specific query after a certain number of milliseconds. This hint can be used to prevent “pathological” queries from tying up the system, but also as part of the process of debugging an existing query with a tendency to run wild.

A new XML type

Another forward-looking improvement, although it doesn’t actually do much yet, is a new XMLTYPE column type, introduced in MariaDB 12.3. Right now, all it does is accept a string of up to 4GB in size, and allow for selective replacement of XML with the UPDATEXML function. While there is no attempt to validate the XML or enforce a schema currently, those features are slated to land later, and to make XMLTYPE more functionally compatible with Oracle. It opens the path for future expansion.

Features still missing

As MariaDB has matured and started to take its own development path apart from MySQL, it’s introduced many features not found in MySQL, like dynamic or virtual columns. But the reverse also holds: Some MySQL features still aren’t present in MariaDB, at least not yet.

One major missing feature, MySQL resource groups, has been proposed but still needs work to be implemented. Other features will likely never be cross-compatible, like support for MySQL’s ‘packed’ (binary) storage format for JSON.

And, because MariaDB and MySQL have different and incompatible methods for global transaction IDs, you can use a MariaDB server as a replica for a MySQL server but not the other way around. On the upside, this means you can use replication as a migration strategy from MySQL to MariaDB. Just make sure you have compatible versions of both databases.

Java Development Kit (JDK) 26, a planned update to standard Java due March 17, 2026, has reached its second release candidate (RC) stage. The RC is open for critical bug fixes, with the feature set having been frozen in December.

The following 10 features are officially targeted to JDK 26: a fourth preview of primitive types in patterns, instanceof, and switch, ahead-of-time object caching, an eleventh incubation of the Vector API, second previews of lazy constants and PEM (privacy-enhanced mail) encodings of cryptographic objects, a sixth preview of structured concurrency, warnings about uses of deep reflection to mutate final fields, improving throughput by reducing synchronization in the G1 garbage collector (GC), HTTP/3 for the Client API, and removal of the Java Applet API.

A short-term release of Java backed by six months of Premier-level support, JDK 26 follows the September 16 release of JDK 25, which is a Long-Term Support (LTS) release backed by several years of Premier-level support. Early-access builds of JDK 26 are available at https://jdk.java.net/26/. The initial rampdown phase began in early December, and the second rampdown phase in mid-January.

The latest feature to be added, primitive types in patterns, instanceof, and switch, is intended to enhance pattern matching by allowing primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types. Now in a fourth preview, this feature was previously previewed in JDK 23, JDK 24, and JDK 25. The goals include enabling uniform data exploration by allowing type patterns for all types, aligning type patterns with instanceof and aligning instanceof with safe casting, and allowing pattern matching to use primitive types in both nested and top-level pattern contexts. Changes in this fourth preview include enhancing the definition of unconditional exactness and applying tighter dominance checks in switch constructs. The changes enable the compiler to identify a wider range of coding errors.

With ahead-of-time object caching, the HotSpot JVM would gain improved startup and warmup times, so it can be used with any garbage collector including the low-latency Z Garbage Collector (ZGC). This would be done by making it possible to load cached Java objects sequentially into memory from a neutral, GC-agnostic format, rather than mapping them directly into memory in a GC-specific format. Goals of this feature include allowing all garbage collectors to work smoothly with the AOT (ahead of time) cache introduced by Project Leyden, separating AOT cache from GC implementation details, and ensuring that use of the AOT cache does not materially impact startup time, relative to previous releases.

The eleventh incubation of the Vector API introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs. This achieves performance superior to equivalent scalar computations. The incubating Vector API dates back to JDK 16, which arrived in March 2021. The API is intended to be clear and concise, to be platform-agnostic, to have reliable compilation and performance on x64 and AArch64 CPUs, and to offer graceful degradation. The long-term goal of the Vector API is to leverage Project Valhalla enhancements to the Java object model.

Also on the docket for JDK 26 is another preview of an API for lazy constants, which had been previewed in JDK 25 via a stable values capability. Lazy constants are objects that hold unmodifiable data and are treated as true constants by the JVM, enabling the same performance optimizations enabled by declaring a field final. Lazy constants offer greater flexibility as to the timing of initialization.

The second preview of PEM (privacy-enhanced mail) encodings calls for an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the  PEM transport format, and for decoding from that format back into objects. The PEM API was proposed as a preview feature in JDK 25. The second preview features a number of changes, such as the PEMRecord class is now named PEM and now includes a decode()method that returns the decoded Base64 content. Also, the encryptKey methods of the EncryptedPrivateKeyInfo class now are named encrypt and now accept DEREncodable  objects rather than PrivateKey objects, enabling the encryption of KeyPair and PKCS8EncodedKeySpec objects.

The structured concurrency API simplifies concurrent programming by treating groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. Goals include promoting a style of concurrent programming that can eliminate common risks arising from cancellation and shutdown, such as thread leaks and cancellation delays, and improving the observability of concurrent code.

New warnings about uses of deep reflection to mutate final fields are intended to prepare developers for a future release that ensures integrity by default by restricting final field mutation, in other words making final mean final, which will make Java programs safer and potentially faster. Application developers can avoid both current warnings and future restrictions by selectively enabling the ability to mutate final fields where essential.

The G1 GC proposal is intended to improve application throughput when using the G1 garbage collector by reducing the amount of synchronization required between application threads and GC threads. Goals include reducing the G1 garbage collector’s synchronization overhead, reducing the size of the injected code for G1’s write barriers, and maintaining the overall architecture of G1, with no changes to user interaction.

The G1 GC proposal notes that although G1, which is the default garbage collector of the HotSpot JVM, is designed to balance latency and throughput, achieving this balance sometimes impacts application performance adversely compared to throughput-oriented garbage collectors such as the Parallel and Serial collectors:

Relative to Parallel, G1 performs more of its work concurrently with the application, reducing the duration of GC pauses and thus improving latency. Unavoidably, this means that application threads must share the CPU with GC threads, and coordinate with them. This synchronization both lowers throughput and increases latency.

The HTTP/3 proposal calls for allowing Java libraries and applications to interact with HTTP/3 servers with minimal code changes. Goals include updating the HTTP Client API to send and receive HTTP/3 requests and responses; requiring only minor changes to the HTTP Client API and Java application code; and allowing developers to opt in to HTTP/3 as opposed to changing the default protocol version from HTTP/2 to HTTP/3.

HTTP/3 is considered a major version of the HTTP (Hypertext Transfer Protocol) data communications protocol for the web. Version 3 was built on the IETF QUIC (Quick UDP Internet Connections) transport protocol, which emphasizes flow-controlled streams, low-latency connection establishment, network path migration, and security among its capabilities.

Removal of the Java Applet API, now considered obsolete, is also targeted for JDK 26. The Applet API was deprecated for removal in JDK 17 in 2021. The API is obsolete because neither recent JDK releases nor current web browsers support applets, according to the proposal. There is no reason to keep the unused and unusable API, the proposal states.

Google has added an agent step to its Opal tool for building AI-powered mini-apps. Powered by the Gemini 3 Flash model, the new agent in Opal enables autonomous workflows that plan, reason, and execute on the user’s behalf, Google said.

Introduced February 24 and available to all Opal users, the agent step upgrades Opal workflows from static model calls to agentic intelligence, according to Google. Now, instead of manually picking a model, developers can select an agent in the “generate” step. The agent then triggers the right tools and models, such as Web Search for research or Veo for video, needed to accomplish the user’s intended mission. The agent can also make use of persistent memory, dynamic routing, and interactive chat with the user.

With persistent memory, the agent can use Google Sheets to remember information across sessions, such as style preferences or ongoing lists, thus making mini-apps smarter the more they are used. With dynamic routing, the agent evaluates work and decides which steps to trigger next, bringing autonomy to mini-apps. With interactive chat, the agent can initiate a chat with the user to gather missing information or offer choices before moving to a plan’s next stage.

Google presented an example in which creating a storybook Opal had required predefining page counts and user questions. Users now can build a Visual Storyteller Opal where the agent step autonomously decides which details it needs and suggests plot points to help direct where a story goes. This marks a shift from rigid formats to dynamic, unique narratives shaped by creative decisions, Google said.

A massive Shai-Hulud-style npm supply chain worm is hitting the software ecosystem, burrowing through developer machines, CI pipelines, and AI coding tools.

Socket researchers uncovered the active attack campaign and called it SANDWORM_MODE,  derived from the “SANDWORM_*” environment variable switches embedded in the malware’s runtime control logic.”

At least 19 typosquatted packages were published under multiple aliases, posing as popular developer utilities and AI-related tools. Once installed, the packages execute a multi-stage payload that harvests secrets from local environments and CI systems, then uses stolen tokens to modify other repositories.

The payload also implements a Shai-Hulud-style “dead switch” that remains OFF by default to trigger home directory wiping when the malware is detected. Researchers called the campaign a  “real and high-risk” threat, advising defenders to treat the packages as active compromise risks.

Typo to takeover

The campaign starts with typosquatting, where attackers publish packages with names nearly identical to legitimate ones, banking on a developer typo or an AI hallucinating wrong dependencies.

“The typosquatting targets several high-traffic developer utilities in the Node.js ecosystem, crypto tooling, and, perhaps most notably, AI coding tools that are seeing rapid adoption: three packages impersonate Claude Code and one targets OpenClaw, the viral AI agent that recently passed 210k stars on GitHub,” the researchers wrote in a blog post.

Once a malicious package is installed and executed, the malware hunts for sensitive credentials, including npm and GitHub tokens, environment secrets, and cloud keys. Those credentials are then used to push malicious changes into other repositories and inject new dependencies or workflows, expanding the infection chain.

Additionally, the campaign uses a weaponized GitHub Action that could potentially amplify the attack inside CI pipelines, extracting secrets during builds and enabling further propagation, the researchers added.

Poisoning the AI developer interface

The campaign was specifically flagged for its direct targeting of AI coding assistants. The malware deploys a malicious Model Context Protocol (MCP) server and injects it into configurations of popular AI tools, embedding itself as a trusted component in the assistant’s environment.

Once this is achieved, prompt-injection techniques can trick the AI into retrieving sensitive local data, which can include SSH keys or cloud credentials, and pass it to the attacker without the user’s knowledge.

Anthropic has accused three Chinese AI developers of running large-scale campaigns to illicitly extract capabilities from its Claude model to improve their own systems. The company claims DeepSeek, Moonshot, and MiniMax used a distillation technique, where a less capable model is trained on the outputs of a more advanced one.

More than 16 million interactions were generated with Claude through around 24,000 fraudulent accounts, in violation of Anthropic’s terms of service and regional access restrictions.

Anthropic said it does not offer commercial access to Claude in China, nor to subsidiaries of these companies operating outside the country.

How Claude’s capabilities were extracted at scale

Anthropic said the three distillation campaigns followed a similar playbook, where they used fraudulent accounts and proxy services to access Claude at scale while evading detection, and targeting Claude’s agentic reasoning, tool use, and coding capabilities.

The DeepSeek campaign involved over 150,000 exchanges, focused on extracting reasoning capabilities across diverse tasks. The activity generated synchronized traffic across accounts, with identical patterns, shared payment methods, and coordinated timing suggested load balancing to increase throughput, improve reliability, and avoid detection. 

Moonshot AI’s activity involved over 3.4 million exchanges targeting agentic reasoning and tool use, coding and data analysis, computer-use agent development, and computer vision to reconstruct Claude’s reasoning traces. MiniMax was the largest of the three, involving more than 13 million exchanges, and was squarely targeted at agentic coding and tool use and orchestration. Detected while the campaign was active, Anthropic said MiniMax redirected nearly half of its traffic to Claude’s newly released model within 24 hours.

To carry out the campaigns, Anthropic said the companies relied on commercial proxy services that resell access to Claude and other frontier AI models at scale, referred to as hydra cluster architectures.

Back to the basics of AI model training

Industry experts note that the allegations raise a broader and unresolved question around how AI systems are trained. Most large language models, including leading commercial systems, are themselves trained on vast amounts of publicly available internet data, often without explicit consent from original authors.

“Just as many of the foundation models have been built by indexing the vastness of the internet, often without the explicit consent of creators or piggybacking on other search engines’ content, the newer entrants are in many instances going through the same routes of distillation and optimization,” said Neil Shah, vice president at Counterpoint Research. He added that there is a fundamental disagreement, which is mostly legally undefined, about who owns the synthetic data and whether it is okay if it is used for training, especially open models.

Export controls and national security

Anthropic has framed the alleged distillation campaigns partly through a national security lens, arguing that illicitly distilled models could undermine US efforts to control the spread of advanced AI capabilities, especially if influenced by the Chinese Communist Party. However, experts note that current US export controls are largely focused on hardware, and not on large language models.

“It is critical to separate hardware restrictions from service access. US export controls have concentrated primarily on advanced semiconductors, high-performance computing infrastructure, and, in certain regulatory moments, specific categories of advanced AI model weights. There is no universal prohibition on offering API access to large language models in China,” explained Sanchit Vir Gogia, CEO and chief analyst at Greyhound Research.

However, this does not mean developers are insulated. Gogia added that the Bureau of Industry and Security continues to refine licensing frameworks related to advanced computing commodities and high-capability systems. Also, if a company knowingly supports training activity for restricted entities, especially those tied to military or strategic objectives, exposure becomes plausible even without hardware shipment.

To safeguard themselves, many US AI providers already restrict availability in China through business policy and compliance posture, even beyond what is strictly required.

“For developers, the risk is indirect but real: if your product routes access to restricted geographies or entities, facilitates prohibited end uses, or helps others evade provider geo-restrictions, you can trigger account termination, contractual liability, and potentially regulatory scrutiny depending on who the end user is and what the system enables,” said global partner/senior managing director – India at Ankura Consulting.

Implications for teams building with LLMs

For developers building or training models using large language models, the Anthropic allegations highlight a growing grey area. Developers commonly use LLM APIs for application development, testing, or evaluation. But providers are scrutinizing large-scale, automated use of model outputs to train competing systems.

For instance, Anthropic is responding by investing in defensive techniques. For detection, the company has built several classifiers and behavioural fingerprinting systems designed to identify distillation attack patterns in API traffic. It has also strengthened verification for educational accounts, security research programs, and startup organizations, citing them as the pathways most commonly exploited for setting up fraudulent accounts. The company is also implementing product, API, and model-level safeguards designed to reduce the efficacy of model outputs for illicit distillation, without degrading the experience for legitimate customers.

Developers, too, should ensure their model training stays safe, compliant, and defensible.

Jaju stated that, to start with, developers should review API/service terms and assume no training on outputs unless explicitly permitted. They should maintain a clear record of where every training/example item came from, with licensing/terms attached. Separate operational logs from training datasets should be maintained along with set retention limits.

“Geopolitical diligence cannot be an afterthought. Restricted party screening, export compliance reviews, and region-specific access controls are increasingly part of AI governance, especially for enterprises operating across borders,” added Gogia.

Experts say that if questioned by a regulator or acquirer to explain the training pipeline, developers should be able to provide the same with documentation and without caveats.

High inference latency and spiraling GPU costs have emerged as the primary bottlenecks for IT leaders deploying agentic AI systems. These workflows often generate thousands of tokens per query, creating a performance gap that current hardware struggles to bridge.

Now, researchers from the University of Maryland, Lawrence Livermore National Labs, Columbia University, and TogetherAI say they can triple inference speed on reasoning benchmarks by fine-tuning pretrained models so that acceleration is embedded into their weights, removing the need for speculative decoding or auxiliary draft models.

In a paper published this month, the team describes a multi-token prediction technique that converts standard next-token models into parallel decoders using a special added mask token and an online self-distillation objective.

In benchmark tests, the approach delivered more than 3x acceleration with minimal accuracy loss, a trade-off that could appeal to enterprises struggling to balance cost and model quality in production AI systems.

The final model reportedly retains the same implementation as the pretrained initial checkpoint and is deployable without the addition of any auxiliary verifier or other specialized inference code.

How the technique works

Traditional LLMs generate one token per forward pass, a design that inherently caps throughput.

This serial bottleneck is especially problematic for reasoning models, which generate thousands of tokens during a “chain of thought,” even for short final responses. Producing multiple tokens in one pass reduces both latency and cost.

To ensure coherence, the researchers rely on a student–teacher setup. Using a zookeeper analogy, they note that a model predicting multiple words independently might nonsensically output that a zookeeper fed “meat to a panda.” The teacher model evaluates these multi-token spans to ensure they make sense together.

“We propose an RL-inspired training paradigm in which a student model generates a span of simultaneous token predictions,” the researchers said in the paper. “To avoid the pitfalls of the standard offline objective, the student output is scored by an LM critic/teacher, rather than being scored against a known ground-truth token sequence.”

“By comparing the student’s predictions against the next-token suggestions made by the teacher, we produce an on-policy reward signal that enables the student to quickly improve the quality of its multi-token predictions,” they added.

At inference time, the system uses a confidence-adaptive (ConfAdapt) decoding strategy that dynamically determines how many tokens to emit per pass. When the model is highly confident, it outputs larger chunks. When uncertainty rises, it falls back to smaller steps, preserving accuracy while maintaining speed gains.

In experiments on GSM8K math reasoning benchmarks, an 8B parameter model achieved more than 3x acceleration with less than a 3 percent drop in accuracy. A smaller 4B parameter model reached similar speedups, though with a larger 7 percent drop in accuracy. More aggressive configurations pushed acceleration to 5x, though at steeper accuracy costs.

Unlike speculative decoding, which requires auxiliary speculator models and specialized inference pipelines, this approach trains a single model that retains the same implementation as the original checkpoint and requires no auxiliary verifier.

What this means for enterprise AI

Analysts say the bigger question is whether this approach meaningfully changes how inference stacks are designed in production.

“Speculative decoding attempts to break that constraint by introducing a draft model that proposes tokens and a target model that verifies them,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “In theory, this yields lossless acceleration. In practice, verification cost, batching interaction, and draft-target drift reduce realized gains.”

By contrast, he said, the multi-token approach retains the autoregressive backbone but shifts optimization into the training phase.

“The economic impact depends on entropy distribution across the output,” Gogia said. “In reasoning-heavy or structured tasks, predictable spans can be emitted in larger blocks with limited degradation. In higher-entropy, open-ended generation, acceleration shrinks. This is selective compression, not universal speed.”

That distinction matters for enterprise deployments.

“ConfAdapt is fundamentally entropy-sensitive,” Gogia said. “Its strategic advantage is maximized in workloads characterized by structured scaffolding, deterministic language segments, and advisory outputs subject to human oversight.”

Enterprises, Gogia said, should view the technique as a calibrated efficiency lever rather than a universal acceleration switch.

Snowflake has extended support for Cortex Code CLI, its terminal-based AI coding agent, to dbt and Apache Airflow to help data practitioners streamline engineering workflows.

“With this extended support, developers unlock secure, context-aware AI assistance within their preferred data engineering systems — empowering teams to work with data wherever it lives, and build, manage, and optimize production-grade workflows more efficiently,” the company said in a statement.

Apache Airflow and dbt are widely used building blocks of enterprise data stacks. While dbt provides a SQL-based framework for transforming raw warehouse data into analytics-ready models with testing and version control, Airflow orchestrates and schedules complex data pipelines across systems.

Avoiding context switching for developers

The development could be a big boon for data practitioners and developers.

“These (dbt and Airflow) are the control planes of modern data stacks. Embedding AI assistance directly into transformation and orchestration layers reduces friction, speeds development, and improves governance,” said Phil Fersht, CEO of HFS Research.

Explaining further how Cortex Code CLI’s integration reduces friction and accelerates development, HyperFRAME Research’s leader of the AI stack, Stephanie Walter, pointed out that developers can now avoid context switching.

Before the integration, developers could access Cortex Code CLI through tools like VS Code and Cursor, but the AI-assistance remained “essentially Snowflake‑centric”, offering little awareness of how dbt models or Airflow DAGs were structured, Walter said.

This meant that developers and data practitioners had to generate code in one environment, copy it over to dbt or Airflow, and then manually rework it to fit the transformation or orchestration logic they were maintaining, Walter noted, adding that this was an inefficient, fragmented workflow that kept AI assistance disconnected from real production pipelines.

Snowflake to own the developer experience

The integration could be seen as a strategic move by Snowflake to own the developer experience around data workflows and not just the warehouse.

“Snowflake wants to be the intelligence layer across the modern data stack, even when components sit outside its core platform. The endgame is platform gravity. If developers rely on Cortex to build and maintain pipelines, Snowflake increases its strategic control over data logic, governance, and AI enablement, regardless of where raw data physically resides,” Fersht said.

As a result, Fersht added, the move should intensify competition around the AI-native data stack: “Databricks has long positioned itself around openness and lakehouse flexibility. Snowflake moving Cortex Code CLI into dbt and Airflow narrows that differentiation by signaling it can operate across heterogeneous environments.”

Snowflake has also introduced a subscription plan for Cortex Code CLI to allow customers who don’t already have a Snowflake workload to try the AI coding agent across their data workflows.

Details of the subscription plan are yet to be disclosed by the cloud data warehouse provider.

Standardizing on a single cloud infrastructure is much easier than pursuing a multicloud strategy. In a single-cloud environment, IT leaders can optimize skill sets, centralize data more easily, secure infrastructure with fewer tools, and gain many other operational benefits. Yet 89% of enterprises report they are pivoting to multicloud adoption. Reasons for choosing to operate across multiple clouds include mitigating risk, reducing service interruptions, and avoiding vendor lock-in.

Vendors have responded to multicloud complexities with “single pane of glass” tools that operate across cloud providers. For example, AIOps platforms can centralize observability and data monitoring, while many data security posture management (DSPM) platforms are multicloud. Establishing platform engineering practices, shifting finops left as a key architecture practice, and automating CI/CD deployments are three ways devops teams can reduce overhead in managing multiple clouds.

Generative AI tools, including AI copilots and AI agents, are also becoming invaluable. World-class IT departments are using genAI to write agile requirements, develop software, automate testing, and maintain documentation.

I asked IT leaders how they are using generative AI to increase efficiency and simplify complexity management in multicloud architectures.

1. Evaluate cloud service and code portability

Architects have the difficult job of understanding tradeoffs between proprietary cloud services and cross-cloud platforms. For example, should developers use AWS Glue, Azure Data Factory, or Google Cloud Data Fusion to develop data pipelines on the respective platforms, or should they adopt a data integration platform that works across clouds?

Generative AI opens the door to a third option for code creation and translation. Consider a developer writing code to extract, transform, and load (ETL) for one cloud during development, then transitioning to another cloud provider if the architecture changes.

“Managing multicloud is like learning multiple languages from AWS, Azure, Oracle, and others, and it’s rare to have teams that can traverse these environments fluidly and effectively. Plus, services and concepts are not portable among clouds, especially in cloud-native PaaS services that go beyond IaaS,” says Harshit Omar, co-founder and CTO at FluidCloud.

One way to work around this issue is to assign an AI agent to support the developer or architect in evaluating platform selections. This AI agent would review standards, decision criteria, and requirements to recommend solutions and articulate tradeoffs.

“GenAI can help by acting like a devops copilot that understands the user’s intent and design preferences, whether the goal is to optimize for cost, performance, or security, and automatically generates the right infrastructure patterns, says Omar. “Teams spend less time hunting around for multicloud linguists and more time executing on the infrastructure updates and optimizing workloads for the best environments for their business.”

Recommendation: Porting across clouds will be a more realistic option for straightforward configurations and implementations. Using cloud architecture agents and code translation AI tools can help with multicloud portability.

Also see: How to excel in multicloud: The new checklist.

2. Shift from coding to improving resiliency

Developing APIs, applications, and data pipelines is getting easier with genAI tools. According to The 2025 State of AI Code Quality report, 82% of developers use AI coding tools daily or weekly, and 70% report improved code quality. Whereas automation helped IT shift left efforts to focus on customer experience and improving data quality, code generators could help them shift right to improve operational resiliency.

“GenAI is creating a new skill set in which knowledge workers learn to code through prompts and specs, while AI handles cloud-specific mechanics,” says Ed Frederici, CTO of Appfire. “In the future, the true measure of success won’t just be cost savings, but also resilient systems, stronger governance, and empowered teams that understand AI as their toolset rather than the quirks of every cloud, helping them work with greater confidence and impact.”

Recommendation: GenAI can improve resiliency by translating governance policies into cloud-specific implementations.

3. Create multicloud configurations from standard requirements

Standardizing infrastructure and service configurations across different clouds requires expertise in different naming conventions, architecture, tools, APIs, and other paradigms. Look for genAI tools to act as a translator to streamline configurations, especially for organizations that can templatize their requirements.

Jed Dougherty, head of AI architecture at Dataiku, says managing multiple clouds can be an exercise in frustration because each cloud has its own approach to security, access, pricing, and services. Dougherty expects genAI will simplify the translation process: “Imagine genAI automatically translating a complicated AWS IAM role into an Azure Role Definition, or an AWS CloudFormation template into a Google Deployment Manager Configuration.”

Recommendation: Look for genAI tools to build automations and cloud configurations from a single set of requirements, translated into cloud-specific implementations.

4. Simplify operations and automation

CI/CD, infrastructure-as-code, and process automation are key tools for driving efficiency, especially when tasks span multiple cloud environments. Many of these tools use basic flows and rules to streamline tasks or orchestrate operations, which can create boundary cases that cause process-blocking errors. Adding genAI to these automations can enable more robust automations and expand their applicability.

“Managing multicloud environments has traditionally been complex, requiring multiple tools for orchestration, compliance, and cost control, says Mehdi Goodarzi, SVP and global head of AI at Hexaware. “GenAI is now changing this by introducing automation, contextual insights, and intelligent governance into the ecosystem. It simplifies visibility, proactively addresses performance and security issues, and seamlessly orchestrates workloads across providers. Together, this evolution transforms multicloud from a resource-intensive necessity into a powerful enabler of agility, resilience, and business growth.”

Recommendation: Look for genAI capabilities that provide recommended actions in their flows and error handling. Devops can then generate risk and accuracy scores to help decide which actions to automate and which require human intervention.

5. Improve problem resolution with genAI observability

Site reliability engineers (SREs) are expected to perform during outages or performance issues, but they prefer reviewing system performance and proactively recommending improvements to developers before issues arise. Improving application observability has helped SREs, but it’s also created data management challenges.

“Multicloud chaos is fundamentally a data problem, and genAI’s edge is building a unified semantic layer over configs, logs, schemas, and lineage,” says Tobie Morgan Hitchcock, co-founder and CEO of SurrealDB. “Natural-language SRE copilots will infer topology, data gravity, compliance, and cost to propose placements, generate runbooks, and continuously remediate drift across clouds.”

Inconsistent and unstandardized observability data can lead to false alarms and misdiagnosis. But going back to development teams to adhere to data standards and naming conventions has a cost.

“Today’s multicloud operations overwhelm teams with noisy, disconnected alerts that bury the real issues,” says Kyle Campos, CPTO of CloudBolt. “GenAI changes that by interpreting complex, cross-cloud telemetry and surfacing only high-value incidents and optimization opportunities with meaningful context. Results include less alert fatigue, faster resolution, and a measurable boost in day-two operations impact—a critical step in how enterprises build, manage, and continuously optimize across clouds.”

Recommendation: SREs should dedicate time to testing AI agents and other genAI capabilities that simplify and accelerate the use of observability data to improve application performance.

6. Reduce the gap between policy and compliance

Each cloud provider has its own tools for implementing policies and reviewing compliance. When these policies are updated, the security and operations teams must update their implementations one by one, which is inefficient.

“Enterprises stitch together three divergent stacks from AWS, Azure, and GCP, resulting in rising operational complexity, brittle cross-cloud integrations, and cost drag driven by data gravity, egress, and persistent skills shortages,” says Pranay Ahlawat, chief technology and AI officer at Commvault. “GenAI can auto-generate portable IaC/policy to translate intent into native controls and remediate drift across clouds, which can improve compliance and cost posture.”

Recommendation: Regulated businesses will need compliance and security tools that enable the implementation of policies once, then deploy and report across cloud capabilities. Look for genAI capabilities in these tools to support reporting and configuration.

7. Enable continuous finops monitoring

Cloud cost reports with recommendations are available natively in each cloud provider’s reporting tools and in dedicated finops tools that aggregate the relevant data. Organizations with significant variable costs, especially as they scale AI programs, need more than reports to continuously optimize costs and workloads.

“Traditionally, organizations struggle to monitor, provision, and optimize workloads across multiple clouds, as they juggle different APIs, tools, and costs,” says Kevin Cochrane, CMO of Vultr. “GenAI simplifies this by providing intelligent recommendations, predictive scaling, and automated policy enforcement across environments. This reduces operational overhead, minimizes misconfigurations, and ensures workloads run efficiently and cost-effectively, allowing teams to focus on AI innovation rather than managing complexity.”

Recommendation: Smaller organizations should assign the responsibility for reviewing cloud costs to tools such as Azure Advisor, Google Cloud Recommender, and AWS Cost Explorer. Larger organizations should review the genAI capabilities in finops tools designed for financial and engineering end-users.

Can genAI fully address multicloud complexities?

GenAI is currently being embedded across development and operational tools, but it’s not a silver bullet. Regarding multicloud, Ahlawat from Comvault says genAI doesn’t eliminate structural constraints such as data gravity, latency, commitments, or the talent gap. “Organizations still need strong guardrails and platform engineering to manage overall operational complexity,” he says.

We can also expect public clouds to release additional differentiating capabilities, so even as tools powered by genAI simplify today’s challenges, new ones will emerge.