My application is deployed on several servers that all read data from a single database.

Following safe deployment practices, code deployments happen first on a subset of servers and only continue to the remaining servers if no issues are detected.

I'd like to also employ safe deployment practices for some critical data that is stored in the database. When appending new rows to a particular table, I'd like those rows to only be consumed by a subset of servers. The remaining servers will only consume the data if no issues are detected for a period of time.

How can I do this given that I only have a single database?

  • That's a little bit vague. Can you give us some more details, maybe an example, what kind of table you have in mind, what "critical" means, what the application is doing with or without those extra rows? Please edit the question to clarify.
    – Doc Brown
    Commented Apr 3, 2021 at 7:51
  • Specifying what database you're using would be helpful. Different database engines have custom functionality for this sort of thing. Oracle, for example, has Workspace Manager that allows you to have some servers accessing data from the new workspace while the other servers access data from the live workspace. Then you can merge the changes into the live workspace when no issues are detected. Other database engines may have similar functionality. Commented Apr 3, 2021 at 16:17

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.