How I dropped my sync time to 0.5s on a 40k row app by fixing a hidden "Address" bottleneck!

Hey AppSheet Community!

I wanted to share a massive performance breakthrough I just had. If you have mysteriously long sync times and your Performance Analyzer points to “Compute virtual columns”, even when you think you don’t have any heavy virtual columns—this might save your app!

The Problem

I’m running an app with a MySQL backend containing around 40,000 rows across several tables (Contacts, Projects, Invoices, etc.). My sync time was lagging.

When I looked at the Performance Analyzer, it showed 7.5 seconds being spent on “Compute virtual columns” for my Contacts table. The weird part? I had already cleaned up all my heavy SELECT() expressions and removed unnecessary Related... reference lists. My table only had physical columns.

The Investigation & The “Aha!” Moment

I dug deeper into the Performance Analyzer and unchecked the “Standard view” box. That’s when the hidden culprit revealed itself:

[internal] GeoCodeAddressColumn

Here is what was happening: If you set a physical column to the Address type, AppSheet automatically creates a hidden internal virtual column to geocode that text into GPS coordinates via Google Maps. Because it acts like a virtual column, it triggers on EVERY sync. It was literally trying to re-evaluate 10,000+ addresses every time the app synced, even if the data hadn’t changed! This is a massive waste of computing power and sync time.

Gemini told me this :slight_smile:

AVOID ADDRESS FIELDS in yuour app!

The Solution (The 0-Second Alternative)

I wanted the fast sync speed, but I still needed my technicians to be able to click an address and see it on a map. Here is how to get the best of both worlds:

Step 1: Kill the Geocoder Go to your Data > Columns and change your column type from Address to Text (or LongText). This instantly stops the background geocoding tax.

Step 2: Create a Map Action Go to Actions and create a new Action for your table:

  • Do this: App: Go to a website

  • Target: CONCATENATE("https://www.google.com/maps/search/?api=1&query=", ENCODEURL([Your_Address_Column]))

  • Appearance: Choose a map pin icon and set it to display “Inline” next to your address column.

The Results

By offloading the map routing directly to the native Google Maps URL and stopping AppSheet from calculating it internally, my sync time instantly dropped to 0.5 - 0.7 seconds! Plus, field technicians often prefer this anyway because it opens the address directly in their native Google Maps app for GPS navigation.

The best architecture is to have your backend/database trigger a webhook to geocode the address via API ONLY when it is created/edited, and store the result in a physical LatLong column. AppSheet reads physical LatLong instantly without recalculating!)

Hope this helps someone else speed up their heavy apps! Let me know if you’ve run into this internal geocoding trap before.

22 Likes

Very nice!! While I knew about the background geocoding, it never dawned on me that it might be adding to overall Sync times!

5 Likes

@Adam-google

Perhaps something that can be addressed somehow (excuse the Pun) ? Some sort of optimising can be done here, would love to hear if your team can come up with a solution to the scenario Jonathan1 faced instead of manually creating an action and webhooks

4 Likes

Thank you @Jonathan1 for sharing this valuable tip.

You may want to post it in the Tips and Tricks section for a better and long lasting reach.

Just in case you are not able to post in the Tips and Tricks section, please revert here. We could then request @Jose_Arteaga or @Shourya_Tomar to the needful.

6 Likes

Thank you so much @Jonathan1 for sharing such an insightful tip with the community members. I am sure this will be useful for everyone.
@Suvrutt_Gurjar, I will move this to the Tips and Tricks section as you rightly pointed out.

6 Likes

Awesome tip! Thanks for sharing, I was not aware of this additional calculus in the app.

6 Likes

Thank you so much for sharing this, @Jonathan1 !

This is a trap that’s incredibly easy to fall into — especially in customer management or field service apps where setting a column to Address type with Geocoding enabled just feels like the obvious, natural thing to do.

Really appreciate you sharing both the root cause and a clean workaround. The Google Maps URL action approach is elegant and likely a better experience for field techs too. Saving this one!

4 Likes

Interesting insight! :thinking:

I’m curious, did you try disabling the geocoding first - before switching the column type?

  • A major draw of the Address column is the driving instructions capability
  • Another is the auto-complete when you start typing

When you switch to a text column you lose both of these capabilties.

Perhaps you might get the best of both worlds by turning off the toggle and keeping the Address type?

@Jonathan1 did you try this?

  • Granted, this doesn’t do anything for the pin on a map
10 Likes

Hi @Jonathan1

I agree with @MultiTech

As for the suggestion to ‘kill’ the Address column type to speed up syncing, I have to disagree. The Address column isn’t just for showing a location; it’s vital for Customer Mapping. It allows us to view turnover per area with a very elegant display.

​Before deciding to remove the Address column, we should analyze the history first:

  1. ​After inputting data, are there many clicks on Enum buttons or dropdowns that trigger constant syncing?

  2. ​Is the Detail View still the auto-generated version that shows every customer when scrolling, or has it been restricted using a Slice with a formula like [Customer]=[_thisrow].[customer]?

this is just my opinion

4 Likes

Absolutely brilliant! Thanks for sharing!

4 Likes

Thank you for all the comments.

I wanted to share this because I was honestly so impressed by the difference it made. I was about to deliver a project, and I was feeling a bit discouraged by the slow sync after importing my client’s data. After discovering this, I just couldn’t keep it to myself.

The Performance analyzer helps a lot, but disabling the standard view option makes it even more powerful.

When AppSheet is properly optimized, it’s possible to build extremely powerful applications.

Thank you all.

7 Likes