A return to the general-purpose database
This is a real trend, at least anecdotally in organizations I work with, and it is being driven in large part by the extraordinary cost -- both time and money -- of moving and reorganizing data within and across systems, particularly as the volumes and velocity inexorably increase. Unnecessary data motion is an operational killer.<p>Working against this trend is that you can&#x27;t make a database competently &quot;general purpose&quot; that was not explicitly designed to be this way in the first place. There is a lot of friction created by the impedance mismatch between a database kernel and the extensions it was never designed to support. Also, even for relatively general-purpose databases like a modern RDBMS, &quot;general purpose&quot; encompasses a much wider array of features today than were anticipated by anyone when these databases were designed.<p>I am skeptical that any current database can meet that criteria through evolution. Existing relatively general databases are insufficiently scalable for many data models and the most scalable databases have internals that are heavily overfitted for a single type of data model to the exclusion of ever having good performance for most others. Most of which can be explained by none of them having been designed with the end state we are talking about here in mind.<p>It should be added that building a database specifically for scalable generality would be extremely expensive. Reductions in generality are a major mechanism for reducing engineering cost in database engines. I&#x27;m not sure you could even find the resources to undertake such an endeavor today. Definitely not the kind of thing where a couple people can build an MVP working nights and weekends.