I like approaches like this too. Largely because it tends to make you think about <i>why</i> you need consistency, more durability, better query abilities etc. for specific subsets of the data if&#x2F;when it comes up, and what the specific requirements are.<p>When people throw everything into a database, in my experience the specific requirements for specific subsets of the data are often lost in the fog of history as people often don&#x27;t document <i>why</i> they need to be in the database.<p>Then it turns out the database is used for everything from a short term cache which could just as well have been in memory, to logs which are of limited utility over long term and &quot;just&quot; need to be indexed for short term querying, to vital financial transactional data which needs to be kept for X number of years, to per-user data which is never, ever looked up other than when that specific user is logged in, and so would be ideal to shard, and so on.<p>Grabbing for the RDBMS right away is then the lazy way out where you can often get away with not seriously evaluating what is best, because it is &quot;good enough&quot;. Then it&#x27;s nice to start out with something that is sufficiently limited that you&#x27;re forced to take it into consideration sooner rather than later.