Some of the more exciting ideas I've seen recently: http://arxiv.org/abs/1310.3314 http://arxiv.org/abs/1310.3314 - Understanding the core difficulty in answer

Some of the more exciting ideas I've seen recently: http://arxiv.org/abs/1310.3314 http://arxiv.org/abs/1310.3314 - Understanding the core difficulty in answering relational queries and examples of problems for which current query optimisers always produce plans which are asymptotically suboptimal http://arxiv.org/abs/1404.0703 http://arxiv.org/abs/1404.0703 - The first theoretical analysis which can relate the choice of indexes to worst-case bounds. Presents a single join algorithm which is asymptotically optimal on every problem without even using cardinality estimates. http://arxiv.org/abs/1210.0481 http://arxiv.org/abs/1210.0481 - A join algorithm that meets some of the bounds of the above paper and is also fast in practice and can be incrementally maintained. https://infosys.uni-saarland.de/projects/octopusdb.php https://infosys.uni-saarland.de/projects/octopusdb.php - Treating index creation, query optimising, view materialisation, incremental maintenance etc as one large optimisation problem. http://www.vldb.org/pvldb/vol4/p539-neumann.pdf http://www.vldb.org/pvldb/vol4/p539-neumann.pdf - Compiling query plans to LLVM because the query plans / indexes are good enough to make the plan cpu-bound instead of memory-bound http://hyper-db.de/HyperTechReport.pdf http://hyper-db.de/HyperTechReport.pdf - Running OLAP and OLTP workloads on the same database without interference It seems possible that in the future, far from having a Cambrian explosion of specialised databases, we will be able to store everything in a single db and treat questions of data layout, partitioning, indexing etc as a direct optimisation problem.