GoZync – The second synchronization tool reviewed

We’re to the second of the three most well know competitors in the FileMaker synchronization marketplace, GoZync. We reviewed MirrorSync lat week in our previous post, and we’ll continue to review one tool a week until we get through them all.

GoZync is made by the great folks over at SeedCode. Before I dive into the review, I feel I should go into full disclosure mode. John Sindelar is a friend, and we have worked together in the past. We’re trying to be as unbiased in our review as possible, but I thought I should disclose our prior business ties before moving forward.

GoZync is up to version 5, just released this week and is a great improvement on an already good product. We initially did our testing in version 4, but have updated our tests and reviews to reflect version 5 data. If you want to read a bit about our testing environment and our tester you can read about it in our first post.

The first thing to note is perhaps the unique features as seen by our intern and tester, Patrick:

GoZync has the capability to stop users from pulling a new version if they have changes that have not been pushed to the main copy. One of the main changes made for this version of GoZync is that it is 4 times faster than before, according to SeedCode. The website states it would take GoZync 4,  3 minutes 20 seconds to pull 100 records whereas the new version takes 32 seconds for the same kind of pull. Which according to my tests appears to be true. Another unique feature is that GoZync allows mobile users to download new versions of a solution from their device using the GoZyncHosted file. The tool can also be used as a file delivery portal, which then acts similar to an app store. Another helpful feature is that GoZync is made up of all FileMaker files, there are no other apps or downloads necessary other than the ones that come from the GoZync zip. So if you have a FileMaker server running with all the necessary open ports then GoZync should work as well.

There are some notable improvements boasted, so we (and by we I mean Patrick) dove into integration:

Out of all of the sync tools GoZync is one of the most involved to integrate. It is extremely easy to mess up one small thing along the way. Having said that SeedCode has created a great tutorial that helps tremendously when initially setting up your solution. Not only are the tutorials great, but they include example solutions in the package to help guide users as well. In total it took probably 5 hours in total to integrate GoZync for the first time. The majority of that time was spent trying to fix a minor bug that ended up not impacting the end result. It said that there was an error in one of the scripts but in actuality it was fine and it was not until I actually synced that I realized the error was irrelevant.

If I were to integrate this again then I think it would take 1 hour maybe 2 max.

Once integrated we started our tests, Patrick’s thoughts on the synchronization process were:

GoZync is one of the most consistent sync tools that I  used. All the tools had minor, hiccups that didn’t affect the process and GoZync was no exception but for the most part it worked perfectly. This was the first tool I was able to finish all the synchronizations in the time tests (except the 512mb container fields, just for time reasons).

It is not the fastest when it comes to synchronizing data fields but at the same time it is not the slowest either. It sits comfortably in the middle. The best part of GoZync is that it has the fastest container syncs by a large margin.

With the synchronizations done it’s time to review the numbers:

Pulling From Server
50
Records
100
Records
500
Records
1000
Records
5000
Records
10 Fields 16 seconds 21 seconds 1 minute 13 seconds 2 minutes 30 seconds 13 minutes 22 seconds
50 fields 28 seconds 36 seconds 2 minute 49 seconds 5 minutes 23 seconds 26 minutes 18 seconds
Pushing To Server
50
Records
100
Records
500
Records
1000
Records
5000
Records
10 Fields 28 seconds 28 seconds 2 minutes 55 seconds 3 minutes 41 seconds 18 minutes 36 seconds
50 Fields 25 seconds 44 seconds 3 minutes 19 seconds  6 minutes 40 seconds 33 minutes 22 seconds
Container Speed Tests
File Size 1
Records
10
Records
50
Records
100
Records
500
Records
1 mb 7 seconds 9 seconds 15 seconds 24 seconds 1 minute 33 seconds
16 mb 17 seconds 20 seconds 30 seconds 36 seconds 1 minute 46 seconds
128 mb 2 minutes 5 seconds 2 minutes 14 seconds 2 minutes 13 seconds 2 minutes 21 seconds 3 minutes 30 seconds
512 mb 8 minutes 7 seconds 8 minutes 18 seconds Not Performed Not Performed Not Performed

The “too long, didn’t read” version is, GoZync was a bit slower than MirrorSync in data, they were a lot faster for container fields.

Next we wanted to compare features. In choosing features to list and compare, we tried to focus on features that were quantifiable and concise, but weren’t covered in other analysis. For GoZync they provide (what we consider the preferred answer is in green, the less ideal answer in red):

Features
GoZync
The ability to choose what fields to synchronize Yes
Tools to help deploy local offline copies Yes
Developer can control the synchronization direction Yes
Synchronizes container fields Yes
Provides field level merge to manage conflicts Yes
Supports Server to Server synchronization No
Open Remote required No
Requires UUID Yes
Deletions synchronize both directions No
Requires additional hosted files Yes
Resume incomplete synchronization Yes
Requires FileMaker Server No
Field level conflict management No
 Approximate first time to integrate  5 Hours
Time to integrate once familiar 1 Hour

I wanted to mention a couple caveats about the features this week. First, listing both MirrorSync and GoZync having tools to help deploy new versions is a bit misleading, GoZync’s new version deployment is simply amazing, and is a boon not to be overlooked when you have a remotely deployed system where development is ongoing (and when does development really ever end…).

Also, saying that UUID’s are required is also a bit misleading. Most all tools will require UUIDs, GoZync uses one you make, while tools that don’t “require” them, simply make one for you behind the scenes and keep track of what record they point to for you. We would recommend all developers use UUID fields for key fields in all synchronized solutions, so this feature is a bit of an optional one in our opinion.

We’ll continue to test and report on a new product each week. If you’d like us to expand our testing to include something you feel we may have missed, or just want to chime in with your thoughts or say something nice about GoZync or SeedCode, please leave a comment below.

Court Bowman

Author Court Bowman

Court Bowman has been working with in the IT field his whole life, working as a network engineer, database developer in Oracle and Progress and as a IT director for several firms. He has been working with FileMaker Pro since version 2 and has been a reoccurring speaker at the FileMaker developer conference. Apart from his expertise in FileMaker Pro he has experience in system architecture and design, data modeling and database architecture. He also has years of experience as a process and workflow consultant and has helped with the design and deployment of hundreds of systems in FileMaker and on the web.

More posts by Court Bowman

Join the discussion 5 Comments

Leave a Reply

All rights reserved Cleveland Consulting.