We have what can be called a distributed application: One full-blown web app and a small REST service. Both must be separately deployable. Both access the same database schema (they actually share only two tables). The common functionality is encapsulated in a common artifact (a JAR file here, since it’s all Java). So far, so good.

However, I’m unsure how to handle schema changes properly. The web app uses Flyway for its schema updates, it works like a charm. But what should be the recommended procedure if one of the shared tables needs an update? Whose responsibility should the upgrade be? (At the moment it is the web app that performs all the upgrades, perhaps that’s good enough, but it worries me.)

I thought of perhaps even changing the architecture to have a separate application or service that has both web app and REST service as a client, but this would only make things difficult, not actually remove the problem.

  • If they must be separately deployable, how can the web app update be good enough? What do you mean by separate?
    – JeffO
    Commented Aug 8, 2013 at 19:37
  • It works at the moment, that’s what I meant by ‘good enough’. It works because actually the DB updates are very infrequent.
    – MPi
    Commented Aug 9, 2013 at 7:33

2 Answers 2


The way Flyway describes itself, it scans both the existing status of the database schema and all defined "migrations" on the class path of the program it is used in, and then automatically does the right thing. Therefore, the obvious answer is "both". Whoever happens to access the database first will perform the migration, so the other client won't have to.

(Obviously there is a possibility that both clients might access the database in an overlapping way and "steal" each other's upgrades. But this is no different from managing any normal read-write access to a shared resource - if you need transactional semantics, I assume that you already have a way of ensuring it.)


Your webapp directly accesses the DB? That's a bit of an anti-pattern right there and shouldn't be encouraged (for security reasons mainly), so I would try to put the DB with the another app-tier service as much as possible partly to try to encourage splitting DB access from client (or web server) access.

Otherwise, just create a new component that is "the DB" and it handles all schema changes independently of both - then neither is going to mess up the others schema changes, and both will have to get used to using this new project as a dependancy.

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.