It's hard to say. On small applications, SQL Synchronization SDK works great in this sort of one-way synchronization, provided that the databases' schemata are set up in a way that allows consistent identities (record IDs) in all of the tables. On any data synchronization, it is going to match rows in the table based on primary key or user-defined columns (provided the column(s) contains unique data). Two-way synchronization starts to get a bit hairy because you would have to code some sort of logic to handle "conflicts" between records that had been updated simultaneously on the client and the server. This is not automatically handled by SDK.
Database size is an issue because SDK reads all of the data in the tables that you want to compare, so worst-case, if you have a huge database with infrequently-changed data, you could potentially waste a lot of time comparing the same data over and over and over again. This can be mitigated using the WHERE clause property, for instance if you assign a block of identities to your laptop user, you could compare only his data and not the whole kit and caboodle.
So no matter how you decide to go about this, it will probably be a bit of a job for you. The SDK can take care of the comparison and synchronization bits if your schema is well thought out and appropriate for this sort of task.