Ничто не мешает, так и делаю. В мунине настолько просто писать плагины что положили в него даже бизнес графики. А клиентам отдаем json + графики на js. Все как я и писал.

Чтобы не быть голословным, поясню:
1. На текущий момент почти каждый релиз меняет движок (LevelDB в 0.7 -> RocksDB (и вообще Pluggable) в 0.8 -> BoltDB в 0.9 и в рамках 0.9 они планировали еще одну смену движка).
2. База фактически Write Mostly. Т.е. на запись у нее была неплохая производительность (хохма в том, что дефолтный стэк графита, написанный на питоне, выдавал сопоставимую, но это мелочи), но при этом из-за особенностей хранения данных прочитать потом что-то - сложно.
3. Колличество детских болячек зашкаливает. Т.е. стабильным оно становится обычно к .5 - .6 релизу. До этого - теряет данные, падает, уходит в себя и пр. прелестные вещи.
5. Размер итоговых данных - на 1 точку приходится больше метаданных, чем в других вариантах хранения (всякие Series ID и пр. радости жизни).

Т.е. многообещающе, мб с переходом на Go 1.5 у них производительность поднялась, и как устаканится движок, может быть у них будет более-менее нормальное поведение при mixed-нагузке (много записи, постоянно идет чтение разных метрик), но пока - интересно, но не готов для серьезного применения. Увы. Ибо кроме Influx'а из time-series можно вспомнить пару различных сетапов графтиа (whisper, booking'овый whisper с помощью carbon zipper, яндексовый ceres, cassandra), но у всех свои недостатки, в том числе в виде морды графита, делающей кучу не очень простой математики, но при этом написанной на питоне и загибающейся на 40-50 средней сложности запросах в секунду на не очень то слабом железе (2xE5-2630v2). Ну и всякие rrd-based решения, у которых еще свои недостатки (масштабируемость, скорость работы базы, характер нагрузки rrdtools не очень подходящий для ssd дисков и т.п.)