Une publication peut être définie sur n'importe quel serveur primaire de réplication physique. Le nœud sur laquelle la publication est définie est nommé publieur. Une publication est un ensemble de modifications générées par une table ou un groupe de tables et peut aussi être défini comme un ensemble de modifications ou un ensemble de réplication. Chaque publication existe au sein d'une seule base de données.

Les publications sont différenciées du schéma et n'ont pas d'impact sur la manière dont la base est accédée. Chaque table peut être ajoutée à différentes publications au besoin. Actuellement, les publications ne contiennent que les tables et toutes les tables d'un schéma. Les objets doivent être ajoutés explicitement, sauf si la publication a été créée pour toutes les tables (ALL TABLES).

Les publications peuvent choisir de limiter les changements qu'elles produisent avec n'importe quelle combinaison de INSERT, UPDATE, DELETE et TRUNCATE, ceci d'une façon similaire à l'activation de triggers en fonction d'un certain type d'événement. Par défaut, tous les types d'opération sont répliqués. Ces spécifications de publication s'appliquent seulement pour les opérations DML ; elles n'affectent pas la copie initiale de synchronisation des données. (Les filtres de ligne n'ont pas d'effet pour la commande TRUNCATE. Voir Section 29.4.)

Une table publiée doit avoir une identité de réplication configurée pour être capable de répliquer des opérations UPDATE et DELETE, pour que les lignes appropriées à modifier ou supprimer puissent être identifiées du côté de l'abonné. Par défaut, il s'agit de la clé primaire, si elle existe. Un autre index d'unicité (avec quelques prérequis supplémentaires) peut aussi être configuré du côté de l'abonné. Si la table n'a pas de clé convenable, alors elle peut être configurée pour l'identité de réplicat FULL, ce qui signifie que la ligne entière devient la clé. Lorsque l'identité de réplicat est spécifiée à FULL, des index peuvent être utilisés du côté de l'abonné pour rechercher des lignes. Ces index candidats doivent être de type btree ou hash, non-partiels, et le champ d'index le plus à gauche doit être une colonne (pas une expression) qui référencie la colonne de la table publiée. Ces restrictions sur les propriétés non-unique de l'index correspondent à certaines des restrictions renforcées par des clés primaires. S'il n'y a pas d'index approprié, la recherche côté abonné peut être très peu efficace, par conséquent l'identité de réplicat FULL devrait seulement être utilisée comme solution de repli si aucune autre solution n'est disponible. Si une identité de réplication est différente de FULL du côté du publieur, une identité de réplication comprenant les mêmes colonnes, ou moins de colonnes, peut aussi être configuré du côté de l'abonné. Voir REPLICA IDENTITY pour les détails sur la configuration de l'identité de réplication. Si une table sans identité de réplication est ajoutée à une publication qui réplique les opérations UPDATE ou DELETE, alors les opérations UPDATE ou DELETE suivantes causeront une erreur sur le publieur. Les opérations INSERT peuvent se réaliser quelle que soit l'identité de réplication.

Chaque publication peut avoir plusieurs abonnés.

Une publication est créée en utilisant la commande CREATE PUBLICATION et peut ensuite être modifiée ou supprimée en utilisant la commande correspondante.

Les tables individuelles peuvent être ajoutées ou supprimées dynamiquement en utilisant ALTER PUBLICATION. Les opérations ADD TABLE et DROP TABLE sont toutes les deux transactionnelles ; de ce fait, une table va commencer ou arrêter de répliquer dans le bon instantané seulement une fois que la transaction a été validée.