We’re seeing an interesting infrastructure tug of war today where GPU clouds are being pulled in two directions. For the economics of AI to work, the enterprise market needs to carve expensive hardware into smaller, shareable units and hand it to customers on demand, similar to how CPUs are doled in public cloud infrastructure. But the more the providers push GPUs to behave like elastic cloud infrastructure, the more they run into the reality that this GPU hardware was never built for safe multitenant use, fast fault recovery, or clean isolation between workloads. That tension is becoming one of the defining operational problems of the AI infrastructure market.
When a gamer launches Steam or the Epic Games Store on their laptop, they don’t have to worry about which GPU is being scheduled, how memory is going to be divided, or really any of the security boundaries or hardware assignment issues on their PC. For consumer PCs, these issues are not just hidden from view, they are irrelevant.
But for today’s IT teams managing GPU-driven AI workloads across distributed systems, those types of allocations and partitions need to be managed manually and carefully. This includes deciding which GPU to assign to each workload, how to divide memory, how to isolate tasks, and how to maximize utilization of this very expensive hardware. That’s why you heard so much about “Day 2” AI infrastructure themes around Nvidia’s GTC event this year.
GPUs were originally developed to speed up graphic rendering and to perform local compute via shaders in service of graphical rendering. Their design assumes a trusted computing environment in which a single application controls the device. When a user runs an application on a GPU, it accelerates that particular workload.
But while GPUs are optimized for throughput, and therefore have thousands of simple cores designed to execute the same instruction over large datasets, this design paradigm creates several major technical limitations regarding context switching and memory isolation. GPUs were designed to produce pixels, not to run sensitive AI applications from multiple tenants using the same hardware.
As a result, GPU infrastructure today behaves less like elastic cloud infrastructure and more like carefully managed hardware appliances.
Today’s AI infrastructure requires GPUs to behave like shared, elastic cloud resources. As inference workloads begin to outstrip large-scale training runs, the ability to slice and share expensive hardware among multiple tenants in real time while maintaining acceptable fault tolerance is no longer optional.
Hardware vendors have introduced new approaches to dividing GPUs into multiple isolated compute slices. Other frameworks approach partitioning through schedulers and container runtimes. But resource partitioning is just one slice of the overall GPU operations pie.
There is currently no widely adopted, cross-vendor operating model for achieving this safely at scale. Most providers are faced with either dedicating a single customer to a physical machine (thus wasting available capacity), or accepting the multi-tenancy security risks currently without a known solution. The current engineering challenge has moved from beneath the model layer and into the infrastructure layer. Success now relies on the ability to quickly launch new workloads and to rapidly contain hardware faults so that a single GPU failure does not bring down all workloads running on the server.
The vast majority of current GPU programming models rely on the idea that the driver has complete control over memory protection and that no user will act maliciously. Unfortunately, that assumption completely falls apart in a cloud environment where one VM or container can leave behind data remnants in memory that another VM or container may access. Especially considering that how GPUs execute code is often completely opaque.
A single faulty workload or a single faulty driver failure in a shared GPU environment can also take down every workload (job) that was being run on the same server, increasing the amount of damage caused by an operational failure.
Currently, there are immature options for runtime inspection or behavioral auditing, limiting both visibility and control for security teams. GPU drivers provide a large attack surface and generally limited telemetry from the hardware. In these shared environments, embeddings, weights, prompts, and tokens are now all sensitive data points, creating significant blind spots for those attempting to protect intellectual property.
The real constraint in many GPU clouds is not model performance but operational efficiency. Right now GPU operations looks like 30 minute tenant spin-up times, 70% idle rates, and engineers continuously debugging infrastructure stacks. Today’s GPU clouds are stalled not due to inferior models, but because the infrastructure layer underpinning these clouds was never designed to support such a high degree of scale.
A 30 minute cold start is a fundamental limitation on the modern AI business model. Those GPU clouds that can spin up workloads in seconds will ultimately win against those that do not. Multitenancy is the only viable means of producing sufficient unit economics to make this very expensive hardware viable for the long term.
Platform teams are beginning to recognize that GPUs require a specialized operating layer between the hardware and workloads. Operators need a unified operating model that supports multiple hardware vendors and GPU models. Cloud providers need a method to safely slice and share servers among tenants, and to prevent cascading failures, while rapidly launching new workloads.
Enterprises are increasingly seeking to run sensitive AI applications with stronger isolation guarantees, and thus are turning to newer categories of software designed specifically to manage the “dirty work” of hardware orchestration.
Prior to Kubernetes standardizing container orchestration, the industry was constantly debating the efficiency of container scheduling and bin packing across clusters. Those operational concerns were eventually automated and incorporated into infrastructure layers that made the complexities invisible to the end user.
A similar evolution is occurring around GPUs today. While platform teams continue to argue over placement strategies and memory tuning, these decisions will likely be automated within five to 10 years. As AI infrastructure evolves, the most valuable layer may not be the GPUs themselves but the operating layers that make them secure, elastic, and efficiently sharable. So the winners in the AI race won’t necessarily be just those with the most silicon, but those who have the best operating models for making that silicon secure and elastic.
—
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.
Enterprises are moving aggressively into generative AI. On the surface, that seems like the right call. The technology is powerful, accessible, and increasingly embedded in how businesses build applications, automate processes, and support decision-making. A development team can connect an application to a large language model in days. A product team can add AI features in weeks. Business leaders see quick wins, faster innovation, and a path to modernizing nearly every part of the company.
These are the upsides everyone is talking about. The part we don’t discuss enough is the economic trap forming underneath all this convenience.
Most enterprises think of tokens as a technical billing detail. They are not. Tokens are the unit of economic dependency in generative AI. Every prompt, response, summarization, retrieval step, workflow action, and agent decision is measured and monetized through tokens. Tokens are not just part of the plumbing. They are the tollbooth between your enterprise and a provider’s intelligence platform. The more AI becomes central to your operations, the more power that tollbooth holds over your future costs.
A token is usually described as a chunk of text processed by a model. That is accurate enough for developers, but it misses the bigger issue for CIOs, architects, and corporate boards. In the enterprise, tokens are the mechanism by which AI capabilities are rented. They are the meter attached to the intelligence itself.
That distinction matters because token usage grows faster than most companies anticipate. A simple user prompt rarely remains simple in production systems. It can trigger retrieval from internal knowledge stores, multiple model calls, tool use, post-processing, policy checks, and agent loops. What appears to be a single transaction to the user may involve several layers of token consumption behind the scenes. As a result, enterprises often underestimate the true operating cost of AI-enabled systems, especially as those systems mature and spread across departments.
Today, those costs still feel manageable. In many cases, they feel surprisingly low. That is exactly why the trap is so dangerous.
Current token pricing is giving enterprises a false sense of comfort. Many remote LLM providers are aggressively competing for market share. They want developers building on their APIs. They want enterprise applications tightly coupled to their platforms. They want AI agents, copilots, workflows, and customer experiences to depend on their models. To make that happen, pricing remains highly attractive relative to the value delivered.
That does not mean the economics of generative AI are stable. It means the market is still being shaped by investor capital, strategic pricing, and growth expectations. Providers are racing to establish position, and enterprises are benefiting from that race. But no market stays in that phase forever. At some point, investors will expect durable profitability. At some point, weaker providers will disappear, consolidate, or retreat. At some point, the survivors will have more leverage and much less reason to price primarily for adoption.
That’s when the token trap closes.
Enterprises that build deep dependence on remote models during the subsidy phase may find that what seemed inexpensive at pilot scale becomes punishing at enterprise scale. The application that costs $1,000 per month today may cost 10 or 20 times that amount a few years from now, not only because usage has increased, but also because the market has repriced the dependency.
Cloud computing followed a similar path, with many enterprises mistaking short-term convenience for long-term economics. In the early years, the case was compelling and largely accurate. Move faster, reduce friction, avoid capital spending, and scale with ease. Those benefits were real. Many organizations made architectural decisions that prioritized speed over leverage. They became dependent on managed services, provider-specific tools, and operating models that were easy to adopt but expensive to unwind.
Years later, many enterprises discovered that their cloud bills were much higher than expected and their exit options much narrower than advertised. That was not because the cloud failed. Architectural dependency eventually became financial dependency.
Generative AI is repeating that pattern, only faster. The integration barrier is lower, the pressure to adopt is higher, and the pace of enterprise experimentation is far greater. As a result, companies are wiring remote LLMs into applications, workflows, and agentic systems with very little thought about how these costs will behave in the next five to 10 years.
The more enterprises move from simple prompt-response systems to agentic architectures, the more dangerous the token trap becomes. Agents are not single-call systems. They plan, deliberate, retrieve information, invoke tools, evaluate results, retry steps, and often coordinate with other agents. Each of those actions consumes tokens. Costs no longer rise in a neat linear fashion. They compound.
This matters because agentic AI is increasingly being presented as the future of enterprise automation. It’s true in many cases. But if an enterprise builds agentic systems primarily on remotely hosted intelligence, it is also building future business processes on top of someone else’s pricing model. That is a major strategic risk. The more successful those systems become, the harder they are to replace. The harder they are to replace, the more pricing power shifts to the provider.
This is how businesses end up operationally dependent on a cost structure they do not control.
The answer is not to reject public models or pretend that external providers play no role. They clearly do. There will always be cases where renting frontier AI capabilities makes sense. But enterprises need to stop assuming that renting is the default for every workload.
AI sovereignty is the alternative that deserves much more attention. That means building, tuning, deploying, and governing models inside the enterprise for use cases where long-term control matters more than access to the absolute frontier. Enterprises need to recognize that most business applications do not need a world-class general-purpose model. They need a model that is good enough for a specific purpose, aligned to the enterprise’s data, governed by the enterprise’s rules, and operated at a predictable cost.
It’s a very different way of thinking.
A self-hosted or enterprise-controlled model may not match the rich feature set of the largest public offerings. It may lack the same breadth, polish, or marketing appeal. But for many internal business tasks, those factors do not matter.
Here’s the most critical question to guide your architectural direction: Can a sovereign AI model solve the problem reliably, securely, and economically over time? If the answer is yes, owning that capability may be far more strategic than forever renting something with more power than you need. In effect, the enterprise becomes its own provider for the workloads that matter most.
Too many companies still treat generative AI architecture as a tactical IT issue. It is not. These decisions directly affect cost structure, operating flexibility, data control, and long-term competitiveness. If AI becomes a force multiplier across the business, the economics of AI become strategic to the business itself.
The companies that get this right will not necessarily be the fastest adopters. They will understand the difference between experimentation and dependency. They will use external models when it makes sense, but they will also invest in sovereign capabilities where ownership matters. They will think like architects, not consumers.
Here’s the takeaway: Cheap tokens come with strings. They are a gateway to a dependency model that will typically look very different once providers stop pricing for growth and start pricing for leverage. Enterprises cannot keep mistaking today’s bargain for tomorrow’s reality. Boards and executive teams need to act now to get ahead of this issue. The key question is not whether generative AI creates value. It clearly does. The real question is whether the enterprise can still afford and control the value it creates once the market matures.
The European Commission published its tech sovereignty package last week, including the clearest signal yet of its intention to strengthen European cloud sovereignty and reduce its dependence on US hyperscalers.
It’s a response to growing concerns among European organizations and regulators about the reliance on US tech firms and legislation such as the US CLOUD Act, which could give US officials access to data — even if it is stored in Europe.
But any shift toward local, sovereign cloud providers will necessarily be gradual, analysts, said as the Cloud and AI Development Act (CADA) proposals leave plenty of room for US providers to continue supplying cloud computing services to European public sector customers.
“The direction is right. The execution will be slow,” said Fernando Pereiro, senior director analyst at Gartner.
While the Commission has correctly identified areas where the EU is most dependent on foreign providers, delivering on its ambitions is another challenge, he said. Scaling alternatives to US suppliers “takes time, capital, and coordination at a level that is difficult to sustain in Europe.”
Dario Maisto, senior analyst at Forrester, played down the prospect of a major short-term shift towards European cloud providers as a result of the CADA proposals, even after recent interest in local European vendors for mission-critical workloads and highly sensitive data.
“I do not expect an immediate impact on the cloud infrastructure market,” Maisto said. “Full-blown migrations are costly and take several years. They are not going to happen in the near future.”
Instead, Pereiro expects the gradual emergence of “sovereign enclaves” or controlled environments for sensitive workloads, particularly in government and regulated sectors. “Outside of those areas, the market will remain global, but increasingly shaped by European rules,” he said.
Nevertheless, the three US hyperscalers that account for around 70% of the European cloud market – Amazon Web Services (AWS), Google, and Microsoft — will likely see a more competitive environment.
“The real shift is symbolic and structural: hyperscalers move from being the default choice to one option among others, and their competitiveness will increasingly depend on how well they align with European control requirements, not just on technology or price,” said Pereiro.
CADA is part of a range of policy and legislative proposals — known as the Tech Sovereignty Package — published by the Commission, alongside Chips Act 2.0, the Open Source Strategy, and Strategic Roadmap for Digitalization and AI in Energy.
CADA includes measures to boost European tech sovereignty. Among other things, it aims to triple data center capacity in the next five to seven years by easing restrictions on new infrastructure projects across the EU, as well as efforts to support research and development of cloud and AI technologies.
It also includes a sovereignty framework that, if enacted, would require EU public bodies to assess sovereignty risks and procure cloud services that meet four assurance levels.
The various levels portray “a political vision with many open questions,” said Maisto. In more detail:
The first two levels could be open to US hyperscalers, said Maisto, with 70% of existing EU public sector workloads falling under Level 1 and 20% at Level 2, according to Commission’s own impact assessment. Just 9% of the workloads would require Level 3.
The most stringent Level 4 would require cloud providers that “have full transparency and control over their software supply chain and no interference from a third country,” the Commission said.
For public sector organizations, the CADA rules could create more clarity around procurement, said Pereiro. “Today, the concept of ‘sovereign cloud’ is often vague and inconsistently applied in providers’ marketing and messaging,” he said. “This package standardizes what sovereignty must look like in practice, effectively ending the era of ‘sovereign washing.’”
The proposals give public sector organizations a “stronger set of requirements with which to assess risk, especially around jurisdiction and access to data,” he said.
“For enterprises, it’s less about regulation and more about leverage,” said Pereiro. “They gain clearer benchmarks and more viable alternatives, particularly through open source and emerging European providers.”
The Cloud Infrastructure Services Providers in Europe (CISPE) — a nonprofit trade group — welcomed the “strong definitions” of Levels 3 and 4, and said that, if implemented well, the proposed rules could “help to challenge the commercial dominance of established foreign cloud and AI vendors.”
However CISPE also called the current Level 1 and 2 criteria “confusing and non-sensical,” and said they should not be designated as “sovereign” since US hyperscalers can meet the requirements. “This will continue to confuse the market, both public and private customers, and encourage more sovereignty washing attempts,” CISPE said in a blog post Thursday.
CISPE also said the proposals fail to require public authorities to check whether a European service exists before opting for a foreign supplier. “We see a significant risk that assessments become a ‘rubber-stamp’ exercise that allow IT departments to continue to buy non-sovereign services out of convenience,” the organization said.
French firm OVHcloud — one of the leading European cloud computing and web hosting companies — welcomed the proposals, though it said any rules must be carefully scoped to ensure they are effective.
“This text is a step in the right direction and represents an opportunity to strengthen European strategic autonomy — something unthinkable just a few years ago,” an OVHcloud spokesperson said. “It provides a useful framework, but one that must not leave too much room for exceptions and workarounds.
“Europe must and can move much faster, with very clear rules and a genuine European preference. Beyond this text, the Commission has demonstrated with its sovereign procurement call that it is possible to act right now to reduce critical dependencies. The time for waiting is over. We must accelerate. We must clarify. We must own it.
“Europe has the players and the expertise,” the spokesperson said. “It is time to turn political ambition into European industrial capability.”
The overall tech sovereignty package “marks the overdue shift from diagnosis to treatment,” said a spokesperson at Ionos, a German cloud and hosting company. Ionos pointed to the EC’s claims that more than 80% of digital products, services and infrastructures in the EU originate from non-European providers, while 264 billion euros flow from EU organizations into predominantly US-based IT products.
“This is a strategic failure that must now be corrected,” the spokesperson said. While the company applauded the Commission’s focus on “secure and sovereign cloud and AI infrastructure for highly critical use cases,” it argued the CADA proposals fall short. “The central weakness of the package: the approach remains predominantly supply-side. The decisive lever — the demand side – is missing. Public procurement is the most powerful instrument for digital sovereignty. The public sector as anchor customer is critical for scaling sovereign cloud and AI solutions.
“Europe will remain dependent on Nvidia and AMD for GPU computing, the spokesperson said. “What matters is not whether to cooperate, but on what terms: data under European law, operations by European providers, no extraterritorial access. …If EU funding earmarked for ‘sovereign cloud’ ends up with the European subsidiaries of US hyperscalers, the package will have failed its objective.”
The proposed rules could require hyperscalers to change tactics to cater to European customers, or to at least ramp up existing sovereign cloud strategies. “For vendors, this is essentially a shift in what ‘competitive’ means,” said Pereiro. “For the last decade, scale and hyperscaler alignment were enough. That’s no longer the case.”
Cloud providers will need to demonstrate real control over data, infrastructure, and operations, he said, and not just label solutions as “sovereign.”
“The bar has been raised, and some existing offerings simply won’t clear it,” he said.
While the CADA rules are designed to favor European providers in some cases, the proposals stop short of barring US providers from public sector contracts. “It doesn’t shut them out,” said Pereiro, “but it changes competitive conditions substantially.”
The proposed procurement requirements make sovereignty a “gating factor” for sensitive workloads, said Pereiro, and “create real friction for providers whose operating models depend on centralized control or non-EU jurisdiction.”
US hyperscalers publicly welcomed the proposals, and indicated plans to work with policy makers and ensure the importance of customer choice in cloud service procurement.
“We look forward to reviewing the proposed rules and continuing to work alongside our partners to ensure European organizations have the power of choice and sovereign control,” a Google spokesperson said.
An AWS spokesperson said the company has invested ”tens of billions of euros” in European cloud infrastructure, which it claims has “already advanced the continent’s competitiveness, helped organizations innovate and grow, and supported the development and resilience of both public and private services that Europeans now rely on every day.
“European organizations deserve access to the best technology available from trusted providers, chosen on the basis of security, performance, verifiable controls, and value,” the AWS spokesperson said. “We look forward to working with policymakers to ensure the Cloud and AI Development Act promotes technology choice and rewards long-term investment in Europe’s digital future.”
A Microsoft spokesperson said the company shares the EU’s “ambition to strengthen technological sovereignty and global competitiveness in AI, grounded in openness, partnership and fair competition.
“Achieving this will depend on access to world-class infrastructure and technologies at scale,” the Microsoft spokesperson said. “That means enabling European companies and public administrations to make procurement choices based on a broad, risk-based assessment in an open and competitive market.
“Microsoft offers secure and sovereign cloud solutions that put customers in control, and we stand ready to help build a strong, resilient and globally connected AI ecosystem in Europe.”
While the proposals present potential hurdles for US hyperscalers, those that adapt to the new regulatory direction — and concerns of European organizations — will benefit, said Pereiro. “If your offering aligns with sovereignty requirements, your company will be likely to see more opportunities, not fewer,” he said.
Model Context Protocol (MCP) has gained considerable momentum as a standard connector between LLM-powered tools and local systems, internal and external APIs, and data sources. From major clouds to devops tools, MCP servers are enabling powerful, AI-powered development and operations capabilities through natural language commands.
Nowhere is this more true than in the world of databases. Most major database platforms now support agentic access through MCP servers. Using an MCP server for databases, you and your AI agent proxies can perform lookups, create and update data, and perform administrative tasks without you having to write SQL by hand.
The MCP server could also guide your LLMs to write new code or build automations that align with your database schema, like its tables, structure, and fields, as well as embeddings, indexes, and metadata. It could also aid debugging by enabling faster queries to surface data issues or misconfigurations, along with plenty of other possible use cases.
Below, we’ll cover official MCP servers from some of the top platform options across major database styles. Though maturity varies, the MCP servers discussed below represent some of the best vendor-backed offerings available today across relational SQL, NoSQL, graph, vector, and data warehouse systems.
These servers can be used by any MCP-compatible tool, IDE, or agent, whether it’s Claude Code, Codex, Cursor, Gemini CLI, Google Antigravity, VS Code, Windsurf, or something else. Adding them is typically simple, often involving a lightweight JSON addition to your MCP configuration file.
MySQL and PostgreSQL are the world’s most widely-used open source databases. However, in both cases, there is no canonical MCP server—what we see are different MCP servers emerging across vendors. One of these vendors is Amazon Web Services (AWS), which offers official MCP servers for Amazon Aurora, its managed relational database service compatible with both MySQL and PostgreSQL.
According to the documentation on GitHub, the Amazon Aurora MySQL MCP Server can be used to convert natural language commands into MySQL-compatible SQL queries, which can then be executed against Aurora MySQL databases. Similarly, the Aurora Postgres MCP Server provides MCP tools for working on PostgreSQL databases. The Aurora DSQL MCP Server does the same for distributed Postgres databases.
AWS provides a growing portfolio of official MCP servers across its product line, including MCP servers for other Amazon database platforms like DynamoDB, ElastiCache, and Redshift. If you’re a heavy AWS shop and you want to enable LLM interactions with your data, these are sensible choices.
BigQuery is Google’s cloud-based data analytics platform, and a popular data source for AI applications. BigQuery users with API access configured can also utilize the BigQuery MCP Server to interact with the platform using MCP-compatible AI clients.
Using the remote BigQuery MCP Server, engineers can generate and execute queries on data sources, or return metadata on datasets, tables, and schema. This can be done with a simple natural language prompt like “List the datasets in project PROJECT_ID.” Results are filterable by region, data set ID, column name, and more.
As part of Google’s fully-managed, remote-hosted MCP portfolio, the BigQuery MCP Server provides some peace of mind regarding security, maintenance, and ease of use for distributed teams. The MCP tools are subject to some limitations, however, in terms of query result size, processing time, and other factors. If you’re using BigQuery and you want more agentic control, you’ll want to check this one out.
Another important database category includes platforms designed for keyword and semantic search. In this space, Elasticsearch is commonly deployed. Instead of providing a single MCP server, Elasticsearch provides the Elastic Agent Builder, which is a more comprehensive framework aimed at agentic workflows.
Using Elastic Agent Builder, you can chat with an agent to retrieve data context from Elasticsearch data and extend it into various environments. The Agent Builder itself includes an MCP server endpoint for programmability and exposing the agent to other clients.
Unlike others on this list, this is not a direct MCP interface to raw Elasticsearch APIs. Instead, it’s an interface that exposes skills from the agent platform. This should also not be confused with the Elasticsearch MCP Server, released in mid-2025, which has since been deprecated.
A possible downside of using this utility is that it includes an additional layer between your IDE or agent and the data you’re searching. The agent setup requires a higher subscription and takes additional steps to configure compared to other MCP servers.
That said, if you want an extensible common layer to interact with both Elasticsearch and external MCP servers, while centralizing responsibilities like permissions, this is an interesting proposition.
Graph databases are another key NoSQL database type these days, specializing in using nodes and edges to accelerate queries of highly interconnected data. Of these, Neo4j is a popular graph database option.
The Official MCP Server for Neo4j works with all kinds of Neo4j deployment (desktop, sandbox, self-managed, and the managed Neo4j Aura cloud service), and allows LLM-based clients to retrieve graph schema, execute read and write statements, execute graph algorithms, and more.
In addition, several other MCP servers for Neo4j are available from Neo4j Labs. These have specialized uses, such as generating Cypher queries from natural language, maintaining an in-memory graph database, modeling and visualizing graph, and interacting with the Neo4j Aura API.
The first MCP server for Neo4j was developed in December 2024. If you’re an avid Neo4j user and want to experiment with interacting with your graph databases in a chat-infused way, these stand as an interesting platform of servers.
Google’s MCP Toolbox for Databases is a notable MCP server because it’s a popular catch-all for various database types. Unlike the other entries on this list, this server connects LLMs not to a single managed database, but unifies LLM access to multiple systems. The open source utility ships with pre-built configurations for nearly 30 databases including PostgreSQL, MySQL, SQL Server, Oracle Database, MongoDB, Redis, Neo4j, and Snowflake, as well as the databases in Google Cloud.
Once you define data sources in a tools.yaml file, you can use MCP Toolbox to perform structured queries or semantic searches against databases directly from within an IDE or agentic client using plain English. MCP tools translate commands into actions like list_tables and execute_sql.
MCP Toolbox for Databases is mature, originally built as a generative AI utility and later re-worked for MCP-style workflows. It offers numerous download, configuration, and interaction methods.
If you’re using a variety of databases on Google Cloud and elsewhere and you want an “all-in-one” MCP server, MCP Toolbox for Databases is a great place to start.
MongoDB is the popular NoSQL document-oriented database. The creators of MongoDB have released an official MCP server that works with the open-source database as well as the company’s cloud-hosted MongoDB Atlas database platform.
The MongoDB MCP Server provides a number of tools to interact with MongoDB. You can query the database, return information on collections, create or remove collections or indexes, gather statistics on database usage, and more. Other tools enable MongoDB Atlas operations, like creating users or clusters, returning cluster data, and other functions.
The server’s tools are read-only by default but can be switched to allow write capabilities. It can be used locally, but also supports Streamable HTTP transport for remote servers, although that comes with greater security concerns.
For those using MongoDB and wanting to hook their AI-enabled IDE or CLI up with more automated powers, the official MongoDB MCP Server is worth checking out.
Among vector-native databases, Pinecone stands as a strong, widely used option with a well-designed API and comprehensive SDKs. The Pinecone MCP server extends this experience, allowing users to query its documentation and execute functionality via AI agents and AI-enabled IDEs.
To date, the Pinecone MCP server consists of nine MCP tools. These cover read-only actions, like knowledge gathering via the Pinecone official documentation and querying vector records, index metadata, configurations, and statistics. It also allows for write operations like updating records and creating new indexes.
Released in mid-2025, the Pinecone MCP server is one of the more complete early implementations, with easy configuration and installation.
For those using Pinecone who want to test new LLM-assisted workflows for creating indexes with embeddings, performing reranking, or testing results using natural language commands, the Pinecone MCP server is worth trying out.
An ultra-fast in-memory database, Redis is commonly used for caching, real-time analytics, and other latency-sensitive use cases. And as you might have guessed, the company behind the Redis database provides an official MCP server. The server allows read, query, and write capabilities.
Developers can use Redis MCP from an LLM client to perform high-level actions to analyze, reference, or embed Redis data and interact with the Redis server within their prompts. The documentation suggests some example prompts for common use cases, such as “Cache this item,” “How many keys does my database have?,” and “What is user:1’s email?”
Unlike other MCP servers, which only allow a slice of platform capabilities, Redis MCP offers full Redis support. This enables working with Redis constructs such as hashes, lists, sets, sorted sets, streams, and more, according to the GitHub repository.
One possible drawback is that Redis MCP has yet to support Streamable HTTP transport. Until this is developed, the server is constrained to local deployment. But for those seeking a local MCP server to work with Redis data, this is the best choice.
Snowflake is a cloud-hosted, AI-enabled data platform widely used in enterprise contexts for data warehousing, data analytics, and data engineering purposes. Compared to other data storage systems, Snowflake is unique in that it’s more fully managed and combines structured and non-structured data types.
The Snowflake MCP Server, available on GitHub, can be used to perform many of the standard Snowflake platform operations. This includes a “fuzzy” search of all records via Snowflake’s Cortex Search and structured data semantic lookups using Cortex Analyst.
Other abilities include object management operations like creating, updating, and deleting records. The server also can invoke other agentic-designed capabilities, like the ability to generate and execute SQL statements against back-end databases.
Snowflake MCP Server is well-thought-out and well-documented, with walkthroughs for various agent and deployment patterns. Those already building with Snowflake should find it complements the mechanics they already employ.
A longtime open-source favorite, PostgreSQL is one of the most popular and trusted object-relational SQL-based database systems. With an active open source community, Postgres has been maturing for decades. Given its open source nature, there isn’t a single “official” MCP server for the platform. Anthropic built an original reference implementation, but it’s now archived.
Instead, database platforms built on PostgreSQL provide different flavors of MCP servers, with a range of vendor neutrality and specificity. One notable option is the Supabase MCP Server, provided by Supabase, a cloud-based “back end as a service” and Postgres development platform.
Supabase MCP Server connects AI agents with Supabase projects, allowing engineers to issue natural language commands to manage tables, query data, get logs, fetch configuration information, and more. The Supabase MCP Server is pre-1.0 release and some features are still experimental.
If you’re an engineer using Supabase and looking for an MCP server to connect your AI assistant with your Postgres databases, this is a good tool to test out.
So far, we’ve reviewed official, vendor-backed MCP servers from some of the most-adopted managed databases. However, numerous MCP servers exist across other database platforms and types.
One MCP server that aggregates LLM access across various database types is DBHub, which works with MySQL, PostgreSQL, SQL Server, MariaDB, and SQLite. Developed by Bytebase, DBHub is described as a zero-dependency, token-efficient MCP server.
For SQL, the options are nearly endless. Official servers exist for Microsoft Azure SQL and DuckDB. PulseMCP catalogs more than 100 MCP servers for MySQL, although most are unofficial, solo-creator open source projects. Of these, one of the most starred is MCP Server for MySQL, developed by full-stack developer Ben Borla and optimized for Claude Code.
For Postgres, notable alternatives to Supabase include pgEdge Postgres MCP, Neon MCP server, and Postgres MCP Pro. For vector databases, others beyond Pinecone have been quick to adopt MCP as well, including Weaviate and Milvus.
Before diving into MCP servers for enterprise databases, it’s important to understand the security risks. For instance, prompt injection remains an unsolved problem, so it’s recommended to limit permissions for SQL statements.
To mitigate this, Supabase recommends enabling AI client settings that require manual approval for each tool call before execution. Experts also recommend assigning only the minimum permissions required and avoiding exposure of sensitive data like API credentials. Due diligence around authentication and authorization is especially important when hosting remote servers.
Lastly, to avoid shadow IT, it’s becoming common practice to catalog the internal MCP servers you use, even for experimental projects. For this, experts recommend an MCP registry that documents approved servers. An MCP registry improves both MCP server discovery and security awareness.
Licensing can be complicated, particularly when enterprises are forced to double-pay because the software they already own is only licensed for a specific environment, and moving it requires a whole different licensing model. Without proper portability rights, they need to make additional financial investments to run the same workloads in a different home.
AWS says its new Bring Your Own Media (BYOM) service eliminates this duplication. Customers can now reuse their existing Microsoft SQL Server media and licenses on Amazon Relational Database Service (RDS) with no additional licensing fees.
This means enterprises no longer have to justify workload migrations to the cloud against existing licensing commitments and infrastructure investments, AWS said.
“What used to be a licensing barrier between operational SQL Server data and agentic AI is now gone,” AWS data engineer Srikanth Katakam and product marketing manager Colleen Betik wrote in a blog post announcing the service.
To drive true value, agentic AI apps must have access to elastic GPU capacity as well as direct, low-latency access to the data they need to reason and make decisions. But, AWS argued, that can be difficult in self-managed data centers and on premises infrastructure with limited access to agentic AI cloud-native services. But a lot of enterprise data lives in Microsoft SQL Server, and until now customers have had to pay for a second license to use a fully managed cloud service like RDS.
Now, with BYOM on Amazon RDS for SQL Server, enterprises can reuse their existing SQL Server Enterprise Edition or Standard Edition licenses through a “lift-and-shift” model. This brings their data into a fully-managed environment.
According to the licensing distribution terms, enterprises must provide their licensed SQL Server Release to Manufacturing (RTM) media to Amazon RDS. They can then upload that media to Amazon S3 and launch BYOM instances. Enterprises must configure AWS License Manager to perform automatic instance tracking.
From there, RDS automates patching, backups, high availability, and monitoring, while providing direct access to agentic AI and analytics services native to AWS. The platform also reports vCPU usage to provide visibility into SQL Server license usage, Katakam and Betik wrote.
“You do not need to choose between protecting your SQL Server licensing investments and giving your data a path to the AWS analytics and agentic AI services redefining what’s possible in the cloud,” they said.
It’s important to note that this service is only available to enterprises with Microsoft Software Assurance (SA), an add-on which supports mobility and rehosting of existing licenses. Enterprises must verify that their SQL Server licenses comply with Microsoft’s licensing agreement, and that they have a SQL Server License (Standard or Enterprise) with SA. They also must submit a License Mobility Verification Form to Microsoft; it, in turn, will notify AWS once verification is complete.
AWS emphasized that enterprises remain responsible for compliance; it does not block operations if license limits are exceeded.
The advantage of this service, explained Mike Leone, principal analyst at Moor Insights & Strategy, is that enterprises can get a Microsoft SQL Server workload onto a managed AWS service without rewriting it for Aurora or paying for the license twice. This means they can modernize on their own schedule rather than being forced into rewrites before they’re ready.
“For a lot of shops, that control over timing is worth more than the license saving itself,” Leone said.
This also loosens Microsoft’s grip on enterprise workloads, because organizations finally have somewhere else to run SQL Server using licenses they already own, he noted. Realistically, their dependency shifts to AWS rather than disappearing entirely, as their data ends up living next to AWS’s AI services.
“For a lot of teams, that’s a trade they’re glad to make for the managed infrastructure and the AI tooling they get in return,” Leone said.
Yaz Palanichamy, a senior advisory analyst at Info-Tech Research Group, also pointed to significant improvements stemming from the migration. Notably, it allows organizations to transition away from static, linear, or reactive storage capabilities towards more dynamically intelligent environments.
“The key is to balance the unification of transactional data towards managed AI and machine learning pipelines,” he said.
The catch? Leone noted that enterprises now own the task of licensing compliance. Staying current on SA, the Microsoft maintenance contract that makes any of this legal, and the license mobility rules, “become your headache instead of something baked into the bill,” he said.
Furthermore, he added, lift-and-shift has a way of turning into “lift-and-forget” when enterprises move SQL Server as-is and never actually modernize, “so you end up carrying all the old baggage onto a shinier platform.”
Palanichamy also pointed to skyrocketing AWS costs, since operationalizing AI agents requires a considerable amount of data ingestion and querying. This can potentially be cost prohibitive on RDS for SQL Server.
“One aspect to consider would be the relative time to production value, so that enterprises can better handle the management of volatile AI workloads,” he said.
Although AWS frames licensing complexity as a roadblock to agentic AI, analysts say it’s really just one piece of the puzzle.
Organizations are not in an AI-ready state due to a number of factors, Palanichamy noted. This could be total cost of ownership (TCO)-related, a lack of appropriate acceptable use policies (AUPs), or concerns around security and compliance.
If and when enterprises are ready to adopt AI, they must perform thorough needs analysis/process optimization benchmarking exercises to determine what workflows could benefit from the technology, he said, and, conversely, flag workflows where AI could prove “an impediment or potential disservice.”
Leone also pointed out that moving SQL Server onto RDS doesn’t “magically make your data agent-ready,” nor does it make it smarter. The data proximity and managed plumbing are what actually support agents. Sitting data next to Bedrock and the rest of AWS’s AI services means builders “stop wasting time shipping the data around or building one-off integrations every time an agent needs it.”
Ultimately, though, licensing isn’t the real issue when it comes to AI; it’s more of a migration problem. The real roadblocks are messy data, questionable governance, and teams that aren’t ready to run it in production, and, Leone said, “no change to a license bill touches a single one of them.”
Agentic AI has moved from conference hype to a budget line item. This is where the conversation gets more interesting and more uncomfortable. Unlike traditional AI systems that respond to a single prompt, classify a document, recommend an action, or generate a summary, agentic AI systems are designed to pursue goals. They plan, call tools, inspect results, retry failed steps, consult memory, hand off tasks to other agents, and sometimes critique their own work before producing an answer or taking an action.
That extra autonomy is the value proposition. It also introduces the cost problem.
A single chatbot interaction may consume a few thousand tokens. A useful agentic workflow can consume hundreds of thousands or millions of tokens per day because it does more than answer a question. It decomposes the problem, retrieves context, reasons through options, invokes APIs, checks the output, and often runs multiple passes before reaching a result. Therefore, the economics need to be understood at the level of “agent instances,” not just model calls.
For the estimates below, I am using a blended token cost of $3 dollars per million tokens. This is not intended to reflect a single vendor’s list price. It is a blended planning figure that assumes a mix of input and output tokens, reasoning steps, retrieval-augmented generation, summarization, tool calls, memory updates, and occasional use of larger context windows. Some enterprises will pay less through volume discounts or by routing work to smaller models. Others will pay more by using premium models, long-context prompts, web browsing, large document ingestion, and repeated reasoning loops.
The basic formula is straightforward. If an agent consumes 2 million tokens per day, it consumes 730 million tokens per year. At $3 per million tokens, that single agent costs about $2,190 per year in token burn. That number sounds surprisingly low until you multiply it by the number of agents, workflows, and users, plus the surrounding infrastructure required to run these systems safely.
In the model used here, the annual token-only cost per agent ranges from about $1,095 to $3,833, depending on the use case.
These figures are useful but incomplete. They include only LLM token consumption and exclude orchestration platforms, vector databases, observability, model evaluation, security controls, workflow monitoring, human review, enterprise application integration, data pipelines, audit logging, prompt management, and the engineers needed to build and maintain the systems. In real deployments, I would expect the all-in operating cost to be two to five times the raw token cost. For regulated or mission-critical environments, the multiplier can be even higher.
This is where many agentic AI business cases become less clear. The model call may be inexpensive, but the system around the model is not. An agent that can update a customer relationship management system, approve a refund, generate a purchase order, or recommend a security containment action needs guardrails, permissions, logging, rollback mechanisms, and human escalation paths. These are not optional features. They are the difference between a demo and an enterprise system.
Customer support is one of the more obvious use cases. A typical support automation deployment may use eight agents: an intake classifier, a knowledge retrieval agent, a response drafting agent, an escalation agent, a quality review agent, a CRM update agent, a sentiment detection agent, and an analytics agent. At two million tokens per agent per day, each agent costs about $2,190 per year in token burn, bringing the annual total to roughly $17,520. If that system deflects even a modest number of tickets or improves agent productivity, the economics can be attractive.
Sales development is another practical example. A five-agent system for account research, lead enrichment, email personalization, CRM updates, and follow-up scheduling may consume 1.2 million tokens per agent per day. That results in an annual cost of about $1,314 per agent, or $6,570 for the full agent team. This can be compelling if it improves pipeline quality, but it can also be wasteful if agents generate low-quality outreach at scale. The cost of brand damage is not measured in tokens.
Software engineering is more expensive but potentially more valuable. A 12-agent system covering requirements analysis, architecture, code generation, testing, review, security checks, documentation, CI debugging, refactoring, release notes, dependency analysis, and hot-fix support may consume 3.5 million tokens per agent per day. That works out to about $3,833 per agent annually or roughly $45,990 for the full system. Compared with engineering salaries, the token cost is small. The real question is whether the system reliably improves throughput without increasing defects, security vulnerabilities, or maintenance complexity.
Security operations also fit the agentic model because the work is repetitive, time-sensitive, and context-intensive. A 10-agent security triage system could include agents for alert triage, log analysis, threat intelligence, endpoint investigation, network investigation, incident summarization, ticketing, compliance evidence, escalation, and post-mortem. At 2.5 million tokens per agent per day, the annual token cost is about $2,738 per agent or $27,375 for the system. This is easy to justify if it reduces alert fatigue and accelerates response, but risky if the agents hallucinate causality or bury critical signals in confident summaries.
Finance, legal, healthcare administration, market research, HR, and supply chain are also viable:
Across all 10 example use cases I’ve mentioned in this section, the model assumes 71 agents and a total annual token burn of about $175,638.
The economics of agentic AI should always be compared with simpler approaches. Traditional AI, workflow automation, rule engines, robotic process automation, and non-agentic LLM calls are often cheaper, easier to govern, and more predictable. Agentic AI is usually overkill for tasks like classification, extraction, summarization, routing, or drafting within a narrow context. A deterministic workflow with a single model call can do the job at a fraction of the cost and risk.
Agentic systems make sense when the process requires judgment across multiple steps, dynamic planning, tool use, exception handling, and adaptation to incomplete information. They are valuable when the path to the answer cannot be fully scripted in advance. They are less valuable when enterprises use them as a trendy substitute for basic automation.
The best architecture is usually hybrid. Use traditional automation where the process is stable. Use non-agentic AI where the task is bounded. Use agentic AI only where autonomy creates measurable leverage. That means fewer agents, tighter scopes, explicit budgets, model routing, token monitoring, and human checkpoints for high-impact decisions.
The financial mistake many organizations will make is to treat agents as digital employees with near-zero marginal cost. They are not. They are probabilistic software components that consume tokens, trigger tools, create operational dependencies, and require supervision. The token bill may be manageable. The governance bill may not be.
Agentic AI can absolutely be worth the money. In many cases, the annual token burn for a useful agent team is less than the loaded cost of a single employee. But that is not the same as saying it is cheap. Companies must measure agent cost per completed business outcome, not cost per prompt or cost per model call. In the end, the question is not how much an agent costs. Ask yourself the right question: Does the autonomy an agent provides outweigh the complexity it introduces?
For the past two years, enterprises have focused on grounding AI systems in internal documents, databases and knowledge repositories. Microsoft now contends that the next challenge is giving those systems reliable access to the outside world as they move into production.
At its ongoing annual Build conference, Microsoft unveiled Web IQ, a new suite of AI-native APIs designed to connect AI agents and applications to real-time information from across the web, including web pages, news, images and videos.
The goal is to help developers build more accurate and context-aware AI systems while reducing the complexity of integrating web search, retrieval and grounding capabilities into enterprise applications, the company wrote in a blog post.
The APIs already underpins grounding for Microsoft Copilot and ChatGPT, and unlike traditional search APIs are designed to retrieve highly relevant information while minimizing token consumption, helping reduce both inference costs and response latency, Microsoft said.
That focus on reducing inference costs and response latency to deliver Web IQ’s search capabilities will be valuable for CIOs and developers, said Phil Fersht, chief analyst at HFS Research.
“Developers have typically stitched this together themselves using search APIs, web scraping, retrieval-augmented generation, vector databases, custom ranking logic, crawling tools and separate orchestration layers. That works, but it is messy, brittle and expensive to maintain,” he said.
“The hard part is not just finding a web page. It is retrieving the right evidence, ranking it, selecting useful passages, reducing token waste, respecting publisher controls and doing all this fast enough for multi-step agents,” he added.
An agent running in production will typically run at least five or ten retrieval steps and in such scenarios latency and cost can become “ugly,” said Moor Insights and Strategy principal analyst Mike Leone.
“I’ve watched plenty of teams handle this by gluing a search API onto a model and hoping the model can sort through whatever HTML comes back, which isn’t ideal,” he said.
Beyond the infrastructure and cost advantages, Web IQ could also simplify the AI application building process developers, said Stephanie Walter, practice lead of the AI stack at HyperFrame Research.
“The value of Web IQ is that Microsoft is trying to make web grounding a reusable, agent-native service rather than a bespoke integration,” Walter said.
That reusability, Fersht said, will matter to CIOs as most enterprises do not want every development team rebuilding its own web grounding stack: “They need a common capability that is governed, scalable, low-latency and economically efficient.”
Still, Microsoft is not entering an untapped market and there are several offerings already available, including OpenAI web search, Google grounding, Perplexity APIs, Bing Search APIs, Azure AI Search, vector databases, and custom RAG pipelines.
However, Microsoft might have an advantage with IQ, despite Google’s strength in search and web-scale knowledge, OpenAI’s tooling push, and AWS’ Bedrock-data-service-partner integrations combo, Fersht said.
“Microsoft’s differentiation is that it can combine Bing’s global web index with Azure AI, Copilot, Foundry, Microsoft 365 and enterprise developer channels,” he said.
The other advantage is the existence of existing IQ offerings, such as Work IQ, Fabric IQ, and Foundry IQ, all of which are targeted towards adding more business context for agentic systems, Fersht added.
But uptake, Walter said, will depend on whether these integrations translate into better production outcomes.
Web IQ is currently available in limited access for select Azure customers. Enterprises can request access to Web IQ via their Microsoft account team or submit a form.
Beyond direct API access, developers can also configure the model-agnostic Web IQ as an MCP tool within Foundry IQ, a Microsoft spokesperson said.
Cloud computing has reached a crossroads. The high cost and data sensitivity of AI workloads are raising the appeal of private clouds, even as neoclouds and sovereign clouds shake up the cloud provider landscape. New cyberthreats, shifting compute requirements, and management complexity are adding to cloud complications.
Download the June 2026 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World, and learn how to navigate the latest cloud strategy developments.
The European Union has now published a set of measures aimed at boosting Europe’s tech industry to help reduce reliance on US and Chinese suppliers for AI, cloud, and semiconductors. The proposals include rules to restrict the use of US hyperscalers for certain public sector procurement purposes, but stop short of banning them outright.
“Technological sovereignty does not mean protectionism. Europe remains grounded in openness, partnership, and fair competition,” Henna Virkkunen, executive vice president for Tech Sovereignty, Security and Democracy, said in a statement Wednesday. “At the same time, Europe wants to be in the position to make its own choices, avoiding dependence on single dominant suppliers, especially from non-like-minded countries.”
The European Technological Sovereignty Package — released after several delays — includes two legislative proposals: the Cloud and AI Development Act and Chips Act (CAIDA) 2.0 and the Open Source Strategy and Strategic Roadmap for Digitalization and AI in Energy.
CAIDA aims to triple data center capacity in the next five to seven years by easing restrictions for deployments across the EU. It also includes rules that, if enacted, would require EU public bodies to meet certain sovereignty criteria for cloud service procurement related to certain sensitive workloads.
Amid ongoing trans-Atlantic tensions and a long-time deep reliance on US tech providers, European organizations have become increasingly wary of a “kill switch” that would cut off access to digital services. There are also concerns that US hyperscalers could be compelled to share data with US government under the CLOUD Act and Foreign Intelligence Services Act (FISA), even when data centers are located in Europe.
The CAIDA proposals include four levels of criteria for suppliers; the most basic includes data center infrastructure located and operated in the region – something many US cloud suppliers already provide – with stricter rules around supplier ownership, full control over the software stack, and more stringent cybersecurity certification.
The majority of existing EU public sector workloads (70%) fall under the first level, with 20% at level 2, and 9% at level 3. Only a small proportion (1%) of the most sensitive workloads would require level 4.
Other proposals include the Chips Act 2.0, a follow-up to the 2023 legislation that sought to improve semiconductor production capabilities; the updated version now aims to boost research and spur demand for domestically produced processors.
The legislative proposals must be negotiated by the European Parliament and Council of the European Union before adoption.
Cloud computing has reached a crossroads. The high cost and data sensitivity of AI workloads are raising the appeal of private clouds, even as neoclouds and sovereign clouds shake up the cloud provider landscape. New cyberthreats, shifting compute requirements, and management complexity are adding to cloud complications.
Download the June 2026 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World, and learn how to navigate the latest cloud strategy developments.
IBM has launched a tool designed to help customers assess cloud-sovereignty risks and meet regulatory compliance requirements.
The Sovereignty Risk Profile launch comes as digital sovereignty becomes a higher priority for organizations concerned about where data is stored and processed. According to an IBM survey, 93% of executives believe sovereignty needs to be part of their business strategy.
Via the new tool, customers can set up policies related to regulatory and business requirements — such as where data resides and how it’s protected, for instance. These policies can be applied to specific cloud workloads, regions, or zones in the Sovereignty Risk Profile tool, allowing users to track sovereignty requirements “in real time,” IBM Cloud product manager Janet Van said in a blog post, with “visibility into configurations, encryption posture, and environmental controls.”
It’s then possible to assess compliance and decide what workloads meet sovereignty requirements.
Tracking the factors that contribute to sovereignty is a challenge for many organizations, said Holger Mueller, vice president and principal analyst at Constellation Research. “It is very difficult, as you don’t know about the details of the stacks; sometimes, even the location of data is not fully transparent,” he said.
The Sovereignty Risk Profile “addresses many of the compliance-related requirements associated with data residency and encryption, while also tackling sovereignty from a resilience and concentration-risk perspective,” said Dario Maisto, senior analyst at Forrester.
However, the monitoring tool can only do so much to address digital sovereignty concerns, he said. While it can help organizations identify and report on potential issues, it “does not help [make] clients more or less sovereign, per se: it has only the potential to tell that a sovereignty problem is there.”
Broader questions around digital sovereignty remain difficult to address, he said, as there’s no universally accepted definition of the concept and limited legislation to establish clear requirements.
Mueller described a spectrum of sovereignty issues that depend on factors such as whether data is stored, processed, and backed up in a customer’s own country, as well as whether staff that operate the data are domestic nationals. “Then there is the sovereignty of the software supply chain — but here everybody is dependent,” he said.
To further complicate matters, while several US hyperscalers sell sovereign-branded cloud services to European customers — with local staff and infrastructure — concerns remain about the potential for extra-jurisdictional access to data, due to the US CLOUD Act and the US Foreign Intelligence Surveillance Act (FISA).
The Sovereignty Risk Profile is available within IBM’s Security and Compliance Center Workload Protection. It’s the latest in a range of IBM Cloud products aimed at addressing customers’ sovereignty concerns, including the recently launched IBM Sovereign Core software platform.
Meta has raised the possibility that it could be joining the likes of Amazon, Microsoft and Google in offering cloud services at some point in the future — although potential customers shouldn’t be adding the company to their suppliers list just yet.
When asked about plans for offering such services at the company’s annual shareholders meeting, Meta CEO Mark Zuckerberg said there was a possibility of the company competing with the major hyperscalers. “It’s definitely on the table.”
He explained that different companies were approaching Meta asking for the company to offer an API service or to buy compute services at a premium price. “We haven’t done it yet, because we think we have a use for the compute, but when we feel we have overbuilt, then that is an option that we have.”
Meta has been active in developing its data centers over the past few years, so there will be a possibility of some excess capacity. It is also developing its own AI chips.
For the moment, though, the company may well need all the capacity it can build: Zuckerberg said that the launch of Muse Spark, a new AI model from Meta Superintelligence Lab, had resulted in large increases in Meta’s AI usage.
This article first appeared on Network World.
“The future of AI should be accessible, available, and open to people and builders everywhere, and it should not require an absurd amount of resources only available to a handful of cloud providers,” Paolo Ardoino, CEO, Tether.
About 700 million people use generative AIs like Gemini and ChatGPT weekly, but adoption is far from uniform. McKinsey’s 2025 State of AI survey found that nearly half of respondents from companies with more than $5 billion in revenue have reached the AI scaling phase, compared with just 29 percent of those from companies with less than $100 million in revenue, a gap that only widens further down the chain, locking out smaller businesses, developers, and everyday users.
Retail and small businesses are limited to basic AI utilities that their facilities can power, such as text-based inference and multimedia generation, using base models. That is billions of end users, and developers locked out of full utilization and development of intelligent software due to high infrastructure demands.
Tether’s edge-first LoRA fine-tuning framework for Microsoft’s Bitnet LLM is an important step towards developing an infrastructure system that supports billions of AI agents and intelligent machines. By reducing the computational overhead of machine learning and enabling consumer-grade devices to perform advanced operations, Tether’s edge-first approach ensures greater leverage for the larger population.
Imagine a 13-billion-parameter model being fine-tuned on everyday handheld devices like Samsung S25 and iPhone 16, as well as on regular personal computers. The breakthrough combines resource-efficiency and platform-agnostic techniques to develop a fine-tuning framework for the ternary-quantized LLM.
Bitnet LLM was born out of the vision of an intelligent AI model that doesn’t consume outrageous computing resources even at full precision. Earlier attempts at resource-efficient AI relied on trade-offs, such as running small-parameter models at higher precision or larger-parameter models at lower precision, but neither approach fully solved the problem.
Bitnet takes a more fundamental approach. The result is a model that achieves linear efficiency while consuming only a fraction of the computing resources traditionally required.
The challenge, however, is that contemporary GPUs are optimized for the very floating-point operations Bitnet eliminates, creating a hardware compatibility gap. Compounding this, Bitnet was originally confined to its own Bitnet.cpp inference engine, limiting its broader utility. Tether’s breakthrough addresses both constraints at once by integrating a Vulkan and Metal GPU backend that unlocks true cross-platform capabilities for BitNet inference and LoRA fine-tuning on heterogeneous consumer GPUs, including mobile GPUs. Bitnet can now run on more mature, widely supported inference engines without sacrificing its efficiency advantages.
Vulkan’s cross-platform nature is key here. Unlike CUDA, which ties developers to NVIDIA hardware, Vulkan runs across a broad range of GPUs and operating systems, opening Bitnet to genuinely multi-platform deployment. Tether’s Bitnet fine-tuning framework implements a dynamic tiling technique to mitigate limitations in Vulkan driver buffer allocation on mobile GPUs.
The dynamic tiling algorithm technique was first applied in the fine-tuning framework for QVAC Fabric LLM, the AI model that powers Tether’s QVAC Workbench application.
This implementation demonstrates the efficiency of this approach: fine-tuning a 13-billion-parameter model across a range of consumer devices with varying GPU configurations.
The Bitnet LLM Fine-tuning framework is Tether’s latest achievement and part of a broader expansion into open-source AI and communication technologies that challenge current, slow, fragile, and controlled systems. These developments are open-sourced and packaged as modules in the QVAC SDK for easy deployment and to help developers build edge-first AI applications without needing anyone’s permission.
Tether envisions superintelligence as a foundational element possessed by its owner and is enforcing this through:
Synonymous with decentralized AI, “Local-first” AI aims to create sovereign AI solutions that do not rely on centralized infrastructure, such as data centers, to operate. They are considered cost-effective, relatively more sustainable, and unarguably more private than centralized AI. Tether is building AI applications that rely entirely on the device’s resources. These applications store data in device memory and use its processors for advanced operations, such as fine-tuning and inference.
Tether’s AI applications are built on the Pear runtime. Pear is a tooling platform for fully P2P applications that can operate without servers. Pear leverages the Holepunch tech stack. Holepunch is purpose-built for stable, direct communication between devices. Pear enables delegated inference for AI applications such as QVAC Workbench. Delegated inference enables a unified, dynamic workstation architecture where compute tasks are fluidly distributed between mobile and desktop environments, allowing either device to offload high-intensity processing to the most capable system. That is, you can start a task on your mobile device and delegate it to your desktop or laptop for completion.
The only way to scale intelligence to the needs of a ten-billion-strong society is to push it to the edge. This, in turn, depends on the progress made by experiments aimed at cost-effectively localizing AI computation.
Billions of AI agents and countless AI applications deployed by developers in every region of the world, running effectively on user-owned resources, is the only way we can democratize superintelligence and avoid creating another ‘luxury’ cutting-edge technology controlled by unicorns and fully accessible only to elites.
Tether is pioneering limitless superintelligence for an ever-growing society and applications. Follow the journey to truly local and edge-first AI solutions
Login