No Cloud Charges

Freedom of choice: the basic philosophy of our approach in designing SyncStudio. When applied to the problem of where to host your synchronization servers, the answer is that you are the one that decides where and how to host it.

SyncStudio is a product that you can buy, install on your own server and host your own synchronization sessions against your own database. You can host it yourself if you want, or you can buy inexpensive hosting from any service provider that offers Windows Hosting, and all you will pay for is the hosting charges, bandwidth and the storage for your database-but no cloud service charges, which are considerably higher than the price of regular windows hosting. Specifically, you will not be paying us a fee for every record being synchronized!

With SyncStudio you can start small, with a self-hosted solution to keep the costs down and then scale up to a 3rd-party hosted solution as your business grows.

Not every synchronization product out there works this way. Some mobile database synchronization products use a Cloud-hosted architecture with your data residing on their hosted environment or something like the Amazon Cloud. In these architectures the database synchronization function is being offered as a service, with a per-record cost.

These products generally offer their users a free account that allows them to synchronize a fairly small number of records, but beyond that they will need to pay the per-record charges. For very small databases and very few users this might be workable. However, for either larger databases (and it does not take very many records to trigger the charges) or for many mobile users the cloud fees can quickly become unaffordable. Basically, in the cloud-based architecture if you have more than a few thousand records in your database and/or a dozen users you will almost certainly find yourself paying a monthly charge, and as the size of your database and the user count grows this charge will keep getting bigger every month.

Some business models, such as those in which you are pushing out large amounts of data on a subscription basis, for example, can become completely unfeasible if you have to pay transaction fees for each record sent. Likewise, applications in which a large amount of data is collected in the field and then sent to a central server have the same problem. Some examples of this type of applications are surveys, field data collection apps for health care and industrial data collectors. Any application that manipulates and distributes data that changes quickly, which will force many records to be exchanged during each synchronization session, will be a very poor candidate for any kind of cloud-hosted architecture.

Additionally, in the cloud-based architecture it is not entirely clear how the data gets into and out of the cloud database server. If you have an ERP system, for example, you will have to do some type of custom programming or some type of import/export program to keep the cloud-based database aligned with your production system.