Google Sheets Two-Way Sync with a Database: What It Is, How It Works, and How to Set It Up

Google Sheets two-way sync with a database means changes made in your spreadsheet automatically update the source database, and changes in the database automatically refresh your sheet: in both directions, in near-real time. It is fundamentally different from a one-way import or a manual export, and most tools on the market do not support it.

The Problem: Why "Syncing" Google Sheets Usually Means One Direction

Search for "Google Sheets sync with database" and you will find dozens of tutorials. Almost every single one covers the same scenario: pulling data from a database into Sheets. Click refresh, see new rows. That's it. What nobody covers is what happens when an analyst edits a cell and needs that change to flow back to the source.

Operations teams run into this wall constantly:

"Two way syncing is theoretically possible with proper spreadsheet design and proficient GApps skills. It would be similar to building a DBMS." (Google Support forum)

"Zapier only handles insert, not update: updating records is often a long and painful process. I basically gave up."

"Our sales team edits deal stages in Sheets because they hate the CRM UI. We want those edits to land back in HubSpot. Every solution I've tried is read-only."

The pain is real: people use Google Sheets as a lightweight UI on top of serious data systems. They want the flexibility of a spreadsheet without losing data integrity. And the market has largely ignored them.

What Two-Way Sync Actually Means

Before going further, it helps to be precise about terminology, because "sync" gets used loosely.

One-way import (read-only): Data flows from the database into Sheets on a schedule or on demand. You can view and analyze it, but any edits you make in the sheet are overwritten on the next refresh. This is what most connectors do.

One-way export (write-only): Data flows from Sheets into the database. A form submission tool like Tally or Typeform that appends rows to a sheet and then syncs to an Airtable base is one example. Useful for collection, not for back-and-forth collaboration.

Trigger-based (event-driven, not true sync): A tool like Zapier watches for a specific event (a new row added, a specific cell changed) and fires an action. This handles inserts reasonably well but struggles with updates and deletions. The state of the two systems can diverge between trigger events.

True two-way sync: Changes in Sheets propagate to the database. Changes in the database propagate to Sheets. Conflicts are detected and resolved by a defined rule. The two systems stay in agreement continuously. This is what operations teams actually want, and it is genuinely rare.

Why Two-Way Sync Is Hard to Build

It looks deceptively simple: "just write changes back." Here is why it is not.

1. Conflict Resolution

If a sales rep edits a deal value in Sheets at 2:03 PM, and an automated workflow updates the same deal in HubSpot at 2:04 PM, which value wins? There is no universal answer. Common strategies include:

• Last-write wins: Whoever edited most recently takes precedence. Simple, but can silently overwrite work.
• Source-of-truth wins: One system (usually the database) always wins on conflict. Sheets edits are suggestions, not commands.
• Manual resolution: The system flags the conflict and requires a human decision. Correct, but slow.

Most connectors that claim two-way sync do not document which strategy they use, which means you find out through lost data.

2. Primary Keys and Row Identity

A spreadsheet has no native concept of a primary key. Row 14 today might be a different record tomorrow if someone inserted a row above it. For a database to accept an update from Sheets, it needs to know which record to update. Without a stable identifier in a dedicated column, upsert logic fails or creates duplicates.

3. Data Type Mismatches

Databases enforce types. PostgreSQL will reject a string in an integer column. Google Sheets does not enforce anything: a user can type "N/A" into a numeric field. Every two-way sync system needs a translation and validation layer, or it will generate errors that are difficult to diagnose.

4. Delete Handling

What happens if a user deletes a row in Sheets? Should the corresponding record be deleted from the database? Hard-deleted or soft-deleted? Most tools either ignore deletions or require extra configuration. Getting this wrong causes data loss.

5. The Apps Script Execution Limit

If you try to build this yourself, you hit Google's 6-minute execution time limit for Apps Script functions. A large dataset with complex upsert logic can time out before finishing, leaving the sync in a partial state.

DIY: Building Two-Way Sync with Google Apps Script

It is possible to build a working two-way sync with Apps Script. It requires significant engineering effort, and the result is brittle. Here is an honest look at what it takes.

The Architecture You Need

A minimal implementation requires:

1. A primary key column in your sheet (e.g., record_id). Never omit this.
2. A "last modified" timestamp column in both the sheet and the database, updated automatically.
3. **An onEdit trigger** that captures cell changes and queues them.
4. A time-driven trigger (e.g., every 5 minutes) that processes the queue, calls your database API or JDBC connection, and performs upserts.
5. A separate pull trigger that fetches database changes since the last sync timestamp and writes them into the sheet.
6. Conflict detection logic that compares timestamps from both sides before writing.

What the Upsert Function Looks Like

The core write-back function needs to:

• Read every changed row from the queue
• Validate data types against the target schema
• Call INSERT ... ON CONFLICT (id) DO UPDATE SET ... (PostgreSQL) or INSERT INTO ... ON DUPLICATE KEY UPDATE ... (MySQL)
• Handle API rate limits and retry with exponential backoff
• Log successes and failures to a separate audit sheet

This is roughly 200–400 lines of JavaScript if done properly. It requires maintaining the script every time your sheet structure changes. If the Apps Script project has multiple contributors, merge conflicts in the script itself become a problem.

The Honest Assessment

Apps Script two-way sync works. Teams with a competent JavaScript developer and a low-frequency sync requirement (every 10–30 minutes is fine, every 30 seconds is not) can make it work without paying for a connector tool. The cost is developer time and ongoing maintenance.

For teams without dedicated engineering resources, or for use cases that require near-real-time sync or audit trails, a dedicated connector is a better investment.

Tools That Support Database Two-Way Sync

The market is still immature. Most connectors are read-only. A handful support write-back, and fewer still call it "two-way sync" with conflict handling.

Brooked.io

Brooked is built around database connectivity with write-back support. It connects to MySQL, PostgreSQL, and major SaaS platforms, and its two-way sync uses a primary key column to match records. Changes made in Sheets are queued and written back on a configurable schedule, with conflict logging. It also supports AI-powered natural language queries so non-technical users can filter and shape data without writing SQL. Pricing starts at $29/user/month.

The main limitation: Brooked's connector library is smaller than mature players like Supermetrics. It excels at database and SaaS integration but is not a marketing data aggregator.

Coefficient

Coefficient is one of the strongest two-way options for Salesforce and HubSpot users. Its write-back feature ("Coefficient Push") is well-documented and includes field mapping, validation, and error reporting. It also includes AI features for query generation. Pricing is roughly $83/user/month, which makes it expensive for small teams.

Coefficient's database connectivity is more limited than Brooked. It shines on CRM and SaaS, less so on raw SQL databases.

Whalesync

Whalesync focuses specifically on bidirectional sync between no-code databases. Airtable, Notion, Webflow, and similar tools. If your "database" is Airtable or Notion, Whalesync is worth evaluating. It does not connect to MySQL or PostgreSQL, so it is not the right fit for engineering teams.

Superjoin

Superjoin supports a growing list of connectors with scheduled refresh. Write-back is available for some sources. It is lighter-weight than Coefficient and better suited to smaller teams. Database connectivity is more limited.

Apps Script (DIY)

Free. Full control. Requires a developer. Covered above.

Comparison Table

Best Practices Before You Start

Whether you use a tool or build your own, follow these practices before turning on any two-way sync.

Add a primary key column and never touch it. Create a column named id or record_id and populate it with your database's primary key values. Protect this column in Sheets so users cannot edit or delete it accidentally. Every upsert operation depends on it.

Decide which system is the source of truth. Before going live, write down the answer to: "If both systems change the same field in the same sync window, which value wins?" Document it. Tell your team. Some connectors let you configure this; others do not.

Build an audit trail. Keep a log of every change written back to the database: what changed, who changed it, and when. A separate "Sync Log" sheet works. A proper audit table in the database is better. You will need this the first time something goes wrong.

Start with a subset of your data. Do not sync your entire production table on day one. Pick a non-critical table or a filtered view. Validate the behavior for a week before expanding.

Set up schema change alerts. If someone adds or removes a column from your database table, your sync will break. Set up monitoring or use a connector that handles schema drift gracefully.

Test deletions explicitly. Deliberately delete a row in Sheets and verify what happens in the database. Deliberately delete a record in the database and verify what happens in Sheets. Do this before your team uses the sync in production.

Troubleshooting and Common Pitfalls

Duplicates appearing in the database. Almost always caused by a missing or inconsistent primary key. The sync cannot match the incoming row to an existing record, so it inserts instead of updating. Fix: verify the id column is populated in every row and that the connector is configured to use it for upserts.

Changes in Sheets not syncing back. Check whether the connector requires a manual "push" step or runs on a schedule. Some tools require you to select changed rows and click a button. Others run automatically but on a delay. Check the sync log for errors.

Data type errors blocking writes. A cell formatted as text cannot write to an integer column. Check your sheet's column formatting and ensure date columns use a consistent format (ISO 8601 (YYYY-MM-DD) is safest for cross-system compatibility).

Apps Script timeouts on large sheets. If your script times out, implement pagination: process 500 rows per execution rather than the entire sheet. Use PropertiesService to store the last processed row index between runs.

Conflict loops. System A updates a record, which triggers System B to update it, which triggers System A to update it again. This is called a sync loop. Prevent it by having your write-back logic check whether the incoming value is different from the current value before writing, and by setting a "sync source" flag on writes so the other system knows not to re-sync them.

Missing rows after a sync. If your conflict resolution rule is "database wins" and a row exists in Sheets but not in the database, it may be deleted from Sheets on the next pull. This is correct behavior but surprises people. Document it.

The Bottom Line

Two-way sync between Google Sheets and a database is not a myth, but it is not a checkbox either. It requires solving three real problems: primary key management, conflict resolution, and data type validation. Most connectors on the market have avoided this complexity by staying read-only. The ones that do support write-back vary significantly in how well they handle conflicts and errors.

For teams with developer resources, Apps Script is a viable starting point, but plan for maintenance overhead. For teams that need a reliable, no-code solution with database support and conflict logging, the field is narrow but growing.

The right choice depends on your data volume, your change frequency, and how much you can tolerate inconsistency during sync windows. Start small, document your conflict resolution policy before you flip the switch, and build an audit trail from day one.

Try It Without Committing

If you want to see what two-way database sync actually looks like before building anything, brooked.io offers a free trial with direct MySQL and PostgreSQL connectivity and write-back support. Connect a non-production table, make a few edits in Sheets, and watch the sync log. It is the fastest way to understand the mechanics without writing a line of Apps Script.

Frequently asked questions