Coming in late to the whole discussion:
Gut feeling mirrors Gregs first response. Compression should be used, but better at the usual level of the file (to say it with Trump: bmp: sad, jpg ok). But there isa lot of information missing to form even a close approximation ;-)

Walter already focused on them a bit. If you target replication in the long run it might be beneficial to restructure the DB schema: target a WORM layout, going for one record for each document (which I guess is unalterable after being sent/received) instead of going for a document-DB style adding each document to one in-record collection or bag of a "biz record", which I have seen sometimes in customer conflict cases.

Then only added documents need to be replicated (deletion, if allowed, does incur less load) and adding document n+1 does not force re-replicating previous n documents bundled in that "record".
However, no good deed goes unpunished: Queries will take longer, as all documents belonging to a biz case need a query to be seen ;-))



>>>Yes, it turns out the solution provider isn't willing to support replication over low bandwidth, so it's going to have to be some sort of remote access setup.
>>
>>Replication would probably require a very respectable bandwidth support. I can understand their POV. It appears a remote access would probably be better, which is what have usually seen at several occasions from discussions on this site, in situations like yours.
>
>Actually, bandwidth is something that may need to be revisited from time to time. A solution provider may say they don't support multi-site replication, but that policy may have been set years ago when bandwidth was very low. With more bandwidth available, that could change.
>
>>>Embedding documents in the database doesn't happen every day. They might go for a while not doing any, and then have to put in one or two dozen.
>>
>>As this is not applicable on a regular basis, in order to determine the payload, you would probably extend the calculation period over a very long period, which you certainly have. I would usually double up on everything, as far as potential scenarios, just to assure your expections would apply. When we have non regular processes like these, such as random payloads, it makes things a little bit more difficult to predict.
>>
>>>Do you have any idea of the efficiency of replication in this sort of scenario? If a 1MB document is embedded, how large of a transaction log entry does that create - I wonder if there's significant bloat.
>>
>>The transaction log tends to grow very fast based on various operations the database has the support, such as removing a bunch of records from a specific operation as well as when adding a new field. It might not be a factor if you have daily maintenance which shrinks some of that. However, if it keeps getting bigger, based on the limit applied into SQL Server, you might have a very big log, especially by embeding such documents into a table.
>
>Regardless of the type of replication used, the data transferred between replicated databases has to be at least as large as the document(s) embedded. Although, it might be smart for SQL Server and/or the transport mechanism to compress during transport (as Walter appears to be doing manually). I was just wondering if anyone had any idea of bloat e.g. if embedding a 1MB document generates 2MB of traffic to the other sites.
>
>>I never embed such documents into a table. While this is good for security concerns, it defies any potential of external manipulation, which might have served here in such replication. File synchronization would usually be easier to support than database. So, at least, you would have add that part more easily resolved.
>
>In this case documents must be embedded, for legal compliance.