Some domains or projects require or work better with "soft" schemas, at least initially. I always wanted "dynamic relational" where columns are optional and "cr

Some domains or projects require or work better with "soft" schemas, at least initially. I always wanted "dynamic relational" where columns are optional and "create on write" (except for "ID", which is needed for row uniqueness guarantee). If you query for a column that doesn't exist, instead of an error, you get a blank for that column (or null, depending on design decisions or settings). But, one can gradually add rules as the requirements solidify. You can later add a rule that all rows of the Employee table must have a non-blank "last_name" column. You can have a rule/constraint that requires it for new rows, and perhaps have a "cleaning mode" to check existing rows. With enough rules/constraints, it acts pretty much like the current crop of RDBMS. Dynamic relational could still use SQL, with some minor modifications to clarify intended compare types. (SQL has warts, but nothing better has arrived yet that's sufficiently better to justify tossing an established standard.) It's not SQL versus No-SQL, it should be strong-typed SQL versus "soft" SQL. That way one doesn't have to toss all their SQL/RDBMS knowledge to get a dynamic RDBMS. The current dichotomy of choice is unnecessarily stark: it's either an RDBMS with SQL, or something very foreign. The No-SQL movement was driven by hardware & scaling needs, not query language needs. If anyone is interested in starting up a dynamic relational company, I'd be glad to supply you with a draft spec for free.