Actually, an Excel sheet can be a database. MS Excel is (or, rather, was) as direct feature-compatible competitor to Lotus 1-2-3, and the 1, 2 and 3 of Lotus 1-2-3 were "spreadsheet", "database" and "business graphics". The VLOOKUP function is part of Excel's database module. It's a common mistake to conflate "database" with "RDBMS"; not all databases are relational (and none of my favorites are, though I've gotten used to shoehorning fundamentally non-relational data into something like MySQL for low-end web development -- or worse, something like Oracle for enterprises that need to feel they're getting their money's worth out of their license).
That being said, the problem here is the database engine. In order to use an Excel sheet as a database adjunct to a web application, you need a runtime engine that can read and write Excel. That's not going to happen on free or low-cost shared web hosting on a LAMP (Linux, Apache, MySQL, PHP) stack. You need to move the data to a different database -- either MySQL or SQLlite (PostgreSQL isn't supported on free hosting here, though it is on paid plans). MySQL is probably the batter option, not because it's the best fit for your data, but because nearly everybody here is using it in one way or another so it's a lot easier to get help when you need it. (And there are a lot of books and websites that can offer additional help, though many of them are based on older versions, outdated methods and "cargo cult" programming techniques.)
The simplest way to do things would probably be to dump your Excel sheet to a CSV (comma-separated values) file and import it into MySQL. Simplest, but nowhere near best. You'll want to spend some time first designing the database (which, at this point, is probably nothing more than a single table). That means taking the time to figure out what data types each of the columns ought to contain, and determining the sizes needed to suit (integers, long integers, floating point numbers, text columns with a maximum length), which columns are (and which are not) allowed to be empty (or NULL), which are going to be used regularly for lookups (they should be indexed) and which are knowably unique for each entry (the primary key, and that may be something you need to impose on data that don't naturally contain unique values).
There is really far too much to cover in a general reply -- one could easily write a thousand-page book that just skims the surface (and many have). If you want any real help, then you need to make you question a lot more specific. What do the data look like? Where do you want to use them? How are you planning to determine what the user can see (is it based on a login, the time of day, day of the year, etc.)?
It's not just a matter of "hooking things up"; there's programming and database design involved.