It depends on your threat model. Will a potential attacker have access to the machine? Might they be able to escalate their authority enough to either dump the process space of the application, or to attach to it as a debugger? Or if you’re concerned about the attacker downloading the entire database and being able to decrypt all the images, consider moving the decryption process or image storage to a separate machine with better security. Or you could encrypt each image with a unique key, and keep each key in a remote database, and use the user’s database to store their master decryption key.
If your concern is that a rogue or compromised client will download each decrypted image in an attempt to acquire the entire database, consider a monitoring process that alerts you to excess activity. Also, consider slowing down each key or image request (this process is known as “trust anchor dragging”) making it harder for anyone to download the entire database in a reasonable amount of time.
Rather than use a private member to store the key, use your platform’s provided cryptographic service library. On Windows, use the CryptoAPI. In Java, use the Cryptographic Service Provider. These tools are designed for secure storage of keys.
If you can’t use the cryptographic library, the key might be persisted in swap space, and end up on your hard disk. If you have the option in your language (C/C++, go, ASM) consider allocating memory using your operating system’s secure memory function, such as mlock() or VirtualAlloc().