Google Expands BigQuery Data Transfer Service With Native Database Replication and Zero-Code Ingestion

Introduction
Modern data architectures increasingly depend on moving information between operational databases, cloud storage, SaaS platforms and analytical systems. For engineering teams, however, data movement can become one of the most difficult parts of the architecture to maintain.

Google is expanding its BigQuery Data Transfer Service (DTS) to address that problem with new database connectors, replication capabilities, Apache Iceberg ingestion and a managed Model Context Protocol (MCP) server.

The additions announced on August 8, 2026, extend DTS beyond conventional data transfer into a broader managed ingestion layer for enterprise databases, cloud storage and business applications.

The central idea is straightforward: developers can move data into BigQuery without building and maintaining custom extraction and loading pipelines for every source.

For database and infrastructure teams, the more significant development is the expansion of native support for relational databases and incremental transfers. PostgreSQL and MySQL are now generally available, while Microsoft SQL Server is available in preview.

The service also adds Snowflake migration capabilities, direct ingestion into Apache Iceberg managed tables and enhanced incremental update support for ServiceNow, Salesforce and Oracle.

These capabilities could reduce the amount of custom integration code required when operational databases need to feed analytical workloads.

Database Ingestion Moves Closer to the Data Warehouse

Traditional enterprise architectures often separate transactional databases from analytical platforms.

An application may use MySQL or PostgreSQL for transactional workloads, while a separate warehouse stores data for reporting, business intelligence and machine learning.

Connecting those systems typically requires an extraction process.

A simplified architecture may involve an operational database, an extraction service, transformation logic, a staging location and finally a data warehouse. Each additional component introduces another configuration surface to operate, monitor and secure.

BigQuery DTS is designed to remove much of that infrastructure.

Google describes DTS as a fully managed, zero-code data movement service that automates data ingestion into BigQuery. The latest database capabilities extend that model to operational database environments.

PostgreSQL and MySQL are now generally available as DTS sources. The service supports replication from on-premises environments, Cloud SQL and other clouds.

Microsoft SQL Server is available in preview and is designed to centralise transactional tables, schemas and operational data inside BigQuery.

For developers, the important capability is not simply that another connector has been added. The broader change is that database replication can be handled as a managed data movement operation instead of becoming another application or infrastructure project.

That distinction becomes particularly important for high-volume application workloads.

When an application continuously generates orders, customer records, transactions or other operational events, an analytics team often needs access to those records without placing additional analytical workloads directly on the production database.

A managed transfer layer creates a separation between operational workloads and analytical consumption.

Full and Incremental Transfers

Google states that the enterprise database capabilities support both full and incremental transfers.

A full transfer is useful when initially loading a database or creating a new analytical copy. The system transfers the relevant source data into the destination environment.

Incremental transfer is more important for ongoing production workloads.

Instead of repeatedly moving an entire database, incremental replication focuses on changes that occur after the initial transfer. This can reduce unnecessary data movement and make recurring analytical refreshes more practical.

The announcement specifically highlights high-volume web and application workloads for PostgreSQL and MySQL.

For engineering teams, this means the database integration can become part of a repeatable ingestion architecture rather than a one-time migration script.

Apache Iceberg Extends the Data Lakehouse Model

Database ingestion is only one part of Google's expansion.

DTS can now ingest data directly into Apache Iceberg managed tables in preview.

The capability supports sources including Google Cloud Storage, Amazon S3 and Azure Blob Storage.

This matters because Iceberg has become an important table format for organisations operating across multiple storage and analytics environments.

Instead of forcing every dataset into a single proprietary storage architecture, Iceberg provides a table abstraction that can be used with multiple data processing and query technologies.

Google's announcement positions direct Iceberg ingestion as a way to maintain multi-cloud storage compatibility while using BigQuery's analytical capabilities.

For technology teams, this introduces another possible architecture pattern.

Object storage can remain distributed across cloud environments while ingestion into managed Iceberg tables is handled through DTS.

That can be particularly relevant for organisations operating hybrid or multi-cloud infrastructure.

The capability is currently marked as Preview, so enterprises considering production deployment need to evaluate its availability and operational limitations against their specific requirements.

MCP Brings Data Transfer Into Agentic Workflows

Another significant addition is the fully managed remote Model Context Protocol server, currently available in preview.

MCP has emerged as a mechanism for connecting AI applications and agents with external tools and data sources.

Google says the DTS MCP server allows developers to connect AI applications and agents to DTS so they can programmatically discover data sources and configure and execute transfers on a user's behalf.

This changes the role of a data transfer service.

Instead of an engineer manually configuring every transfer through a conventional interface, an AI application can potentially interact with the transfer service through an MCP-based interface.

For developers building agentic systems, this creates an integration point between AI applications and data infrastructure.

However, the announcement does not provide detailed information about the complete security model, permission workflows or operational boundaries of agent-initiated transfers.

Those details are important because allowing an AI agent to discover sources or configure data movement introduces a different class of infrastructure-control considerations.

The practical value will therefore depend not only on automation but also on how organisations implement identity, authorisation and governance around those operations.

Snowflake Migration Becomes a Managed Operation

Google has also made its Snowflake connector generally available.

The migration capability includes incremental transfer, automatic schema detection, private connectivity and support for Snowflake data hosted across Google Cloud, AWS and Azure.

For organisations moving workloads from Snowflake to BigQuery, these capabilities address several parts of the migration process.

Automatic schema detection can reduce manual schema configuration.

Incremental transfer can help with migration scenarios where the source continues changing during the transition.

Private connectivity addresses network architecture considerations for enterprise environments.

Support for Snowflake deployments across the three major cloud environments is also significant for organisations that do not operate Snowflake exclusively on one cloud provider.

The announcement does not provide a detailed migration methodology or migration performance benchmark, so organisations should still validate schema compatibility, workload dependencies and migration timelines against their own environments.

SaaS Connectors Expand Beyond Databases

The latest DTS expansion is not limited to relational databases.

Google has introduced preview connectors for Shopify, Klaviyo, HubSpot and Mailchimp.

These connectors target e-commerce and marketing data.

Shopify can transfer order histories, inventory information and customer profiles.

Klaviyo can transfer email and SMS engagement information, including clicks, sends and opens.

HubSpot can synchronise pipeline, contact tracking and inbound marketing metrics.

Mailchimp can transfer campaign performance and audience list attributes.

For database engineers, these integrations illustrate a broader trend in modern data platforms: analytical architectures increasingly need to combine operational databases with application-generated business data.

The data warehouse is no longer only a destination for structured database exports.

It can become a central analytical layer containing information from applications, databases, marketing systems, cloud storage and other operational sources.

Incremental Updates Are Becoming a Core Capability

Google has also enhanced ServiceNow, Salesforce and Oracle connectors with native incremental update support.

This is important because enterprise systems can contain extremely large datasets.

A pipeline that repeatedly reloads complete tables can become inefficient as the underlying dataset grows.

Incremental updates allow a transfer architecture to focus on changed records rather than treating every refresh as a complete migration.

For Salesforce and ServiceNow environments, this can support recurring analytical workflows without requiring the same amount of custom extraction logic.

Oracle support is particularly relevant for enterprise financial and operational systems where databases may contain large volumes of business-critical records.

The announcement does not disclose detailed throughput figures for these connectors.

Consequently, enterprises should not assume that incremental support automatically translates into a specific refresh performance level. Actual performance will depend on source characteristics, network conditions, transfer configuration and workload patterns.

Security Is Integrated With the Destination

Google positions security integration as another advantage of DTS.

The service integrates with Cloud IAM, while transferred data inherits security controls associated with the destination dataset.

The announcement specifically references Column-Level Security, Row-Level Security and Customer-Managed Encryption Keys.

This is important from an implementation perspective.

A data transfer architecture is not only responsible for moving data. It also needs to preserve the security model applied to the analytical destination.

By integrating with BigQuery's native security controls, DTS reduces the need to create a separate security layer around the transferred dataset.

Google also states that data streams operate inside the native Google Cloud perimeter.

For enterprise teams, this can simplify the architecture by reducing the number of external servers and security configurations required for data movement.

However, security still depends on correct identity and access configuration. A managed service does not remove the need to establish appropriate permissions, dataset policies and governance practices.

Cost Model Shifts From Pipeline Maintenance

Google also highlights cost efficiency as a major part of the DTS proposition.

The company says ingestion is free for first-party Google sources, with Google Play identified as an exception. It also lists Amazon S3, Azure Blob Storage, Amazon Redshift and Teradata among sources with no ingestion charge.

For third-party SaaS sources, Google describes a consumption-based model.

The announcement states that compute fees can run below six cents per slot-hour in major regions and says pricing scales with compute footprint rather than row volume.

This distinction is relevant for engineers designing large ingestion systems.

A row-based pricing model can make high-volume datasets difficult to predict when the number of records increases dramatically.

A compute-oriented model changes the cost calculation, although actual costs will still depend on workload characteristics and infrastructure usage.

The key implementation question for enterprises is therefore not simply whether ingestion is inexpensive, but whether the managed service produces a lower total operational cost than maintaining custom pipelines.

That includes engineering time, monitoring, infrastructure, maintenance and failure recovery.

What This Means for Technology Teams

The latest DTS capabilities point toward a more managed approach to enterprise data engineering.

For database engineers, the most immediate benefit is reduced custom integration work.

PostgreSQL and MySQL replication can be configured through a managed service, while SQL Server support provides another path for centralising transactional data.

For cloud engineers, the expansion creates a native mechanism for moving data between multi-cloud storage environments and BigQuery.

For data engineers, incremental transfers and new SaaS connectors can reduce the amount of extraction code required to maintain recurring ingestion workflows.

For AI engineers, the MCP capability introduces a potential programmatic interface through which agents can interact with data transfer operations.

And for platform teams, native IAM and BigQuery security controls can simplify governance compared with architectures that depend on multiple external ingestion services.

The Bigger Architecture Shift

The latest BigQuery DTS capabilities reflect a broader change in how enterprises are approaching data infrastructure.

Data ingestion is increasingly becoming a managed platform capability rather than an application that every engineering team must build independently.

The announcement combines several previously separate requirements: database replication, SaaS ingestion, cloud storage integration, migration, incremental updates and AI-driven interaction with data transfer infrastructure.

The significance is not that every organisation will immediately replace its existing pipelines.

Complex environments will continue to require custom transformation, orchestration and governance.

Instead, DTS provides a potential managed foundation for the movement layer of the architecture.

That distinction is important.

Data movement and data transformation are not the same problem. DTS primarily addresses movement and transfer, while organisations may still need other systems for transformation, quality management, business logic, orchestration and advanced data processing.

For engineering teams, the practical question is therefore where managed ingestion can replace custom infrastructure without sacrificing the controls and flexibility required by the organisation.

What Enterprises Should Evaluate

Before adopting the new capabilities, technology teams should evaluate several implementation areas.

First, they should identify which databases require full loading and which require continuous incremental replication.

Second, teams should review network connectivity requirements, particularly for on-premises databases and multi-cloud deployments.

Third, database administrators should evaluate the effect of replication workloads on production systems.

Fourth, security teams should verify IAM permissions and destination-level controls.

Finally, data teams should validate schema behaviour, update handling and downstream dependencies before moving production workloads.

Google has not disclosed detailed performance benchmarks for every new connector. As a result, enterprises should validate expected throughput, latency and cost using their own workloads.

Conclusion

Google's latest BigQuery Data Transfer Service expansion is fundamentally an infrastructure story.

The company is extending a managed ingestion layer across relational databases, cloud storage, SaaS platforms and migration workloads while adding support for AI applications through an MCP server.

For database-focused technology teams, PostgreSQL and MySQL reaching general availability are particularly significant because they bring managed replication of high-volume application workloads closer to the analytical environment.

The addition of SQL Server, Snowflake migration capabilities, incremental updates for major enterprise connectors and direct Iceberg ingestion broadens the architectural scope further.

The result is a more comprehensive approach to data movement in which teams can rely on managed connectors rather than building every integration themselves.

The broader industry shift is toward reducing the amount of infrastructure engineering required simply to make enterprise data available for analytics and AI.

For organisations evaluating modern data platforms, the important question is no longer only how data should be stored or queried. It is also how efficiently, securely and reliably that data can move between the systems where business applications create it and the platforms where teams analyse it.