No... well.. not necessarily.
So long as you have a strict convention and common parsing and validation means (scripts, libraries etc) readily available you are good to go.
Take for example packaging and dependency management systems (Maven, NuGet and the likes). Though many will use specific files for metadata to store the more advanced information, basic information is often part of the file name itself. Relying on strict conventions the file name can contain the most pertinent information about the package : it's vendor, it's name, it's version, it's type. Sometimes that is all you need... 4 or 5 short pieces of information.
If the metadata is simple then a file naming convention makes perfect sense requiring nothing to put in place. It can be strengthened with very simple tools and scripts, no database needed, no specialised infrastructure just a few scripts and a naming convention.
If nothing out there quite does what you need and your needs are simple i'd start with this.
your requirements outgrow this convention ? extend it with a proper metadata file.
You later need better search for this ? There are already good solutions out there for searching files that get get you to where you need.
It's not that I dislike databases, quite the contrary they are really powerful and useful but they require some amount of overhead to get going. They need to be installed, backed up, maintained, you will need staff that, if not completely dedicated, will need to dedicate part of their time to this infrastructure. They are also more complex and cryptic to the laymen, loose the dev that set you up and your system will be stuck in time until you find a replacement.
Never underestimate the power of low tech with the proper oversight it can get you a long way.
And by the time you outgrow your low tech solution you will have gathered all the experience and requirements to implement the perfect system for your needs.