Because you can add arbitrary keys in a new release and there is no migration SQL needed like you would need to do if adding new database columns (or tables).
The thing he missed is that you can implement arbitrary key/value pairs in a RDBMS table; you don’t need a NoSQL database necessarily:
CREATE TABLE NAME_VALUE
ID INT,
NAME VARCHAR(32),
VALUE VARCHAR(512);
Querying on WHERE clauses with multiple keys/names can be tedious but works fine as long as performance is not your first priority.
Point likely stands - any schema migration is not an easier problem on either side - you just move the migration logic to your code instead of the database.
That's the part of NoSQL I've never understood. With a "normal" SQL DB my app has to be able to migrate between versions of data, but the code ever only supports the current version. With NoSQL, you will either have to support every possible version (which might be unique per entry), or implement migrations yourself. How is that not strictly worse?
