I have searched for this answer on many websites,and I am getting almost same answer everywhere.
This can be done by using Jpa too (using different properties file for staging, dev, production). Then when we should use liquibase, and when it is required?
Liquibase & JPA are very different & have completely separate use cases.
Liquibase is a library for tracking, managing, and applying database schema changes automatically. Liquibase helps track all of your database schema changes in your own files (sql, xml, yml, json). You can think of liquibase as a versioning-type tool for database scripts.
Say somebody inserts new data into a table but, only did it for one environment when it should have been done for all of them. Now an even worse case scenario is that person leaves their company & now no one knows they are missing data. This is a perfect example of how you lose consistency overtime due to careless errors when managing multiple databases or multiple schemas. With liquibase they wouldn't have to worry because that database change is now properly saved & will execute for each environment that that code is deployed to. Essentially, your liquibase scripts are now somewhat part of your project's code (depending on where they live of course).
On the other hand, JPA can validate your existing codebase against your database but, it won't make the necessary DB changes for you (unless you specify something like create-drop which I don't recommend for most use cases). Whenever you use any of their annotations such as @Entity, @Table, @Id, @Blob, etc., none of those changes are automatically applied to your database. JPA is great for modeling how your tables, relationships, & constraints should look in your database. However, it is usually up to you to execute the necessary SQL (or other query language) for such changes. That's where liquibase can conveniently handle it for you.