I would suggest database tables, one per list.
The enumerations exist to list the permissible values for one or more attributes. Likely you'll want to enforce these restrictions within the database, too. For that you need foreign keys and for those you need to have the enumerations in tables. It is best to have one table per enumeration so the foreign keys are simple to define and obvious in their intent.
Having tables and foreign keys does not necessarily mean a join in every read. If the enumerations are stable over time and have short, meaningful codes then these codes can be propagated to the referencing tables. Say we have an enumeration of cardinal directions - North, South, East and West. These are stable over time. They have short, meaningful codes: N, S, E & W. Anyone seeing a code will understand the meaning given the context. Hence having the foreign key reference the single letter code will do the job and can omit a join. In contrast, the habitual design will have a surrogate key in the enumeration table. As this is typically a meaningless number, joins will still be required to return human-understandable values.
Once you have the enumerations in tables does it make sense to repeat them in the application? To repeat them as additional code would be a mistake. There would be two list - one in the app, one in the database - which have to be kept synchronized. Such duplication is a common source of error. To have the values cached in the application, as opposed to reading the table each time the enumeration's values are required, may be beneficial. It depends on the app, how often these enumerations are referenced, how much memory is available etc. etc. Since you're considering hard-coding the values, re-starting the app to pick up new values from the database shouldn't be a problem, though other solutions are possible.
Using database enumerations could work if you are very sure the list is single-valued and will never shrink. Removing an enumeration value is tricky. Adding new values requires elevated privileges. Additional properties (e.g. (direction, code, bearing) = (South, S, 180)) are not possible.