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 database is the publishing target.
When you publish, Sitecore copies data from 3 tables
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
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
- 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