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.

Amazon Aurora MCP Servers

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 MCP Server

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.

Elastic Agent Builder

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.

MCP servers for Neo4j

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.

MCP Toolbox for Databases

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 MCP Server

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.

Pinecone MCP server

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.

Redis MCP

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 MCP Server

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.

Supabase MCP Server

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.

Other MCP servers for databases to consider

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.

Using MCP for databases: what to watch out for

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.

Avoiding the double-licensing problem

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.

More control over workloads, loosening Microsoft’s grip

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.

Enterprises take on new responsibilities

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.

Just one challenge in the AI race

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.”

I’ve seen a lot of promising AI prototypes fall apart after launch. And it’s rarely because the model was bad. More often, the problem starts much earlier; teams treat the data layer like something they can figure out later.

They’ll spend weeks fine-tuning prompts, testing models and debating evaluation scores, then throw together the retrieval pipeline over a weekend and move on. At first, everything looks great in demos. But a few months later, the system gives outdated answers; the embeddings no longer match the source documents, and nobody fully understands what changed.

What started as an impressive prototype slowly becomes difficult to trust in production. The teams that avoid this tend to realize one thing early: Embedding pipelines are fundamentally a data engineering problem, not an entirely new AI discipline. It’s still ETL (Extract, Load, Transform) at its core, but with embeddings and vector stores as the destination instead of a warehouse.

Once you start looking at it that way, a lot of things become clearer. Problems like versioning, data freshness, lineage and retries stop feeling “AI-specific.” They’re data infrastructure problems we’ve already spent years learning how to solve.

Why do we need embedding pipelines?

Large language models are extraordinary reasoners trapped inside a time capsule. When training ends, the model’s knowledge is sealed. It does not know what your team decided in last quarter’s strategy review. It has never read the support ticket that came in this morning. It cannot find the clause buried on page 47 of your master service agreement. It’s brilliant, but blind to anything specific to your organization.

Layer on top of that a hard context window limit, a ceiling on how much text the model can process in a single interaction, and you have a clear problem: you cannot just hand it everything you own.

The answer the industry converged on is retrieval-augmented generation, or RAG. Instead of stuffing everything into the context window, you build a retrieval layer that fetches only the most relevant pieces of information at the moment a question is asked and passes just those to the model. That retrieval layer is powered by a vector database, and the process that populates it, which is taking raw documents and transforming them into searchable semantic representations, is what I mean when I say embedding pipeline.

Every team building an internal AI assistant, a smarter enterprise search tool, an automated customer support agent or a document Q&A system needs one. The question is not whether to build it. The question is whether you build it like a prototype or like infrastructure.

How an embedding pipeline works

An embedding pipeline has three stages: ingestion, chunking and indexing. Here is what each one means and how I relate them to a typical ETL process.

Ingestion is extraction

Getting your raw content, PDFs, wiki pages, Word documents, database records, transcripts, out of wherever it lives and into the pipeline. This is ETL’s extract stage, almost verbatim.

I see teams cut corners here more than anywhere else, and it’s often where production systems first start to fail. A document gets updated, but the pipeline doesn’t pick it up. A file gets deleted, but its chunks remain in the index, still returning outdated answers months later. And because there’s no obvious error, no one reports it.

The fix is Change Data Capture (CDC). This maintains a manifest of every document you have ingested, a content hash and a timestamp. On each run, we compare sources against that manifest, re-ingest what changed, delete what is gone and treat your document the way you would treat any source table you are syncing incrementally.

Chunking is transformation

Once your documents are in the pipeline, you cannot embed them whole. A 30-page technical report is too long to represent meaningfully as a single vector, and even if it were not, returning the entire report in response to a narrow question would bury the model in irrelevant context.

Chunking is the process of breaking each document into smaller pieces that are focused enough to embed accurately and retrieve precisely. This is ETL’s transform stage, and it deserves the same level of design discipline.

The most common mistake I see is treating chunk size as a default configuration option rather than a product decision. It is not. The right chunk size depends entirely on the nature of your content and the nature of your queries. Dense technical documentation needs finer granularity than a collection of FAQs. A legal contract with clause-level logic needs different treatment than a set of onboarding emails. What works for one document will actively degrade retrieval quality on another.

My strong preference is to treat your chunking configuration as a versioned pipeline parameter, not hardcoded logic. When you change it, and trust me, you will. You need to re-chunk in a controlled, observable way, compare retrieval quality before and after, and roll back if it degrades. That is just good transform-layer hygiene. It is no different from versioning a data cleaning rule or a field mapping.

Indexing is the load

The final stage is where chunked text gets converted into vectors and stored in a vector database where it can be searched by semantic similarity rather than keyword match.

In the conversion step, embedding is handled by a model specifically trained to turn text into dense numerical representations that encode meaning. Two chunks expressing the same idea in different words will produce vectors that cluster close together in that mathematical space. Two chunks discussing entirely different topics will sit far apart. When a user asks a question, the system embeds that question the same way, finds the chunks whose vectors are nearest, and returns them as context for the model to reason over.

That is a genuinely new capability. But the discipline around indexing is not. One data engineering principle I keep coming back to is versioning.

In embedding pipelines, every chunk in your index should be tagged with the embedding model name and version used to generate it, this is non-negotiable. Embedding models evolve, and vectors produced by different versions are not comparable in a reliable way. You cannot safely search across them as if they are interchangeable.

This exact problem shows up when teams upgrade embedding models mid-pipeline without a proper migration plan. You end up mixing vectors from different generations in the same index, and retrieval starts to degrade in ways that are hard to detect. The system just quietly begins returning subtly wrong answers.

I treat an embedding model upgrade the same way I treat a schema migration: Plan it explicitly, execute it in full and validate retrieval quality on a representative query set. The stakes are the same as any breaking change to your data model.

Pipeline observability is not optional

Once an embedding pipeline is running in production, the question shifts from “did it run” to “did it run correctly.” That distinction matters more here than in most pipelines, because failures are rarely loud because the index looks fine, queries return without errors and the system quietly surfaces wrong answers until someone notices the AI has stopped being useful.

The same observability discipline that makes any data pipeline trustworthy applies directly here. Once you treat embedding pipelines as production systems, you stop thinking in isolated steps and start thinking in signals. For example, chunk counts per document become a simple but powerful health check, a sudden drop is usually not a model issue, but a sign of broken ingestion or upstream parsing failures.

You also need a “golden set” of queries with known-good outputs. This runs after every pipeline change, much like data quality checks after a transformation. This is how you catch regressions that don’t show up as explicit failures.

On top of that, you can track lineage: Which embedding model version produced which chunks, and when each document was last ingested. That makes it possible to trace retrieval issues back to specific changes instead of guessing.

And finally, freshness becomes a first-class signal. If documents start going stale beyond an acceptable threshold, that should surface in monitoring long before users experience degraded results.

The metric that ties it all together is retrieval quality over time. Treat it like any other pipeline SLA, measured, tracked and owned.

Summary

Embedding pipelines definitely come with a lot of new language, new tools and a genuinely different capability in the semantic layer. But the funny thing is, the principles that actually make them reliable in production are not new at all.

We have versioning, freshness, quality checks and monitoring. These are problems data engineering has already spent years solving.

The real work is taking that same discipline and applying it to a pipeline that just happens to output vectors instead of rows in a table. Once you start seeing it that way, a lot of the chaos around AI systems becomes much easier to reason about.

That’s the difference between building a cool AI demo and building something people can actually depend on. One is a prototype, whereas the other is infrastructure.

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

Artificial intelligence does not advance at the same pace across industries. It presses forward in some directions while lagging behind in others.

Spend time with today’s most advanced AI applications, and this contrast becomes obvious. In software development, AI is quickly becoming ubiquitous. It writes production-ready code, explains obscure libraries, and iterates at a pace human teams have difficulty matching.

But place that same AI model inside a complex customer support workflow or ask it to reason through a nuanced clinical scenario, and the cracks begin to show. Multi-step reasoning falters. Context gets lost. Performance drops in ways that can seem inconsistent with the model’s strengths elsewhere.

These AI models are often similar. They run on similar hardware and are often trained in similar ways. So why the mismatch in performance across tasks? The simplest explanation is also the most overlooked: data.

Software engineering benefits from an immense, structured, and highly visible digital record. Code is written in standardized languages, benefits from robust documentation, is reviewed in public forums, and is discussed at scale. That ecosystem has generated a robust and massively useful pool of training material.

Other fields often do not. For example, healthcare data is scattered across institutions, wrapped in privacy constraints, expressed in multiple modalities, and rarely ready out-of-the-box for AI training. Enterprise workflows are captured in internal systems that were never designed for training AI. Multilingual speech data varies widely in quality and representation.

This imbalance creates what I describe as “the data gap.” This is the distance between what models are capable of in theory and what they can achieve in practice, because the right data does not yet exist in usable form. Closing this data gap may be the most important—and least glamorous—challenge in AI today.

The missing pillar of AI progress

Three forces are driving the recent advances in AI: the models, the chips, and the data.

On the AI models, the field has invested heavily. Major research organizations employ thousands of researchers and scientists who are actively refining architectures, training techniques, and evaluation methods. Breakthroughs are measured in benchmark scores, conference papers, and model performance on human tasks. On the computing chips, the investment has been equally intense. Hardware manufacturers and infrastructure providers are pouring billions of dollars into building and supporting data centers that deliver faster results via large-scale training.

Yet data has not received the same institutional focus for AI development. Conversations with researchers at frontier AI labs share a similar frustration that today’s model capabilities in key use cases, such as healthcare, are limited less by architectural imagination and more by the availability of high-quality, domain-specific data. The bottleneck is not always a lack of ideas, but a lack of reliable inputs.

We are long past scraping the internet for useful data, and this path does not scale. Progress depends on building and curating datasets that reflect the complexity of true lived experience and organizational processes. That work requires both scientific rigor and research specialization in the field of data for AI.

The dataset behind every leap

The history of AI reinforces a consistent lesson: major leaps in model capability follow major leaps in the availability of quality data. From early vision systems that relied on clearly labeled images to today’s language models trained on massive text collections, each major leap has depended on access to more high-quality data.

Architectural innovation alone is rarely enough. The value of these new approaches only emerges when paired with large, structured, and representative datasets that reveal what the models can actually do in practice. Whether in vision or language, progress has depended on the painstaking work of collecting, organizing, and validating the underlying data.

Large language models illustrate this clearly. Their emergence was not just the result of better training techniques, but of access to an unprecedented volume of data. The models did not generate that data. They relied on it. That pattern raises a pressing question for the present: who is building the next generation of foundational datasets?

Across domains ranging from healthcare to audio to agentic task performance, there is no widely accepted blueprint. What constitutes a gold-standard dataset for training an AI agent to handle complex enterprise tasks? What does a clinically meaningful evaluation look like for a model that will assist in medical decision-making? How should multilingual speech data be curated to ensure broad representation and reliable performance?

These are not simple sourcing problems. They are fundamental research challenges that need to be solved.

When data is treated as a commodity

Too often, consequential data decisions are handled like procurement exercises. An organization requests “medical conversations” or “wildlife scenes,” and the request is routed to internal procurement or data sourcing teams, or to external data vendors, who assemble data that appears to match the description. The implicit assumption is that data is interchangeable, that one dataset is as good as another so long as it meets a basic specification.

Actual application suggests otherwise. Seemingly small choices about factors such as inclusion criteria, annotation standards, filtering rules, and validation protocols can dramatically alter downstream performance. Data design shapes model behavior as much as architecture does.

Three structural issues compound the problem:

• Capacity: There are relatively few specialized teams dedicated to building domain-specific datasets at the highest level of rigor. Talent and funding have gravitated toward model development and hardware innovation. Data work often operates in the background, even though it underpins both.
• Design: Constructing a dataset is a distinct discipline from designing a neural network. It requires expertise in experimental design, domain knowledge, and statistical validation. Expecting model researchers to simultaneously shoulder the full burden of data research, while also training and evaluating the models, overlooks the complexity of the upstream task.
• Translation: The researchers who are requesting specific data sources to improve the models are often not the same people responsible for sourcing that data. As a result, nuances and research-backed expertise can often be missing or diluted as requests pass through layers of procurement and vendor relationships. The result can be data that meets the specification sheet, but in fact fails to advance model performance.

The rise of annotation providers and reinforcement learning services has addressed part of the need. Rating model outputs, labeling text, and evaluating structured information are essential for many optimization tasks. But these activities generate data that is carefully constructed for specific, bounded purposes.

The frontier challenges in AI require more. They demand datasets derived from real human activity and organic organizational processes. Such data is complex, multimodal, and sensitive. It is rarely AI-ready by default. And converting it into reliable training and evaluation material is a scientific undertaking.

The need for scientific rigor for the AI data layer

If high-quality data is a central bottleneck, then scientific rigor is part of the solution. Just as leading model-builders have dedicated research labs and hardware has dedicated development ecosystems, the data layer for AI requires focused, scientifically-grounded institutions.

This means engaging directly with core questions like dataset design, evaluation methodology, and quality control. The conversation cannot end at volume; it must address data structure, representativeness, and expert validation.

Dataset construction must be approached as experimental design. Protocols must be documented and validated. Evaluation frameworks must test whether the dataset truly reflects the intended applications.

The field also requires standards and benchmarks that reflect real-world complexity, not simplified proxies. In healthcare, for instance, evaluating a system intended for clinical assistance with generic question-and-answer tests is insufficient. Real-world clinical environments involve multimodal inputs and contextual judgment. Benchmarks must reflect that reality if they are to function as meaningful gates before deployment.

Quality measurement is another crucial frontier. Finance relies on standardized metrics such as credit scores to assess risk. AI lacks an equivalent for datasets and benchmarks. Developing clear methodology to quantify dataset quality and evaluation reliability brings clarity to model assessment.

The criteria for evaluating a multilingual audio library will differ from those of a multimodal oncology dataset. Yet the underlying principle remains constant. Better models require better-defined, better-measured data.

The risks of getting it wrong

As AI systems move closer to high-stakes deployment, weak data practices carry tangible risks.

Benchmarks cannot be created with the same data that is used for training—that’s giving the test answers to the model ahead of time. Scaling data volume without prioritizing data quality and selection diminishes model performance gains, and can even bias against or omit underrepresented populations. These are methodological challenges, and ones that must be solved.

The rigor required at the data layer may not attract headlines. It does not typically lend itself to dramatic product launches. Yet the data layer for AI is foundational to trust, safety, and sustained progress for all AI progress.

An ecosystem for the data era

No single organization can resolve the data gap alone. What is needed is an ecosystem of AI data labs and research groups, each focused on different domains and challenges but united by a commitment to scientific discipline. These institutions would collaborate with model researchers and domain experts who would tackle challenges such as dataset contamination, factuality, groundedness, de-identification, international representation, and bias. They would design benchmarks that mirror real-world complexity rather than simplified abstractions.

AI’s trajectory will not be determined solely by larger models or faster chips. It will be shaped by the datasets we construct, the standards we adopt, and the rigor we apply at the foundation. The uneven frontier we see today reflects an uneven data landscape. Bridging the gap requires deliberate, research-driven dataset design.

If we want AI systems capable of operating reliably in clinical contexts, navigating enterprise workflows, and functioning responsibly across languages and cultures, we must treat data for AI as a first-class scientific endeavor.

AI models have their research labs. AI chip-builders have their fabrication plants. AI data needs institutions of equal seriousness and ambition.

—

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.

As enterprises move from AI experimentation to production deployments, one challenge is becoming increasingly apparent: AI systems are only as reliable as the business context they operate in.

Snowflake is attempting to address that problem with Horizon Context, a new set of semantic and metadata-management capabilities, currently in preview, that it unveiled Tuesday at its annual Snowflake Summit conference.

Artin Avanes, head of core data platform at Snowflake, said that the offering, launched as part of Horizon Catalog, the company’s existing data discovery, management and governance suite, collects metadata from across an enterprise’s data estate, enriches it with business definitions, relationships, lineage, and governance information, and makes that context available across AI and analytics systems.

These capabilities, according to Avanes, build on Snowflake’s acquisition last year of Select Star, a metadata management startup known for its integrations with database systems such as PostgreSQL and MySQL, business intelligence tools like Tableau and Power BI, and data pipeline/orchestration tools such as dbt and Airflow.

Reducing operational complexity of agentic workflows

For CIOs, Horizon Context should reduce operational complexity because it will provide a governed map of their organization’s data estate, said Stephanie Walter, practice lead of the AI Stack at HyperFRAME Research.

“The value is not simply cataloging where data lives; it is giving AI systems the metadata, lineage, permissions, and business context needed to retrieve the right data safely,” Walter said.

In fact, according to Robert Kramer, managing partner at KramerERP, the challenge of missing context for analytics and reporting is not new for enterprises.

“Most enterprises were stitching together catalogs, BI semantic layers, governance tools, lineage, access controls, dbt models, security policies, and custom integrations. The issue was not that these pieces did not exist. The issue was that they were fragmented,” he said.

That duct-taping together of different pieces, said Mike Leone, principal analyst at Moor Insights & Strategy, is the actual reason why most teams in an enterprise would end up with slightly different versions of a business metric, such as monthly active users, resulting in AI agents also being inconsistent downstream.

But, said Walter, the stitching together of different catalogs and semantic layers only works for semi-autonomous workflows. “What changed with AI agents is that those systems increasingly need access to context at runtime rather than through documentation and human interpretation,” she said. “Snowflake is trying to pull those pieces closer to the data platform, so context, semantics, access control, and execution are part of the same operating environment”

Automatically maintaining business context for AI agents

To supplement Horizon Context, Snowflake is also adding Semantic Studio, currently in private preview, to help enterprises reduce the effort required to build and maintain business context for agents and agentic workflows.

“Semantic Studio is a core part of the Enrich layer of Horizon Context, providing the AI-assisted workspace where teams define, test, and publish that business logic,” Avanes said.

The Enrich layer itself, which consists of companion capabilities like the Semantic View Autopilot, automatically layers intelligence on data assets, providing insights such as which assets are most trusted, how they connect, what they mean, and how to correctly calculate metrics, Avanes added.

According to Leone, Semantic Studio solves a critical challenge: “It will reduce the burden of SQL-savvy data engineers and let business owners author the shared definitions. That’s where most semantic-layer projects die today.”

For Walter though, there is still a caveat to these offerings.

“While these offerings reduce complexity, they do not remove the work. Someone still has to decide which metrics are authoritative, which data products are trusted, and who owns the business definitions,” she said.

Addressing security and governance concerns

Alongside these updates, Snowflake is also trying to address security concerns around agentic workflows with new capabilities inside Horizon Catalog’s Trust Center.

These capabilities, which are focused on AI Security Posture Management (SPM), include a new agent identity capability that enables enterprises to distinguish between human activity within a session and actions taken by an AI agent operating on a user’s behalf, Avanes said.

“This should provide greater transparency and auditability for agents, while also enabling enterprises to apply existing data access controls, such as dynamic masking and row access policies, on an agent-by-agent basis,” he said.

Another new capability, data exfiltration policies, currently in private preview, will help enterprises prevent unauthorized movement of sensitive data. These policies are part of Horizon Catalog’s broader governance framework, and will allow enterprises to define controls around how data can be accessed, shared, and moved across systems, Avanes said.

For enterprises, Walter noted, these capabilities could help address one of the biggest barriers to deploying AI agents in production: governance.

“Data exfiltration controls, AI Security Posture Management, and other centralized AI controls help CIOs move from experimentation to production by giving security teams a way to see and govern how AI workloads interact with enterprise data,” she said.

Echoing Walter, Leone pointed out that the “security story” is the gating issue for almost every agent deployment that Moor Insights & Strategy is currently tracking.

“Features such as data exfiltration policies and AI SPM are what convert a CISO from a ‘no’ to a ‘yes’ on moving an agent deployment into production,” he added.

This article originally appeared on CIO.com.