To make an educated decision, you need to know what publishing does and what it does not.

Publishing is the process of copying content from one database to another. By default there is one source database - master and one destination database web. The web database is the publishing target.

When you publish, Sitecore copies data from 3 tables Items, VersionedFields, UnversionedField. Copy here is not just moving bytes. It is a sophisticated process that transforms data to the form that works best for delivery. From top of my head the following transformations are performed:

• Clones are merged
• Language fallback fields are materialized
• Old Item versions are removed so only recent one is kept

But Sitecore is not just Items and Fields. Other important artifacts are not moved when you publish content. What is not included:

• xDB data
• Sitecore modules, fixes, updates
• Users and Roles (although permissions are moves as they are stored in Item Security field)
• Application Files - configuration, CSS, JS, Razor views and others
• Application Code

After content is copied, target Server receives publish:end:remote event. During this event pipeline Sitecore clears caches for affected items and pushes affected items to Search Indexes.

As you can see, publishing is an expensive process. It may be an overkill to use it if you want to have two always synchronized environments. Consider shared database or SQL Replication for that scenario.

Multiple publishing targets setup works best for scenarios when two conditions are met:

• Sitecore and your App versions are synchronized
• You need to control over how your content is traveling from one environment to another.

Steve Newstead already provided great sample when it make most sense in his answer

To make an educated decision, you need to know what publishing does and what it does not.

Publishing is the process of copying content from one database to another. By default there is one source database - master and one destination database web. The web database is the publishing target.

When you publish, Sitecore copies data from 3 tables Items, VersionedFields, UnversionedField. Copy here is not just moving bytes. It is a sophisticated process that transforms data to the form that works best for delivery. From top of my head the following transformations are performed:

• Clones are merged
• Language fallback fields are materialized
• Old Item versions are removed so only recent one is kept

But Sitecore is not just Items and Fields. Other important artifacts are not moved when you publish content. What is not included:

• xDB data
• Sitecore modules, fixes, updates
• Users and Roles (although permissions are moved as they are stored in Item Security field)
• Application Files - configuration, CSS, JS, Razor views and others
• Application Code

After content is copied, target Server receives publish:end:remote event. During this event pipeline Sitecore clears caches for affected items and pushes affected items to Search Indexes.

As you can see, publishing is an expensive process. It may be an overkill to use it if you want to have two always synchronized environments. Consider shared database or SQL Replication for that scenario.

Multiple Publishing Targets work best for scenarios when two conditions are met:

• Sitecore and your App versions are synchronized
• You need to control over how your content is traveling from one environment to another.

Steve Newstead already provided great sample when it make most sense in his answer

To make an educated decision, you need to know what publishing does and what it does not.

Publishing is the process of copying content from one database to another. By default there is one source database - master and one destination database web. The web database is the publishing target.

When you publish, Sitecore copies data from 3 tables Items, VersionedFields, UnversionedField. Copy here is not just moving bytes. It is a sophisticated process that transforms data to the form that works best for delivery. From top of my head the following transformations are performed:

• Clones are merged
• Language fallback fields are materialized
• Old Item versions are removed so only recent one is kept

But Sitecore is not just Items and Fields. Other important artifacts are not moved when you publish content. What is not included:

• xDB data
• Sitecore modules, fixes, updates
• Users and Roles (although permissions are moves as they are stored in Item Security field)
• Application Files - configuration, CSS, JS, Razor views and others
• Application Code

After content is copied, target Server receives publish:end:remote event. During this event pipeline Sitecore clears caches for affected items and pushes affected items to Search Indexes.

As you can see, publishing is an expensive process. It may be an overkill to use it if you want to have two always synchronized environments. Consider shared database or SQL Replication for that scenario.

Multiple publishing targets setup works best for scenarios when two conditions are met:

• Sitecore and your App versions are synchronized
• You need to control over how your content is traveling from one environment to another.

Steve Newstead already provided great sample when it make most sense in his answer

To make an educated decision, you need to know what publishing does and what it does not.

Publishing is the process of copying content from one database to another. By default there is one source database - master and one destination database web. The web database is the publishing target.

When you publish, Sitecore copies data from 3 tables Items, VersionedFields, UnversionedField. Copy here is not just moving bytes. It is a sophisticated process that transforms data to the form that works best for delivery. From top of my head the following transformations are performed:

• Clones are merged
• Language fallback fields are materialized
• Old Item versions are removed so only recent one is kept

But Sitecore is not just Items and Fields. Other important artifacts are not moved when you publish content. What is not included:

• xDB data
• Sitecore modules, fixes, updates
• Users and Roles (although permissions are moves as they are stored in Item Security field)
• Application Files - configuration, CSS, JS, Razor views and others
• Application Code

After content is copied, target Server receives publish:end:remote event. During this event pipeline Sitecore clears caches for affected items and pushes affected items to Search Indexes.

As you can see, publishing is an expensive process. It may be an overkill to use it if you want to have two always synchronized environments. Consider shared database or SQL Replication for that scenario.

Multiple publishing targets setup works best for scenarios when two conditions are met:

• Sitecore and your App versions are synchronized
• You need to control over how your content is traveling from one environment to another.

Steve Newstead already provided great sample when it make most sense in his answer