CUE DBMS

Some day, I'd like to build a DBMS with the following three properties, called CUE properties:

1. Cheap (or Cost-effective)

It should be cheap. Or, users should be willing to pay for what they get. In other words, work-done-per-dollar should be high. Pay-as-you-grow or SaaS model may also nicely fit for this, but in-house DBMS should also have a low cost to own, to administer (see Easy-to-use as well). Increase in cost should be justified by the increased output of the system. To realize it, DBMS will have to be built on commodity HWs, without any special interconnect or processing unit. More research will be needed to optimally exploit next-generation commodity HWs, such as many-nodes and flash memory.

2. Useful

It should be useful. It's more like a constraint that should be met, rather than an optimization objective, I believe. Below are vague specification of possible usefulness criteria.

- reasonably expressive: somewhere between key-value storage and SQL?

- reasonably fast: rather than being super-fast, certain hard-bound time limits should be met

- reasonably consistent: query answer should make sense (yup, it's a very unclear statement)

- highly available: it should serve requests at most of times. (how many nines?)

- highly scalable: it should adjust to the dynamic workload in an incremental fashion

3. Easy-to-use

User should not need to know too much about DBMS. It should be:

- nice user interface: HTML-based GUI

- self-tuning: physical design automatically done, continuously re-tuned in incremental fashion

- self-monitoring

- self-healing