> И как оно? Мы в свое время побоялись её на прод пускать.

А чего бояться, тестировать надо (и, пожалуй, хотя бы ознакомиться с кодом, благо его мало), а там уж ясно станет, либо пускать, либо не пускать. В моём случае, похоже, реальная нагрузка оказалась даже меньше тестовой, так что в итоге замечательно работает. И да, специфика моего случая: принципиально важна возможность удалять старые файлы (т.е. держать архив за N дней), при таком количестве файлов в случае ФС это была огромная боль.

> С какими проблемами пришлось столкнуться? Как нагрузку держит?

1. Поначалу (ещё до выбора кого использовать) традиционно стоит проблема разобраться с документацией. У weedfs сущностей используется меньше (чем у аналогов), так что это ещё одна из причин его выбрать в итоге.
2. Конечно же вылезла проблема Go'шного GC (который «stop the world» любит делать), но по пути до прода она исчезла (во-первых, было несколько важных обновлений Go и самого weedfs, во-вторых, нагрузка на проде оказалась куда ниже, чем в тестах). Так что нагрузку в итоге держит стабильно. В итоге упёрлось всё в ширину канала наружу, а не в БД.
3. Т.к. использовать вложенные каталоги тут весьма нежелательно, пришлось чутка поменять код приложений, которые работали с этой БД, вместо путей вида /datatype/param-a/param-b/param-c/zzz стали, грубо говоря, /datatype/param-a_param-b_param-c_zzz. Т.к. оно используется только по HTTP (без всяких FUSE-обёрток), такое изменение никаких новых проблем не принесло.
4. Не забыть на nginx, стоящем между интернетами и БД, явно указать что для проксируемых запросов разрешён только метод GET. Не то что бы это проблема, но могло ей стать, если бы не вспомнили в последний момент. Вроде, и очевидная вещь, но имеет отношение не к самой БД, а к инфраструктуре вокруг, так что может и остаться незамеченной (прямо скажем, нечасто в nginx в секции proxy_pass приходится указывать список методов).
5. В какой-то момент volume заполняется и сам он расти не будет, при этом, насколько помню, его максимальный размер в коде ограничен. Нужно либо править код сразу (исходя из своих предположений о том, сколько будет храниться), либо вовремя подключать больше томов.

Т.е., в общем-то, мелочи, а не проблемы. Нужно заранее прикидывать сколько места будут занимать данные, использовать не антикварную версию Go и, конечно же, тестировать. Что отдельно радует (хоть это и не показатель), за несколько лет оно ни разу не сегфолтилось, не падало из-за необработанных исключений и не зависало из-за какого-нибудь deadlock.