На Ваш вопрос нет однозначного ответа. Аналогично вопросу: что быстрее, поезд или автомобиль? Кто то будет сравнивать советский поезд с бугатти, другой будет сравнивать японские скоростные поезда с жигуленком.
Базы с поддержкой SQL бывают разные: MySQL, MsSQL, Oracle и т.д. У каждой из них своя методика работы с кэшем, индексами, памятью. Очень многое зависит от размеров базы, размеров таблиц, построения индексов, самого запроса, настроек сервера БД и операционки. Если база нормально сконфигурирована, таблицы с нормальной архитектурой, правильно построены индексы, сервер обладает достаточным количеством памяти, то запрос будет быстрее большинства самопальных решений для работы с файлами.
Если же файлы проектировала группа высококлассных специалистов, обвязка спроектирована именно под такие запросы, то выигрыш по скорости может быть значительным в этом варианте. Но такой "путь самурая" предполагает перенос объема вычислений в более быструю область сервера: память-процессор. У тебя будет меньше работа с дисковой системой, но вся логика работы приложения должна быть перелопачена под такой вид данных. Без фундаментальных знаний алгоритмов программирования и математики-информатики в целом, такие велосипеды лучше не городить. Теория графов, матрицы, хеши, алгоритмы сортировки должны быть у тебя на уровне выше институтского. Про удобные таблицы на 5-10 полей можешь забыть. У тебя будет куча небольших упорядоченных файлов со списками ключ-значение. Индексы, хеши, хеши по хешам, индексы по хешам и т.д. - это на долгое время будет твой кошмар, который ты должен будешь представлять у себя в голове. Работа с файлами напрямую не имеет смысла, если ты не планируешь создавать высоконагруженное приложение с большими объемами данных. В этом случае у тебя проработка архитектуры хранения данных займет на порядок больше времени, чем проработка архитектуры базы. Предварительный поиск по одному символу, по двум, трем, ссылка на файлы, которые содержат следующую часть, по которой уже идет поиск. Не забудь блокировки файлов, обработку ошибок доступа, обработку оборванных транзакций, уникальность значений, индексов или ключей и т.д. Отсутствие удобных select-ов с join-ами и блэкджеком потребует от тебя проработки возможных видов запросов, чтобы сам вид хранения данных оптимизировать под кастрированные возможности. А из запросов будут только аналоги простейших "SELECT xxx FROM file_yyy WHERE Id=zzz", "UPDATE file_xxx SET yyy WHERE Id=zzz", "INSERT INTO file_xxx yyy=zzz", "DELETE xxx FROM file_yyy WHERE Id=zzz". Этими 4-мя операциями тебе придется обходиться.
Сейчас есть уже готовые "велосипеды" noSQL, но это не "путь джедая". Типовой сайтик, с десятком или сотней уников в час не стоит такого геморроя.