When considering how to improve dealing with changes to your database when releasing software, one simple distinction can help clear up a lot of confusion. There are two broad categories of things that change in a database. There are tables that contain data for your application. Unlike application code, these can’t be dropped and recreated each time you release. At least not in the majority of useful software.
There’s another category of components within a database that can be treated much more like application code. These are the “code” components of your database. They don’t hold data. They simply transform and interact with data stored in tables. Things like views, stored procedures and functions. These can be dropped and recreated every time you release changes to your database.
That’s not to say that you will want to do this, but it is an option that works well in many situations. Just like your application code, you can simply replace these with the latest versions. There are often issues around ordering of how these are replaced, but otherwise are quite similar to application code.
No matter what you do to improve delivering database changes, if you keep this distinction in mind, you might find new opportunities. Or new ways of looking at things. And you’ll probably avoid some confusion in the myriad of strategies available to you. Different strategies often revolve around how to deal with database “code” versus database tables/data.