and when you do break backwards compatibility, you version. Now how is versioning managed? The database can easily fill in here with a standardized approach, w

and when you do break backwards compatibility, you version. Now how is versioning managed? The database can easily fill in here with a standardized approach, with supporting tooling. Or it can not, in which case you come up with an adhoc versioning scheme that you maintain manually. Same way you do in all computing scenarios when you don't have any versioning tool available to you: AGREEMENT_v1.doc AGREEMENT_v2.doc AGREEMENT_v2_revised.doc AGREMEENT_v2_Revision2.doc AGREEMENT_v3.doc AGREEMENT_v3_fixed.doc or perhaps you start doing some strange behaviors to force other tools to fit in, like attempting to version your schema/functions with git, by tying it to a single application's ORM or perhaps you stop touching the database directly, and try to make it all work with migration-scripts, and it all falls apart when a second application comes into play or perhaps you try to force coordination between all dependent applications and your database, and make this update simultaneously or perhaps you convince the RDB management system to manage your system