Sam Gentle.com

Build your own database

One unfortunate habit I see people get into is only using one kind of database. Once you get familiar enough with a particular family – say, document databases, or traditional relational databases – it's easy to try to shape all your future problems into that paradigm. Oftentimes that ends up meaning just one single database that you constantly push the limits of when you should really use a different one that suits the domain better.

But maybe there can be a single answer, if it's an answer that lets you adapt the database to the situation. What if you had a build-your-own-database? Instead of prividing you with a high-level preworked answer to the various tradeoffs, it would give you a lower-level set of primitives that you could combine to let you fit the database more naturally to the problem domain.

I'm not entirely sure what those primitives would be – probably some combination of indexes, hash joins, triggered events, and maybe a few options for low-level storage – but I think it'd be an interesting project to figure it out. Databases are too useful and powerful to stick with just one.