Since you mention this in the context of deployments, I understand that those tables contain configuration or master data that make sense only to newer version able to deal with it.
One way to solve this challenge, is to foresee in those tables a from_version version id that correspond to the software version from which this data starts to make sense. you can then make sure that an app version does select only the data it can deal with.
The problem is that sooner or later you might also need deletion of some data for a newer version. It would therefore be even safer to have a also a to_version so that each version can chose the relevant data.
If you also want to change data, it will be more difficult, due to primary keys. If you can avoid it don’t do this.
This solution is easily done, when designed right from start, because you’d factor the version logic in every query involving this data. But adding it afterwards can be difficult if many queries use these tables.
Another approach could be to use database schemas, authorisations, views or alisases. But the feasibility depends on many factors such as the database access strategy (e.g. a db user per app? per server? per end-user?), the use of the tables (read only vs read-write) and how the querries are build (i.e. is it easy to inject a prefix or a suffix to the involved tables) and the features of the database product itself.
