Database design to avoid inconsistencies in the version between the application layer and the database layer

The approach that comes to mind is called Entity-Attribute = Value (EAV). If you search on Google for that, you will find very quickly that it is almost universally revised. In short, it's generally a bad idea because it does not allow your relational database management system to do what it was designed to do.

As an alternative, you should think of schema changes as something you need to maintain compatibility with earlier versions. This often means that the new columns will be voidable or will have default values ​​set. However, depending on what you want to do with your application, sometimes a database change is simply a major change and you can not release the database change without releasing the corresponding code change.

I've seen some people keep a short code table in their database that contains information about the version (for example, the minimum and maximum code versions supported). The idea of ​​this is that when the application starts, a quick search is made in the code table and, if the database version is not compatible with the code, the code is output correctly.