That distinction matters for IT teams planning deployments. Microsoft SQL Server, Shopify, HubSpot, Klaviyo, and Mailchimp are still preview features; PostgreSQL and MySQL are generally available for standard transfers, but their newer incremental-transfer modes remain preview; and the Snowflake connector reached general availability on April 9, 2026. The practical news is less a same-day connector drop than a consolidation of BigQuery’s push to absorb more ingestion, migration, and automation work that organizations previously handled through custom pipelines or specialist ETL products.
Google’s current BigQuery Data Transfer Service documentation confirms that the connector inventory now includes Microsoft SQL Server in preview; MySQL and PostgreSQL; Shopify, HubSpot, Klaviyo, and Mailchimp in preview; and Snowflake. The service schedules managed loads into BigQuery and supports backfills, but it is an ingestion service: it does not transfer data out of BigQuery.
The connector rollout was real, but it was not one August release
Google’s BigQuery release notes put dates on the rollout that the broader reporting leaves out. PostgreSQL transfers reached general availability on December 22, 2025, and MySQL reached general availability on December 19, 2025. Microsoft SQL Server landed the same week as a preview connector, while HubSpot and Klaviyo were introduced in preview on December 18.
Mailchimp followed in preview on January 27, 2026. Shopify appeared in preview on March 24. Google then made the Snowflake transfer connector generally available on April 9, while adding preview incremental-transfer support for Microsoft SQL Server on April 8 and for MySQL, PostgreSQL, Oracle, and ServiceNow on April 7.
For a data engineering team, these launch-stage details are not semantic housekeeping. A generally available connector is supported under Google Cloud’s normal production framework; a preview connector is governed by pre-GA terms and can have limited support or change before general availability. Organizations should therefore resist treating all seven database and SaaS connectors as equally mature simply because they appear in the same service catalog.
There is a further qualification for MySQL and PostgreSQL users. Their core connectors are GA, but Google’s documentation still labels incremental MySQL transfers as preview, and its release record separately labels incremental PostgreSQL support as preview. A team that only needs periodic full reloads can treat those database connectors differently from a team expecting production-grade change-style replication with upserts and watermark columns.
That is especially relevant for enterprises coming from SQL Server, PostgreSQL, or MySQL environments where a “transfer connector” can be mistaken for full change data capture. BigQuery Data Transfer Service supports scheduled full and incremental patterns, depending on the source and configuration, but it is not a substitute for assessing latency, source database load, conflict handling, retention, schema drift, and recovery behavior in a production replication design.
Snowflake migration still includes a staging hop
The Snowflake connector is the most strategically pointed addition because it gives Google a native migration path from a direct warehouse rival. Google documents the connector as generally available and says it supports Snowflake accounts hosted on Google Cloud, AWS, or Azure. It also offers automatic schema detection, incremental-transfer options, private connectivity options, and authentication features intended to make the path less dependent on manual export jobs.
But “direct migration” should not be interpreted as a direct live link between two warehouses. Google’s Snowflake transfer documentation says the service uses migration agents running in Google Kubernetes Engine and stages data in Cloud Storage before it is loaded into BigQuery. For Snowflake accounts on AWS, Azure, or Google Cloud, that staging behavior remains part of the data path.
That architecture creates operational consequences that a migration project needs to price and test. The source warehouse’s chosen compute capacity can constrain export speed. Google also notes that the connector handles one Snowflake database and schema per transfer configuration, so broad estates spanning multiple databases or schemas require multiple jobs. And the Parquet staging route has a documented type limitation: Snowflake TIMESTAMP_TZ and TIMESTAMP_LTZ values are not supported in that transfer path.
The connector can remove substantial orchestration work, but it does not eliminate migration engineering. Teams still need an inventory of unsupported types, table boundaries, schema mappings, transfer windows, validation queries, and a plan for downstream reports or applications that depend on Snowflake-specific SQL behavior. Google’s BigQuery Migration Service can help with assessment and SQL translation, but moving table data is only one part of exiting a warehouse.
Iceberg support is an ingestion destination, not a no-copy shortcut
Google added preview support in December 2025 for loading data from Cloud Storage, Amazon S3, and Azure Blob Storage into BigLake Iceberg tables in BigQuery. This is useful for teams adopting Apache Iceberg as an open table format while retaining BigQuery’s managed analytics and governance controls.
The wording here matters. The connector transfers data from those blob-storage sources into Iceberg tables managed through BigQuery; it is not simply a promise that BigQuery will query data in place wherever it currently resides. The move can still involve transfer, storage, and cloud-network cost considerations, particularly when the original files sit in AWS or Azure.
Google’s Apache Iceberg managed-table documentation describes the tables as a managed BigQuery experience backed by customer-owned storage buckets. BigQuery can perform compaction, clustering, garbage collection, metadata maintenance, schema evolution, time travel, and access-control functions, while the Iceberg format remains usable by compatible engines such as Spark. That combination is attractive for organizations that want more interoperability than a warehouse-only table format offers.
It also shifts responsibilities rather than erasing them. Deleting or making the backing bucket inaccessible can create data-loss exposure, according to Google’s documentation. Storage optimization consumes separately billed data-compute resources, and standard query, storage, and cloud-storage charges can still apply. The new transfer option reduces the need to hand-build landing pipelines, but it does not make cross-cloud lakehouse data free or operationally invisible.
The Data Transfer Service MCP server is the important AI addition
The submitted report is right that Google now offers a remote Model Context Protocol server for BigQuery Data Transfer Service. Google’s release notes show that the Data Transfer Service MCP server entered preview on March 24, 2026, and the current Google Cloud MCP product list still labels it Preview.
This is separate from Google’s more general BigQuery MCP server. The ordinary BigQuery MCP server is designed for activities such as listing datasets and tables, inspecting metadata, and executing SQL. Google made that BigQuery MCP service generally available in May 2026. The Data Transfer Service MCP server, by contrast, is intended to let an AI agent create, manage, and run transfer configurations.
That difference is consequential. A query-oriented agent can help analyze data already in BigQuery; a transfer-service agent can potentially alter the pipeline that brings data in. The latter requires a much tighter control model, especially when a transfer configuration contains source credentials, schedules, destination datasets, and access to customer or operational data.
Google’s remote MCP framework uses IAM controls and audit logging, and administrators can apply IAM deny policies to constrain tool access. Those controls are useful, but they do not make an agent-generated transfer safe by default. Platform teams should begin with dedicated service accounts, least-privilege permissions, nonproduction destinations, explicit approval gates for new connectors, and log reviews that distinguish agent-made changes from ordinary automation.
An agent that can create a transfer is not merely answering questions about a warehouse. It can start moving data, consume compute, populate datasets, and create a new path for sensitive records. For most enterprises, this preview should first be treated as a controlled operations interface rather than an autonomous data-engineering replacement.
Reliability and pricing remain source-dependent
Google’s service messaging emphasizes managed ingestion, IAM integration, destination dataset controls, row-level and column-level security, and customer-managed encryption keys. Those are real controls once the data lands in BigQuery. They do not guarantee the source system will be available or that a third-party connector will meet the same delivery targets as a Google-native source.
Google explicitly says its Data Delivery SLO applies to scheduled transfers from sources within Google Cloud. It does not apply to third-party or non-Google Cloud sources, because outages or API failures at those services can affect performance. That limitation covers precisely the connectors likely to draw the most interest here: Shopify, HubSpot, Klaviyo, Mailchimp, SQL Server deployments outside Google Cloud, Snowflake, AWS storage, and Azure storage.
The pricing model needs the same scrutiny. Google changed third-party SaaS and database connectors to consumption-based pricing in September 2025, measured in slot-hours when the relevant connectors are GA. Data that arrives in BigQuery also remains subject to the usual BigQuery storage and query charges. A connector may reduce engineering labor while adding a new variable compute line item, particularly when a schedule repeatedly reloads large source tables instead of transferring narrowly scoped changes.
BigQuery Data Transfer Service is becoming a more credible front door for data arriving from outside Google Cloud. The missing headline is that its newest capabilities are unevenly mature: production teams can use the GA database and Snowflake paths, but should treat preview SaaS connectors, incremental modes, Iceberg ingestion, and AI-managed transfers as separate risk decisions rather than one blanket upgrade.
References
- Primary source: IT Brief Australia
Published: August 9, 2026 at 11:45 PM UTC
Google expands BigQuery transfer service with new connectors
Enterprises will be able to move more sales, marketing and database data into BigQuery as Google adds connectors for SQL Server and Shopify.
itbrief.com.au
- Related coverage: docs.cloud.google.com
What is the BigQuery Data Transfer Service? | Google Cloud Documentation
docs.cloud.google.com
- Related coverage: docs.cloud.google.com
Apache Iceberg managed tables | BigQuery | Google Cloud Documentation
Describes how to use Iceberg managed tables. - Related coverage: cloud.google.com
BigQuery Data Transfer Service enhancements | Google Cloud Blog
Learn about recent enhancements to the BigQuery Data Transfer Service connector ecosystem, security and compliance features, and the user experience.cloud.google.com
- Related coverage: cloud.google.com
Announcing BigQuery Migration Service | Google Cloud Blog
Announcing BigQuery Migration Service, a set of free-to-use tools to help you with your end-to-end migrations to BigQuery. - Related coverage: bigdataprep.com
Pass GCP-ADP Google Associate Data Practitioner Exam: Study Tips & Resources!
GOOGLE ASSOCIATE DATA PRACTITIONER CERTIFICATION QUESTIONS & ANSWERSwww.bigdataprep.com
- Related coverage: codelabs.developers.google.com
Getting Started with Google MCP Servers | Google Codelabs
Welcome! In this codelab, you will learn how to supercharge your AI agents using Google Managed Model Context Protocol (MCP) Servers.
codelabs.developers.google.com
- Related coverage: techcrunch.com
Google launches managed MCP servers that let AI agents simply plug into its tools | TechCrunch
Google is rolling out managed MCP servers to make its services “agent-ready by design,” starting with Maps and BigQuery, aiming to simplify messy integrations and help AI agents use real tools.techcrunch.com - Related coverage: growthengineer.ai
- Related coverage: scalekit.com
Google BigQuery MCP vs API for AI Agents: How to Choose
Compare Google BigQuery MCP and BigQuery API for AI agents—covering capability gaps, auth models, result size limits, and per-tenant credential management.www.scalekit.com - Related coverage: nerova.ai
- Related coverage: medium.com
Medium
Agentic Infrastructure: Provisioning Bigtable using the Model Context Protocol (MCP) As developers, we are rapidly moving toward an “Agentic” future. We are getting accustomed to our IDE agents …medium.com
- Related coverage: security.googlecloudcommunity.com
Remote SecOps MCP server: all SOAR-backed tools return "Internal error encountered." on one instance, while SIEM tools work fine | Community
Hi all,We operate multiple Google SecOps instances and use the managed remote MCP server (chronicle.<region>.rep.googleapis.com/mcp, negotiated pr...
security.googlecloudcommunity.com
- Related coverage: medium.com
