It's worth thinking at a slightly more fine-grained level about the properties of older technologies, so as to be able to understand whether they should be abandoned completely. For the sake of argument (and because I'm marginally familiar with it) take PostgreSQL as an example of an old-school relational database. Use it, and out of the box you get (among other things):
- Familiar SQL syntax, understood by generations of programmers and software tools;
- Schema management commands;
- Data management commands;
- Hard guarantees about data integrity, through transactions;
- A sophisticated query planner with a choice of algorithms.
Similarly, it's true that an out-of-the-box relational database doesn't suit vast quantities of data distributed over large numbers of machines. Its query planner doesn't understand that situation. But a query planner is a mechanical embodiment of a task that used to be done by humans. To discard relational databases entirely is to shift that burden back onto those humans. I've seen this first-hand again and again - you wouldn't believe how much time Google engineers spend thinking about the most efficient way to query the data, and then writing fiddly bits of code to represent their conclusions. Far better is to upgrade the query planner to embody our understanding of the layout of data in the 21st Century.
The benefits of adapting and tuning existing systems are things like continuity and interoperability. Google's staggeringly huge repositories of data are carefully designed from the ground up to suit the queries they need to support. That's an affordable and necessary activity when you're shunting petabytes and more around. But it means that each repository comes with its own equally peculiar tools for querying, modifying and managing the data and the schemata. And there is certainly a high cost to that, as soon as any activity needs to span projects.
In short, I want a pony. I want the same pony everyone else wants (although some people haven't realised it yet). I want a pony that I can throw concise, high-level queries at, but that will scale. It doesn't have to be always consistent; it's okay for it to be eventually consistent. But I want it to take expressive queries in a well-known syntax - I shouldn't have to learn a new UI or API just to be able to investigate that one record which my current bug refers to. I want it to make plans for executing those queries, explain to me how much time and energy they're going to cost, and run them. All of which, I suspect, is best accomplished by surgery to tools that already exist.
