How to Connect SQL Server to Google Sheets Without SSRS, SSIS, or a DBA

You can connect SQL Server to Google Sheets in three ways: manual CSV export (no setup, not repeatable), Apps Script JDBC (free, requires port access and SQL auth), or a third-party connector like brooked.io (automated, no firewall changes needed). This guide covers all three, including the enterprise pain points. ODBC dead ends, Windows Authentication blocks, named instance resolution, and Azure SQL firewall rules. That most tutorials skip entirely.

Why SQL Server Is Harder Than Other Databases

Most database-to-Google Sheets tutorials assume you are working with a cloud-native database like PostgreSQL on a public endpoint, a MySQL instance with a whitelisted IP, or a managed service where credentials are straightforward. SQL Server breaks almost every one of those assumptions.

SQL Server was designed for the Windows enterprise ecosystem. It was built to live inside a corporate network, authenticate via Active Directory, and be accessed by Windows applications that understand NTLM and Kerberos. Google Sheets is a cloud application that understands none of those things.

The result is a set of failure modes that are unique to SQL Server:

• SSRS and SSIS dependency: Many organizations that want live data in Sheets have historically relied on SQL Server Reporting Services or SQL Server Integration Services to move data around. Both tools require a DBA to configure, neither produces a live Google Sheets connection, and both require on-premises infrastructure that most modern workflows are trying to move away from.
• ODBC is a dead end for cloud apps: ODBC drivers let Windows desktop applications talk to SQL Server. They do not help you connect a cloud application like Google Sheets to SQL Server. There is no ODBC bridge that runs in the cloud and reaches your on-premises SQL Server instance without additional infrastructure.
• Windows Authentication is not supported: Any connector that runs outside your corporate network (which includes every cloud connector and Google's own Apps Script) cannot use Windows Authentication. It cannot participate in your Active Directory domain. SQL Server Authentication (username and password) must be enabled on your SQL Server instance, and a SQL login must be created, before any cloud connectivity is possible.
• Named instances use dynamic ports: If your SQL Server runs as a named instance (the classic example is SQLEXPRESS\SQLEXPRESS or SERVER\INSTANCE), it may not be listening on port 1433. Named instances use the SQL Server Browser Service to dynamically assign ports. Cloud connectors cannot query the Browser Service. You need to find the actual TCP port your named instance is using and open that port in your firewall.
• Port 1433 firewall complexity: On-premises SQL Server instances are almost never exposed to the internet. Getting port 1433 (or your named instance port) reachable from the cloud means working with your network team, your firewall vendor, and potentially your ISP, and it introduces real security considerations.

The ODBC Dead End (and Why It Doesn't Work)

If you search for how to connect SQL Server to Google Sheets, you will find suggestions involving ODBC. Specifically, some tutorials describe installing an ODBC driver on your Windows machine and then somehow using it from Google Sheets. This does not work for any live, automated connection.

ODBC is a local driver architecture. The ODBC driver sits on the machine where the application runs. Google Sheets runs on Google's servers. You cannot install an ODBC driver on Google's servers.

What ODBC can do: let a desktop application like Excel, Power BI Desktop, or a custom Windows app connect to SQL Server from the same network. What it cannot do: give a cloud application like Google Sheets direct access to your database.

The only partial exception is if you are running a custom middleware server that exposes your SQL Server data via a REST API, but at that point, you are building infrastructure, not installing a connector.

Windows Authentication and Active Directory

Windows Authentication (also called Integrated Security) is the default authentication mode for SQL Server in enterprise environments. It works by having SQL Server trust the Windows user account running the client application. When you connect from SQL Server Management Studio on your domain-joined laptop, Windows Authentication works smoothly.

Cloud connectors cannot use Windows Authentication. They are not on your domain. They cannot be issued a Kerberos ticket. They cannot authenticate as a domain user.

Before you can connect SQL Server to Google Sheets through any method other than CSV export, you need to:

1. Enable Mixed Mode Authentication on your SQL Server instance (this allows both Windows Authentication and SQL Server Authentication). This setting is in SQL Server Configuration Manager or can be set via T-SQL with EXEC xp_instance_regwrite.
2. Create a SQL Server login with a username and password. In SSMS: Security > Logins > New Login. Set "SQL Server authentication," assign a strong password, uncheck "Enforce password expiration" if your connector does not rotate passwords.
3. Grant that login access to the target database and the necessary SELECT permissions on the tables or views you want to query.
4. Restart the SQL Server service after enabling Mixed Mode Authentication.

If you are on Azure SQL Database, Mixed Mode Authentication is enabled by default. Azure SQL always uses SQL Authentication (or Azure Active Directory, which is a separate mechanism with some connector support).

Named Instance and Port Resolution

SQL Server named instances are a common source of connection failures when integrating with cloud tools.

A default SQL Server instance listens on TCP port 1433. A named instance (like HOSTNAME\SQLEXPRESS) does not. It registers with the SQL Server Browser Service on UDP port 1434 and gets a dynamically assigned TCP port. That port is consistent across restarts (usually), but it is not 1433.

To find the port your named instance is using:

1. Open SQL Server Configuration Manager.
2. Expand "SQL Server Network Configuration."
3. Click "Protocols for [instance name]."
4. Right-click "TCP/IP" and select "Properties."
5. Click the "IP Addresses" tab.
6. Scroll to "IPAll" at the bottom. The "TCP Port" field shows the port in use. If it is blank, check "TCP Dynamic Ports."

Once you have the port, open that port in your Windows Firewall and any network firewall between the SQL Server machine and the internet. When configuring your connector, use the explicit port rather than the instance name syntax. Most cloud connectors expect a host and port, not the HOSTNAME\INSTANCE format.

Method 1: Manual CSV Export

Best for: One-time data pulls, ad hoc analysis, situations where automation is not required.

How it works:

1. Open SQL Server Management Studio (SSMS).
2. Write your query and execute it.
3. Right-click the results grid and select "Save Results As."
4. Save as CSV.
5. Open Google Sheets, go to File > Import, and upload the CSV.

Limitations: This is a completely manual process. The data in your Sheet is a snapshot frozen at the time of export. Any updates to the underlying SQL Server data require repeating the entire process. There is no scheduling, no automation, and no live connection.

This method is appropriate for generating a one-time report or doing exploratory analysis, but it is not a solution for ongoing reporting or dashboards.

Method 2: Apps Script JDBC

Best for: Teams comfortable with JavaScript who want a free, automated solution and can open firewall access.

Google Apps Script includes a built-in JDBC service that supports Microsoft SQL Server via the jTDS driver. This is a legitimate, working approach, but it requires that your SQL Server instance be reachable from Google's IP ranges on the correct TCP port.

Step 1: Confirm Prerequisites

• SQL Server Authentication is enabled and you have a SQL login with a password.
• The SQL Server TCP port (1433, or your named instance port) is open to inbound connections from the internet, or specifically from Google's IP ranges (published at goog.json in Google's IP ranges documentation).
• You are using a hostname or IP address, not a Windows Authentication connection.

Step 2: Open Apps Script

In your Google Sheet, go to Extensions > Apps Script.

Step 3: Write the Connection Script

Below is a complete, working Apps Script function for SQL Server. Replace the placeholder values with your actual credentials.

function importFromSQLServer() {
  // Standard SQL Server (on-premises or EC2)
  var conn = Jdbc.getConnection(
    'jdbc:sqlserver://YOUR_SERVER_IP_OR_HOSTNAME:1433;databaseName=YOUR_DATABASE',
    'your_sql_login',
    'your_password'
  );

  // Azure SQL Database
  // var conn = Jdbc.getConnection(
  //   'jdbc:sqlserver://yourserver.database.windows.net:1433;databaseName=YOUR_DATABASE;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30',
  //   'your_sql_login@yourserver',
  //   'your_password'
  // );

  // Amazon RDS for SQL Server
  // var conn = Jdbc.getConnection(
  //   'jdbc:sqlserver://yourinstance.xxxx.us-east-1.rds.amazonaws.com:1433;databaseName=YOUR_DATABASE',
  //   'your_sql_login',
  //   'your_password'
  // );

  var stmt = conn.createStatement();
  var results = stmt.executeQuery('SELECT * FROM your_schema.your_table LIMIT 1000');
  var metaData = results.getMetaData();
  var numCols = metaData.getColumnCount();

  var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Sheet1');
  sheet.clearContents();

  // Write header row
  var headers = [];
  for (var i = 1; i <= numCols; i++) {
    headers.push(metaData.getColumnName(i));
  }
  sheet.appendRow(headers);

  // Write data rows
  while (results.next()) {
    var row = [];
    for (var j = 1; j <= numCols; j++) {
      row.push(results.getString(j));
    }
    sheet.appendRow(row);
  }

  results.close();
  stmt.close();
  conn.close();
}

Step 4: Schedule the Script

In Apps Script, click the clock icon (Triggers) to set up a time-driven trigger. You can run the script hourly, daily, or on any schedule Google supports.

Limitations of Apps Script JDBC

• Requires a publicly accessible SQL Server endpoint. Many organizations cannot or will not open firewall access.
• Row-by-row appendRow() calls are slow for large datasets. For tables with more than a few thousand rows, use setValues() with a batched array instead.
• No built-in error alerting. Failed runs are silent unless you add error handling.
• Apps Script has a 6-minute execution timeout. Very large queries will fail.
• SQL Server Note: Use TOP 1000 in your query rather than LIMIT 1000. SQL Server uses TOP, not LIMIT.

Method 3: Third-Party Connectors

Best for: Teams that want reliable, automated, scheduled syncs without managing firewall rules or writing code.

Third-party connectors handle authentication, scheduling, schema mapping, and error handling. The main options for SQL Server to Google Sheets are:

brooked.io: Purpose-built for connecting databases to Google Sheets. Supports SQL Server, Azure SQL, and RDS for SQL Server. Uses a secure tunnel architecture so you do not need to open firewall ports to the internet. Schedules syncs automatically. Handles named instances with explicit port configuration. Free tier available.

Coefficient: A Google Sheets add-on that supports multiple data sources including SQL Server. Operates as a Sheets sidebar. Requires direct database access (public endpoint or VPN). Better suited for self-service BI use cases.

Skyvia: Cloud-based ETL tool with SQL Server support. More configuration overhead but handles complex transformation logic well. Not Google Sheets-native.

Connector Comparison Table

Azure SQL Firewall Configuration

If your SQL Server is hosted on Azure SQL Database, firewall rules are managed in the Azure Portal rather than at the network or OS level.

To allow a specific IP address (for Apps Script or a known connector IP):

1. Go to the Azure Portal and open your SQL Server resource (not the database. The server).
2. In the left navigation, select "Networking" (previously called "Firewalls and virtual networks").
3. Under "Firewall rules," click "Add a firewall rule."
4. Enter a rule name, start IP, and end IP. For a single IP, set both start and end to the same address.
5. Click "Save."

To allow Azure services (required for Apps Script JDBC to Azure SQL):

On the same Networking page, enable "Allow Azure services and resources to access this server." This allows connections from any Azure-hosted service, which includes Google Apps Script (Google's infrastructure runs in the cloud, and its IP ranges are treated as coming from the internet, not from Azure, so this toggle may not be sufficient). For Apps Script specifically, you need to whitelist Google's IP ranges or use a connector that handles this for you.

To find Google's IP ranges for whitelisting:

Google publishes its IP ranges. The relevant ranges for Apps Script are in the _spf.google.com TXT records or in Google's published JSON. This list changes over time, making static whitelisting fragile. A connector like brooked.io avoids this problem entirely by using a stable IP or a tunnel that does not require whitelisting Google's dynamic ranges.

For Azure SQL with private endpoint:

If your Azure SQL instance uses a private endpoint (accessible only within a VNet), you cannot connect from the public internet without additional infrastructure like a VPN gateway or Azure Relay. A connector with a native tunnel capability is the practical solution in this scenario.

Pushing Data the Other Way: Google Sheets to SQL Server

The reverse direction (writing data from Google Sheets into SQL Server) is a legitimate use case. Common scenarios include:

• Sales teams updating a pipeline tracker in Sheets that needs to sync back to the CRM database.
• Operations teams using Sheets as a lightweight data entry form that feeds a SQL Server back-end.
• Finance teams entering budget data in Sheets that needs to land in SQL Server for consolidation.

Apps Script approach: The same JDBC connection used for reading can be used for writing. Replace executeQuery() with execute() for INSERT, UPDATE, or DELETE statements. Build the SQL statement from the row data in your Sheet. Be careful about SQL injection: use PreparedStatement rather than string concatenation.

brooked.io: Supports bidirectional sync. Changes made in the Google Sheet are detected and written back to SQL Server on the next sync cycle. No code required.

Coefficient: Supports write-back for some data sources. Check current documentation for SQL Server write-back status.

Consideration for write operations: Writing from Sheets to SQL Server requires the SQL login to have INSERT/UPDATE/DELETE permissions, not just SELECT. Ensure your login has the appropriate grants on the target tables.

Troubleshooting

"Connection refused" or timeout on port 1433 SQL Server is not accepting remote connections, or the port is blocked by a firewall. Verify: (1) SQL Server is configured to accept TCP/IP connections (SQL Server Configuration Manager > Protocols > TCP/IP must be Enabled). (2) The Windows Firewall has an inbound rule allowing TCP on port 1433. (3) Any network firewall between the client and SQL Server allows port 1433.

"Login failed for user" error SQL Server Authentication mode may not be enabled, or the login credentials are wrong. Verify Mixed Mode Authentication is enabled and the SQL login exists with the correct password.

"Cannot connect to named instance" or instance name resolution failure Named instances require explicit port configuration. Find the actual TCP port (see the Named Instance section above) and use hostname:port format instead of hostname\instance format in your connection string.

Apps Script runs but returns no data Check that your query returns results when run directly in SSMS. Verify the table and schema names are correct (SQL Server is case-insensitive by default but schema names matter). Confirm the SQL login has SELECT permission on the queried objects.

Azure SQL connection works from SSMS but not from Apps Script Azure SQL firewall rules are blocking the connection. Add a firewall rule for the IP address Apps Script is connecting from. Because Apps Script uses Google's IP ranges (which vary), static whitelisting is unreliable. Consider using brooked.io instead.

Execution timeout in Apps Script Your query is returning too many rows or taking too long. Add a TOP 10000 clause to your query, or add pagination logic. Apps Script has a hard 6-minute execution limit.

Bottom Line

Connecting SQL Server to Google Sheets is harder than connecting most other databases, because SQL Server was built for the Windows enterprise world and Google Sheets lives entirely in the cloud. The two environments do not share authentication models, networking assumptions, or tooling conventions.

If you need a one-time data pull, export a CSV and import it into Sheets. It takes five minutes and requires nothing else.

If you are comfortable with JavaScript and your organization will open port 1433 to the internet (or to Google's IP ranges), Apps Script JDBC is a free and capable solution. The connection strings in this guide will get you connected to on-premises SQL Server, Azure SQL, and RDS for SQL Server.

If you want automated, scheduled syncs without firewall changes, without code, and without involving your DBA or network team, a connector like brooked.io is the right tool. Setup takes about 15 minutes and the connection updates on a schedule automatically.

Get Connected in 15 Minutes

Connect SQL Server to Google Sheets with brooked.io, no firewall changes, no code, no DBA required. Set up a scheduled sync from your SQL Server, Azure SQL, or RDS instance to any Google Sheet in under 15 minutes.

Related Guides

• How to Connect Amazon Redshift to Google Sheets
• How to Connect PostgreSQL to Google Sheets
• How to Connect MySQL to Google Sheets
• Google Sheets Database Sync: The Complete Guide

Troubleshooting quick reference

Frequently asked questions