4 ms·

I don't see what is so appealing about backwards compatibility. The database is an implementation detail and its specifics should not block anything. Seeing se

I don't see what is so appealing about backwards compatibility. The database is an implementation detail and its specifics should not block anything. Seeing several comments like yours is puzzling to me because I find myself unable to understand what are the devs preaching for it gaining from SQLite's extremely conservative backwards compatibility policy. For example, PostgreSQL has `pg_upgrade`. You run that after you upgrade its major version and it's a bulletproof and easy transition 99% of the time.

bruce511 2y ago
Like with most things, context matters. If you have a "closed" system (such that "you" control the database, and all access to it) then upgrades are "easy" to do. You just upgrade the server and all clients. If your system is more diverse then it's harder because in that case server and clients gave to be upgraded together. If I'm using multiple different programs (Accounting, Payroll, Access control etc) possibly from multiple vendors, then coordinating everything to happen at the same time can be impossible. If the server is not backwards compatible with old clients then you can get stuck. In the case of SQLite for example lots of systems rely on the stability of the file format. Breaking that would not be welcome.