А никто не говорил про выборки ;-)))
Тем более большие и сложные ;-)))
А если поиск можно привязать к физическому порядку следования записей (и этого будет достаточно), то и индексы становятся не нужны ;-)))
Так что все зависит от задачи. Не нужна СУБД - ну, значит, и не нужна. Как станет нужна, можно данные будет и сконвертнуть ;-)))

Так елки! Видывали и мы плоскотекстовые (куда там типизированные ;-)) файлы на нехилых швейцарских спектрометрах. И ничего, работали ;-)
Пока система хранения данных с контроллера есть вещь в себе, все будет ОК и без СУБД. Надо будет интегрироваться - делаем, к примеру, так:
Произвольный файл+интерфейс импорта в СУБД+СУБД
- кто говорит, что это работать не будет? А?
Если для контроллера произвольный файл - копилка, для СУБД он может стать источником. И все в шоколаде ;-)

Кириллл, а ты в своем движке для работы с типизированными файлами и буферизацию записи на диск предусмотрел? Сбои ведь когда в основном происходят: когда начатая операция записи на диск не завершена. Если операция не начата, то это, с точки зрения структуры файла, вроде как и не сбой (файл в предыдущем состоянии остался, ну, правда, последние данные с контроллера пропали, конечно). Так вот, свои файлы чем характерны: своими методами доступа к ним ;-))). Если у тебя есть буферизация, то по окончании записи не забывай принудительно сбрасывать содержимое буфера на диск - так минимизируешь риск потери данных из за тех же выключений питания в процессе работы. Ну и запись старайся выполнять единовременно только целыми записями - что-то вроде коротких транзакций (хотя это будут и не совсем транзакции, конечно, но уже почти ;-)). Ну, заведи помимо файла данных файл журнала. Или копию файла данных. Структуру файла выбери такую, чтобы была устойчивой к сбоям. Архивируй время от времени. Используй контрольные суммы. А в остальном - защищайся аппаратно. Ставь рэйды, упсы и тыды ;-)
Это все хорошо, если у тебя один контроллер пишет в один файл одним процессом. Если много процессов пишут в один файл - то есть смысл сразу подумать о СУБДовом движке (хотя и самому можно помучиться и разрешить возможные коллизии, но дело это, с учетом того, что все уже реализовано до нас, и в лучшем виде, не благодарное).