Google Drive to Amazon Redshift: How to Move Your Data

Moving Google Drive into Amazon Redshift turns a shared folder into queryable tables inside an AWS estate. Partner extracts, exported reports and files somebody drops in every week are invisible to your warehouse until something loads them, and Drive is where a great deal of that material already sits.

Two things shape the build. A Google Doc or Sheet is not a file in the ordinary sense and arrives as a conversion rather than structured rows, and Redshift cannot be loaded without a staging bucket, which puts an AWS prerequisite in front of a Google source.

Google Drive to Amazon Redshift at a glance:

Why move data from Google Drive to Amazon Redshift?

Two situations account for most of these pipelines.

The first is a cross-cloud reality. Your colleagues work in Google Workspace and your analytical estate runs on AWS, so files land in Drive and need to reach Redshift. That is a bridge rather than a choice anybody made deliberately, and it is the common case here.

The second is automating a manual step. A partner shares a folder, a system exports to it nightly, and somebody currently downloads those files and uploads them somewhere else by hand. If the folder holds Google Docs rather than data files, read the section on native formats before planning anything.

What do you need before you start?

One task belongs to somebody else, and one is an AWS prerequisite you cannot skip:

Authentication, and a folder shared with it. OAuth is recommended on Airbyte Cloud and simplifies the setup considerably. On self-managed deployments you create a service account key, and then somebody must give that service account access to the folder, exactly as they would a colleague. The Google Drive source documentation covers both routes.

The folder link and a glob pattern per stream. Copy the folder URL from the Drive interface. Format is configured per stream rather than per file, so a folder containing several file types needs patterns selecting only the files matching each format, relative to that root.

An S3 staging bucket and IAM permissions. The Redshift destination writes data to S3 as files with a manifest, then issues a COPY command, which is Redshift's own recommended approach. You need put, get, delete and list on the bucket, in the same region as the cluster.

Redshift entities created in advance. A database, a schema and a user able to write data and manage staging operations. Airbyte writes into two schemas, the one you nominate and a raw schema it manages, so tell whoever reviews your Redshift objects that the second is expected.

Note also that an SSH tunnel covers the SQL connection only. Staging traffic reaches S3 over HTTPS regardless, so a network design assuming everything passes through a bastion is wrong.

How do you build a Google Drive to Amazon Redshift pipeline in Airbyte?

Step 1: Look at what is actually in the folder

Open the folder and note the file types, because that determines everything downstream. A folder of CSV exports is a straightforward structured pipeline. A folder of Google Docs and Sheets is a document extraction problem, and the two have little in common beyond both living in Drive.

Step 2: Configure the Google Drive source

Click Sources in the left navigation, then New Source, and select Google Drive, following adding a source. Authenticate, paste the folder link, then define a stream for each file format you need with a name and a glob pattern selecting only files of that type.

Step 3: Configure the Redshift destination

Click Destinations, then New Destination, and select Redshift, following adding a destination. Supply the cluster host, database, schema and credentials, along with your S3 bucket and IAM key. Staging files are removed after a successful COPY by default, and can be retained if you need them for debugging.

Step 4: Create the connection and set your keys

Click Connections, then New connection, select your streams and an incremental sync mode so new files are picked up without re-reading what has already been processed. Set the frequency against how often files actually land, and set sort keys on whatever date column your queries filter by.

Check the resulting table after the first sync, particularly with CSV, since that format carries no type information and the connector has to infer what each column contains.

What happens to Google Docs and Sheets?

They get converted on the way out, because Google-native files are not stored as files in the ordinary sense. Google Docs are exported as Docx to preserve as much formatting as possible, and other exportable Google formats go through PDF. What reaches your pipeline is that export rather than the original.

The consequence catches people out with Sheets specifically. A Google Sheet looks like a table, so it is natural to assume it arrives as rows in Redshift. It does not, because it is handled as a document rather than as structured data, and the result is text rather than typed columns.

That matters more on a row-oriented warehouse than elsewhere, because Redshift is a poor place to keep document text you then have to parse. If your folder is full of Sheets, the Google Sheets connector reads them as tabular data directly, and if you want the prose, a search index or vector store is the better destination.

Why does a Google source need an AWS bucket?

Because the requirement comes from the destination rather than the source. Redshift is designed to be loaded in bulk from S3, so the connector writes files with a manifest and then issues a COPY command pointing at them. That is Redshift's own recommended path and there is no direct insert alternative.

So a pipeline moving files from Google storage acquires a second storage dependency on another cloud, which reads as odd and is simply how Redshift works. Budget for a bucket in the same region as your cluster, IAM credentials with four permissions on it, and whatever approval your organisation requires for new storage.

It also affects your network design, since an SSH tunnel covers the SQL connection to the cluster and not the staging traffic. If your security model assumes all traffic passes through a bastion, that assumption needs revisiting before somebody discovers it in a review.

Frequently asked questions

Will a Google Sheet arrive as a table in Redshift?

No. Google-native files are converted on export, with Docs becoming Docx and other formats going through PDF, so a Sheet is handled as a document. Use the Google Sheets connector for tabular data.

Do I need an S3 bucket to load into Redshift?

Yes. The destination stages data in S3 and loads it with COPY, which is Redshift's recommended approach, even though the source is a Google product. Put the bucket in the same region as your cluster.

Why is my sync returning nothing?

On a service account, check the folder has actually been shared with it. Then check your glob pattern, since it is relative to the root folder you specified.

Why is there an extra schema in my cluster?

Airbyte writes to your target schema and to a raw data schema it manages to improve reliability. Both are expected.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven, including the glob patterns. You may want Redshift views casting CSV columns, since that format carries no type information.

Get your Google Drive data into Amazon Redshift

Set up the staging bucket early, because a Google source needing AWS storage surprises people. Look in the folder first since CSVs and Google Docs are different projects, share the folder explicitly, write glob patterns per format, and use the Google Sheets connector if what you want is tabular data.

Airbyte's connector catalog includes 700+ pre-built connectors, so file feeds can reach a warehouse alongside the systems they describe. For the same source in another warehouse, see Google Drive to Snowflake, and for a similar file source, SFTP to PostgreSQL.

Start syncing now →