In Microsoft SQL Server replication, the terms "push" and "pull" refer to the methods by which replicated data is transferred from the Publisher to the Subscriber(s). These methods determine where the replication agents run and how the distribution of data is initiated. While the end result of both push and pull replication is the synchronization of data between the Publisher and Subscriber(s), they operate in fundamentally different ways.

Push Replication
In push replication, the actions required to replicate data are initiated by the Distributor. All the agents involved in the replication process—the Snapshot Agent, the Log Reader Agent (in transactional replication), and the Distribution Agent—are run on the Distributor. This method "pushes" changes out to the Subscribers without the Subscribers having to request (or "pull") the changes.

Characteristics of Push Replication:

Agent Location: Agents are run on the Distributor or the Publisher (if the Publisher is also acting as its own Distributor).
Initiation: The replication is automatically initiated by the Publisher/Distributor based on a schedule or a continuous action, without the Subscriber requesting the data.
Management: Generally easier to manage because the replication process is centralized at the Distributor.
Control: Better suited for scenarios where the Publisher has the administrative control over the replication timing and frequency.
Usage: Commonly used in environments where data changes need to be propagated in a timely and controlled manner.
Pull Replication
Pull replication, on the other hand, is driven by the Subscriber. In this model, the Subscriber initiates the replication process, and the agents—the Distribution Agent for snapshot and transactional replication, and the Merge Agent for merge replication—run on the Subscriber. The Subscriber "pulls" the changes from the Publisher as needed, based on a defined schedule or on-demand.

Characteristics of Pull Replication:

Agent Location: Agents are run on the Subscriber.
Initiation: The replication process is initiated by the Subscriber based on a schedule that is configured at the Subscriber.
Management: It requires more management at the Subscriber level, as each Subscriber is responsible for pulling the data.
Control: Provides autonomy to the Subscriber, which can be necessary if Subscribers are managed by different departments or organizations.
Usage: Ideal for scenarios where the Subscribers are remote, disconnected, or need to control the timing of data synchronization due to bandwidth considerations or other resource constraints.
Comparing Push vs. Pull Replication
Resource Utilization:

Push: Resource utilization is primarily on the Distributor or Publisher.
Pull: Resource utilization is offloaded to the Subscriber.
Performance:

Push: May impact the performance of the Publisher/Distributor if there are many Subscribers or large volumes of data to replicate.
Pull: Can balance the load more efficiently by allowing Subscribers to retrieve data as per their capacity.
Scalability:

Push: Can become more challenging to scale as adding more Subscribers increases the load on the Publisher/Distributor.
Pull: Scales better in environments with numerous Subscribers, as each manages its own replication timing.
Administrative Control:

Push: Centralized control, making it simpler to administer.
Pull: Distributed control, which can be more complex but offers flexibility.
In conclusion, the choice between push and pull replication in SQL Server is largely dependent on the specific requirements and constraints of the replication environment. Push replication is generally simpler and more centralized, whereas pull replication offers greater flexibility and scalability at the cost of increased complexity.