The OpenStack Technical Committee voted last night to expand the scope of the Trove program, which is currently in incubation, to encompass non-relational as well as relational databases.
Trove (formerly known as RedDwarf) is a provisioning service for database servers that abstracts away the administrative parts of running the server, ‘including deployment, configuration, patching, backups, restores, and monitoring’. (In other words, it is comparable to Amazon’s RDS.) It was originally envisaged to encompass both relational and non-relational databases, but the Technical Committee limited the scope to relational databases only when it was accepted for incubation, pending a proof-of-concept to allow them to assess technical impact of supporting both. The minimal size of the resulting Redis implementation made a compelling case not to exclude non-relational databases any longer.
One trade-off to keep in mind when making such a decision is that maximising flexibility for users in the present does not always maximise flexibility for users in the future. A database being relational is not undesirable in itself; rather, trading away that valuable feature allows us to gain a different valuable feature: much easier scaling across multiple machines. This opens up an opportunity for a non-relational Database-as-a-Service that abstracts away the underlying servers entirely. Trove has no interest in being that service, so it is important that the existence of Trove does not eliminate the incentive for anybody else to create it.
Happily, Michael Basnight (the Trove PTL) has agreed to amend Trove’s mission statement to reflect the fact that it is a database provisioning service. In my opinion this offers the best of both worlds—flexibility now and keeping the door open to innovation in the future—and I was happy to support the change in scope.
My hope is that anybody contemplating a data-only non-relational DBaaS API will see this decision as confirmation that there is still a place for such a thing in OpenStack. I would also strongly encourage them to build it using Trove under the hood for server provisioning. I expect that some future Technical Committee would require this, much as Trove was required to use Heat instead of hand-rolled orchestration as a condition of graduation from incubation.
Speaking of which, the Technical Committee is planning to assess Trove in September for possible graduation in time for the Icehouse (2014.1) release cycle.
