How to Connect Amazon Redshift to Google Sheets

Fastest path: install the Amazon Redshift connector for Google Sheets, paste in your cluster endpoint and credentials, and you have live query results in a sheet in under 10 minutes, with scheduled refresh and two-way write-back included. If you'd rather stay AWS-native, the official path is UNLOAD to S3 and import the CSV, which takes about 20 minutes and is a one-time snapshot rather than a live connection. This guide covers both, plus Apps Script, BigQuery federation, the reverse direction (Sheets back into Redshift), and what to do if you actually need Excel.

Evaluating more than one warehouse? The same Brooked setup covers Snowflake and Databricks, and you can weigh price and two-way sync against the usual pick in Brooked vs Coefficient.

Quick comparison: 4 ways to get Redshift data into Sheets

A sheet-sized query, before you pick a method

Whichever method you use, keep the result sheet-sized rather than pulling a raw fact table. A simple pattern that works well for dashboards and finance reviews:

1SELECT2  date_trunc('day', event_time) AS day,3  acquisition_source,4  COUNT(DISTINCT user_id) AS daily_active_users5FROM analytics.events6WHERE event_time >= dateadd(day, -56, current_date)7GROUP BY 1, 28ORDER BY 1 DESC9LIMIT 500;

Aggregate and filter in SQL rather than in the sheet. Redshift is much faster at grouping millions of rows than Sheets is at recalculating formulas over them, and a LIMIT keeps you comfortably under the 10-million-cell ceiling Sheets imposes per spreadsheet.

Step 0: Find your Redshift credentials in AWS

Whatever method you pick, you need the same five things from AWS. This is the most common 30-minute time sink for first-time connectors, and no top SERP result tells you exactly where to find each value.

• Endpoint / Host: AWS console → Redshift → Clusters → click your cluster → Properties tab → Endpoint. Format: cluster-name.region-id.redshift.amazonaws.com. Strip the :5439/database suffix if it's appended.
• Port: 5439 by default for provisioned clusters and Redshift Serverless. Confirm in the same Properties tab.
• Database name: Redshift creates a default 'dev' database. Your team's data is usually in a different DB, check Clusters → your cluster → Databases.
• Username: the database user, not your AWS console user. Find existing users via Query editor v2 → Databases → Users, or create a new one with CREATE USER sheets_reader PASSWORD 'value'.
• Password: set when the user was created. If lost, reset with ALTER USER sheets_reader PASSWORD 'value' from a privileged session.

Redshift Serverless is different. Endpoint format is workgroup-name.account-id.region.redshift-serverless.amazonaws.com, and IAM database authentication is the default. Most Sheets connectors expect username/password, so create a password-auth user explicitly: CREATE USER sheets_reader WITH PASSWORD 'YourPassword', then GRANT SELECT ON ALL TABLES IN SCHEMA public TO sheets_reader.

Step 0.5: Allow inbound traffic from the connector

This is the single most common silent failure. If your cluster is in a private VPC (most production setups are), no connector tool can reach it without an inbound rule on the cluster's security group. AWS console → EC2 → Security Groups → find the SG attached to your cluster → Inbound rules → Add rule: Type Redshift, Protocol TCP, Port 5439, Source the connector's IP range.

Brooked publishes its outbound IP ranges in the help docs; pin those in the Source field rather than 0.0.0.0/0. If your cluster has no public endpoint and lives entirely in a private VPC, no Sheets-side connector can reach it directly, so you'll need a VPN, AWS Direct Connect, or a bastion host with an SSH tunnel. If the cluster is publicly accessible (Publicly accessible Yes in cluster properties), the IP rule alone is enough.

For Apps Script users: Google does not publish a stable IP range, so you cannot pin to a specific source. The honest options are to open the security group to all IPs (bad for production), put a proxy in front (e.g. a Lambda using the Redshift Data API), or move to a connector that uses fixed IPs you can whitelist.

Method 1: UNLOAD to S3 → CSV → Sheets

The AWS-native path. From Redshift: UNLOAD ('SELECT … FROM …') TO 's3://your-bucket/dump_' CREDENTIALS '…' CSV HEADER; Then either download the CSV manually or wire up a Lambda + EventBridge to deliver it to a Google Drive folder for IMPORTRANGE pickup. This is the AWS official answer.

Pros: Free (only S3 storage), handles arbitrarily large dumps, native AWS. Cons: Snapshot only. Wiring up the S3 → Sheets bridge is non-trivial. IAM permissions, role assumption, and credential rotation are real ongoing work.

Method 2: Apps Script + Postgres JDBC

Redshift speaks the Postgres wire protocol. Apps Script's Jdbc service can connect with a Postgres-style JDBC URL (jdbc:postgresql:// cluster-endpoint:5439/db). Write a function, run it, schedule with time-driven triggers.

Pros: Free, customizable, no third party. Cons: Apps Script's 6-minute execution limit. Apps Script's IP ranges aren't well-documented and change, so security group inbound rules are a moving target.

Method 3: BigQuery federation via Omni

Google's BigQuery Omni can federate queries to Redshift directly. From BigQuery you can write a query that runs against Redshift. Then Sheets' native BigQuery connector pulls the result. This is useful if you're already a heavy BigQuery shop and Redshift is one of multiple warehouses you query.

Pros: Cross-warehouse queries from a single SQL surface. Cons: Omni pricing is on top of BigQuery pricing. Heavyweight for "I just want Redshift data in a sheet".

Method 4: A Google Sheets add-on (Brooked)

Brooked connects to Redshift directly, runs queries on demand, holds the connection across refreshes, and ships two-way write-back plus the AI agent. Setup is under 10 minutes including security group configuration. See the Amazon Redshift connector for Google Sheets page for the full feature list and pricing.

Step 1: Install Brooked

Install from the Workspace Marketplace. Free tier covers 100 imports/month with AI Analyst.

Step 2: Connect Redshift

In the Brooked sidebar, click Add data source → Amazon Redshift. Paste your cluster endpoint (or Serverless workgroup endpoint), port 5439, database, username, and password. SSL is on by default. Click Test connection.

Almost always you'll need to allow Brooked's egress IPs through your VPC security group. Brooked's sidebar surfaces the exact IPs to allow-list during this step.

Step 3: Run a query, pick a destination, schedule refresh

Click New import, write your SQL (or browse the schema and pick a table to auto-generate a SELECT), pick a destination range, click Import. Toggle Auto-refresh in settings and pick a cadence (15 min / hourly / daily / weekly).

Step 4: Two-way write-back (optional)

For writing data from the sheet back to Redshift, click 'Convert to two-way sync' on any import. Map columns, pick a primary key, pick write mode (INSERT, UPDATE, UPSERT compiled to DELETE+INSERT, or DELETE). Every write is captured in an audit log.

Google Sheets to Redshift (the reverse direction)

Plenty of teams search for this the other way around: they have data living in a sheet, a manually maintained budget, a list uploaded by a vendor, form responses, and need it in Redshift for joins against warehouse tables. Two paths:

Brooked's two-way sync (above) is the fastest route if you're already using Brooked for the Redshift-to-Sheets direction: flip any import to two-way, and edits in the sheet write back via INSERT/UPDATE/UPSERT. This is the right choice for ongoing, human-edited data that needs to land in Redshift regularly.

Manual COPY from S3 is the AWS-native route for one-off or bulk loads: export the sheet as CSV (File → Download → CSV), upload it to an S3 bucket, then run COPY target_schema.target_table FROM 's3://your-bucket/file.csv' CREDENTIALS '…' CSV IGNOREHEADER 1; into a staging table, and merge into the target with MERGE or a DELETE+INSERT pattern. This is more steps but needs no third-party connector, useful for a single large historical backfill rather than a recurring sync.

Loading Google marketing data into Redshift (Search Console, Ads, GA4)

A related question lands on this page often: how do I get Google Search Console, Google Ads, or Google Analytics data into Redshift? None of these have a first-party Redshift connector, but the paths are short. For Google Analytics 4 and Google Ads, Amazon AppFlow has managed source connectors that write into Redshift on a schedule, with no pipeline to build. For Search Console there is no AppFlow connector: pull the data into Google Sheets first (the official GSC add-on or the API), then push it to Redshift with two-way sync or an S3 COPY load. Files sitting in Google Drive follow the same CSV → S3 → COPY route. When volumes outgrow a spreadsheet, a dedicated ETL tool is the honest answer.

Using the AI agent with Redshift

Open the Chat tab. Ask: "What's our daily active user trend over the last 8 weeks?" The agent introspects your schema, writes the SQL, runs it on your cluster, and lands the result in the sheet. For follow-up analysis the SQL layer can't easily do, cohort retention, statistical tests, projections, the agent drops into a Python sandbox with pandas pre-loaded.

Brooked AI, Redshift

Live

Ask anything about your Redshift data…

Redshift to Excel

Brooked is Sheets-native. For Excel, AWS publishes the Amazon Redshift ODBC driver: install locally, configure a DSN, use Excel's Data → Get Data → From ODBC. This is the AWS official Excel path. It works but every analyst needs the driver installed. Coefficient also supports Redshift for Excel on its Premium tier. Most teams that try live-Excel with Redshift settle on Brooked + .xlsx export for the snapshot use case, connecting once via the Amazon Redshift connector for Google Sheets, then export any sheet to .xlsx for the handful of people who need Excel specifically.

Redshift to Looker Studio

Looker Studio ships a native Amazon Redshift connector (Create → Data source → Amazon Redshift), and it's the right pick for dashboards that read straight off the warehouse. The Sheets bridge still matters when a report mixes warehouse data with manual inputs: pull Redshift into Sheets on a refresh schedule, do the spreadsheet work, and point Looker Studio at the sheet. Teams on Looker (the BI platform) can also pull Looks and Explores into Sheets directly with Brooked.

The verdict: which method when

• I need a one-time bulk dump

  → UNLOAD to S3 → CSV → Sheets. AWS native, free, handles arbitrarily large result sets without Apps Script timeouts.

• I want a single query refreshed daily

  → Apps Script + JDBC. Free, customizable, can be scheduled. Fine if you don't mind maintaining the script.

• I want live Redshift data across many queries with no script

  → Brooked. Visual SQL editor, scheduled refresh, two-way write-back, AI agent, all without owning code.

• I want to ask Redshift questions in plain English

  → Brooked. The agent introspects your schema, writes the SQL, runs it on your cluster, and lands results in the sheet.

Troubleshooting common issues

Related Articles

• How to Connect Amazon Redshift to Google Sheets (VPC Security Group Setup Included)
• How to Connect SQL Server to Google Sheets Without SSRS, SSIS, or a DBA
• Google Sheets to SQL Server: How to Push Data FROM Sheets INTO Your Database

Frequently asked questions