> Скажите, у вас часто файлики на системе меняются/обновляются? У меня - да. Так вот эта
> программка тоже часто должна перепарсить каждый из них и сложить обновленное в базу.

Если оно будет часто и много сканить файлы, пересканивая полдиска - оно висту по тормозам сделает, для начала. Будет так же клинить комп из-за постоянной занятости диска чтением-записью. А остальные при нужде что-то прочесть\записать встанут в позу рака, ожидая пока диск сможет осилить и их запросы. Как по мне - так я такие штуки на моем десктопе срубаю первым делом, если они есть. Я и так знаю что и где лежит а в крайнем случае - легко нахожу по имени файла (ed2k сетка научила меня полезному фокусу - забивать все потенциальные "теги" для "поиска" ... прямо в имя файла - тогда Kad может запубликовать "кейворды" в "распределенный индекс" и народ может найти файло "распределенным поиском" по кейвордам, до кучи оно помогает и поиску по локальной ФС, да и просто глядя на имя файла понимаешь о чем же оно - без его открытия и затрат на это времени).

> И каждый раз пока будет складывать чтение не будет возможным

1) Это в любом случае проблемы демона который будет индексированием заведовать.
2) В SQLite совершенно валидно если есть много reader-ов и не более 1 writer'а. Для десктопа - это трижды за глаза! Более того - такая конкуррентность канает даже для половины серверов (серверов с интенсивными записями в БД где реально нужна конкурентнаая запись нескольких writer-ов на этой планете не так уж и много).

Цитирую понятно чей FAQ:
----------------
Can multiple applications or multiple instances of the same application access a single database file at the same time?

    Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
----------------

Для десктопного индексатора - более чем за глаза... можно даже не паузить индексированеи пока демон вам что-то ищет как видите. А если у вас множественные одновременные записи - наверное это уже все-таки не десктопный индексатор а крЮтой сервак БД :)

> А почему мускуль или постгрес оперативку будут жрать?

Потому что для того чтобы они нормально работали - им надо кучу оперативы под кеши и прочая. И по дефолту они не очень скромничают с жрачем оперативы. Ну, сервер БД обычно ставится для того чтобы быть сервером БД, собссно. И там скромничать глупо - надо юзать ресурсы с пользой. Вот только десктоп - не сервер БД, он поставлен не для того чтобы отдать все свои ресурсы движку БД, так что на нем наглеть не полагается :P.

> Это уже задача планировщика оперативку распределять

Планировщика? Какого планировщика и где? Если что я про кеши самой СУБД говорил а не про дисковые кеши ОС. И зохаваную демоном сервера БД оперативу у него просто так не отберешь, пардон.