Microsoft® SQL Server™ provides three major types and one optional type of replication to use as you design your distributed applications:
Option: Snapshot, with immediate-updating Subscribers
Option: Transactional, with immediate-updating Subscribers
Each of these types provides different capabilities and different attributes for transactional consistency and can be arrayed along a continuum from eventual data convergence to immediate transactional consistency.
Each of these types provides different capabilities and different attributes for the first two design requirements: data consistency and site autonomy. The third design requirement, partitioning, is a consideration you design into your application. By choosing a replication type and then augmenting it with partitioning, you have the opportunity to develop significant new distributed applications. Also, the decisions are not mutually exclusive. It is not uncommon for the same application to use multiple replication types. Some of its data may require immediate data consistency, while other data may not.
Which type of replication you choose for your application depends on your requirements for data consistency, site autonomy, and network resources.
If you refresh your data infrequently or the amount of data is small, snapshot replication is less intrusive than transactional because you do not have a log reader in the process. If you only need to update at the end of the day, it would use less resources to do a snapshot of 1,000 rows instead of transactions of millions of rows. You need transactional replication whenever you need updates more frequently than snapshots, or if your data is too large to refresh entirely.