I'm not going to go into the whole question of whether you need a singleton at all or not. I feel that's out of scope. However, if you feel the need for a singleton, there are two issues around it: the first is instantiation, the second is thread-safe access.
As far as singleton instantiation goes, your implementation is a good one.
My go-to reference for singletons in C# is this article which outlines different implementation. The one you've chosen - a static field which is instantiated the first time your type is accessed, in a thread-safe fashion, and retrieved though a read-only property, is a good enough implementation.
However, even if the singleton is instantiated once, calls to it are not thread-safe. If two threads call
MySingleton.Singleton.BuildAllGrowers at once, you'll have collisions - both threads will try to add to the Hashtable at once, and the most likely result is an exception when you try to Add() an item that's already been added.
If your aim is to have a hashtable that's lazy-loaded from the DB the first time it's accessed, your best bet is using the fifth method in the article above (using the nested class), and having the BuildAllGrowers method in the nested class's static constructor. That way it will happen once, before the first caller can access it.
In addition to the issue of the Singleton, I really have to ask - Hashtable?!
Hashtable class has been deprecated since 2005, and should never be used in projects based on .NET 2.0 or newer, which MVC certainly is. You should use
Dictionary<K,V>, which in your case would probably be
Dictionary<int,string> - they're type-safe (which
Hashtable is not) and just as efficient.