Dgraph, GraphQL, Schemas, & CRUD – Ardan Labs
&gt;Relational databases are very rigid so you need to really make sure you understand your data upfront.<p>Is NOT true:<p><pre><code>    CREATE TABLE&#x2F;VIEW ...
    ALTER TABLE ...
    SELECT (whatever) ...
</code></pre>
Changing a rdbms at runtime is fully supported, in MUCH better ways than almost all &quot;nosql&quot; databases.<p>&gt; Changing the database is a big effort<p>Is much less effort than nosql. With more guaranties than the change is CORRECT, and not left you half documents in one version and the other in other version.<p>&gt; These databases are hard to distribute and scale so you tend to end up with single instances that are very large and require replication for backup. The cloud providers have relational databases today that are supposed to scale, but I have no experience with them.<p>Is very easy to be &quot;web scale&quot; if you don&#x27;t care about data integrity. Very few nosql are half good about this. Scaling a rdbms is very similar to have a less brittle nosql product (like mongo), is about how you model the data.<p>I was in a team behind one of the largest deployments on google cloud store. The amount of coding for cover for the store lack of integrity was a big part of the codebase. Despite the supposedly massive amount of data I don&#x27;t see why have a rdbms in the back could have been worse (when anyway you must put in front redis and other caches for high ingestion).<p>I think for the majority of the startup deployments, rarely a non-rdbms make much sense, specially if the team have not idea of what truly a good rdbms can do, or how code by hand a correct transaction code...