Yeah, storing stuff in the Cloud seems to be all the rage!! ... we don't store anything there, yet, except our backups. Our Email, SQL Databases, DMS, Intranet Website are all in-house on servers inside our own buildings. So you would be able to host a DMS (or any SQL database and its applications, I suppose) in house for as long as you prefer that method.
It sounds like you have "encapsulated" everything you need in either the UNC path and/or the Filename itself? A DMS, or a Database which stores the UNC and Filename, would be able to do the same job (maybe better, maybe no worse). I'm not seeing a major gain there though if you just store UNC and Filename. For me the major gain comes when you store other useful data in association with your Filename. It sounds like your colleagues know what keywords to use for a search - presumably they form part of either the Filename or the UNC path?
For me the main benefit of a Database would allow other data to be stored. Maybe your filenames are "ClientA-ProjectB_yyyymmdd_V999.DOCX" or somesuch, where you encapsulate the Client Code and Project Reference, along with the date and version number or whatever. For me the document could be called "FRED.DOCX" because the Client Code, Project Reference, Create date, Version Number etc. etc. would all be additional columns in the database table. If the project moved from ClientA to ClientB I can just change that value in the database (and I also have an audit of when it changed, by whom, and what it was previously). I can report on all documents for ClientA, or perhaps the narrower search I need is: "All documents for ClientA on ProjectB between date XXX and YYY". SQL is incredibly fast at running a search like that, whereas anything just using the filesystem, or an index list of the file system, is going to have to use pure horsepower to find matching entries. The difference is that as the size of the index grows then SQL will scale MUCH better than a pure-horsepower solution.
So for you to want a database solution you problem need to also be wanting to store multiple Attributes or Properties - Meta Data if you will - about each document. That information would be entered when a document was added to the system. For us, using our DMS, when we "check in" a document it asks us those questions - Which client? Which Project? What Title? and some other "keyword" and "attribute" type things - e.g. a checkbox for whether it is Regulatory related (which is a major thing for us).
Other things that SQL will do:
Not get corrupted. SQL Server is very robust, and uses a twin-file system of Data and Log. Every transaction (i.e. a change to the database [slight oversimplification]) is stored in the log, sequentially, and applied to the data file. It is possible to recover a Full Backup from, say, last night and then replay, forwards, all the Log file backups to a given date/time. So if someone [or a software bug ] accidentally deletes half the customers you can restore to just-before-that-happened.
Also, if the Data file does become corrupted then you can restore from a Full Backup before the problem (e.g. a disk controller is found to have been corrupting data since Tuesday Night) and then play forward the Log Backups. Most times you can do this right up to "now" and have zero data loss, in particular if the Data and Log files, and their backups, are stored on different disk drives / controllers - because a corruption in one is unlikely to also effect the other.
Data is consistent - by that I mean that if you say "Update the Files Table and the Archive Table and the User Statistics Table" then SQL can perform that as a single transaction. Either all three things happen, or none of them; it will never just do the File Table Update on its own. So if you get a power cut / server crash in the middle, or a critical program bug, then SQL will rollback any partially completed parts of the transaction.
SQL backups can be compressed. That saves about 80% of the disk space and 40% of the I/O (i.e. "time")
You will still have to backup all your files (unless you store those, too, in the SQL database - but there are good reasons for both DOING and NOT doing that).
Back in the old forum when anyone got to 1,000 posts the Zen Master, Merkin, bestowed a Custom Title on the poster. There were lots of great titles - like "SQL Warrior Princess" who subsequently became "Almighty SQL Goddess" So ... back in 2004 I eventually got to 1,000 posts and was given the unbelievably august title of ... "test" ... whilst Merkin had been away there was some slightly ... errmmm ... "off topic posting" and I got the blame ...
I'm sure it is of no great interest anymore, but just in case here's a link to the story: