Development Database 

Flyway Desktop works with the following:

A shared development database could increase human error, limit the ability of team members to experiment, and curtail testing of features early in the development process. 

Advantages of dedicated development databases 

Distributed version control systems, such as Git, don't reflect shared databases

The most popular version control system (VCS) is Git. Git is a distributed version control system, meaning that users clone a local, private copy of the repository in which to work. When working with Git, committed changes are periodically pushed to and pulled from the centralized repo, and users may work in branches to develop new changes.

This may cause problems when teams utilize a shared development database; the database is shared, but the local git repo is not shared.  This misalignment makes it unclear which changes in the development database have been committed to the repo and in which branch. This lack of clarity makes it easy for a developer to accidentally overwrite someone else's changes or to erroneously include someone else's work in progress in their own commits.  Team member should regularly pull and push to update their local git repo with changes pushed by other team members to help avoid some of these problems.  

By contrast, having a dedicated development database aligns well with distributed version control systems in an intuitive way because your database will match your local repo. 

Dedicated development databases create a safe place for experimentation 

Users who have a private development database are free to experiment with any schema or data changes necessary to design or test a database change.  They don't have to worry about breaking something and messing it up for everyone.

By contrast, users who share a single development database must be very careful not to impact other users. Any changes to schema or data in the environment could delay another user, cause another user to see unexpected results, or cause confusion. 

The ability to experiment and to make any changes necessary to test a change help developers make the right changes and identify any problems early.

Dedicated development databases promote good habits in software development 

Users who have a private development database must share changes with one another by frequently committing those changes to version control. 

By contrast, users with a shared development environment often rely on the ability to share changes through the database itself and refrain from checking in those changes for longer periods. This results in a buildup of uncommitted changes in the development database. It's easy to lose track of the status of these changes, to not remember who made what change and why, to accidentally overwrite these changes, and even to accidentally commit these changes when it is not necessary. If the shared development database is corrupted or accidentally dropped, these changes may be lost altogether. 

Dedicated development databases allow higher permissions for developers, which builds knowledge and allows better troubleshooting 

Users who have a private development database are often granted higher permissions on this environment, as it is only for their use. These higher permissions allow the users to develop more expertise in the database technology they are using and to develop their troubleshooting skills when problems arise. 

By contrast, users in shared databases are often restricted to more limited permissions because of the risks of accidentally impeding the work of other users. This disempowers these users and limits their long-term knowledge of the database technology. 

Reducing costs for development databases when using Platform as a Service (PaaS) databases 

If you choose to use a database hosted by your cloud provider for your development and shadow databases, you may choose to use some of your cloud provider's options to reduce costs for these environments.

For example, if you are using Azure SQL Database, you may use the serverless compute tier to reduce costs for the environment when not in use. Please note that the serverless compute tier auto-pauses databases when not in use. Connections which trigger the database to resume return an error stating that the database is unavailable with error code 40613. If you are using the serverless compute tier, you will see this error bubble up in Flyway Desktop. Re-try your action and it should work. 

Another option to reduce costs when using Azure SQL Database for development or shadow databases is to use an elastic pool. 

You can also use a local shadow database.  This might improve performance.  You also don't have disk space or backup concerns for shadow databases.

Next steps

Learn more about configuring your development database in Flyway Desktop.