Let's split this in two:
Encrypting the user's data with their password
Sure, why not, if the data is private. In practice, the server will need to handle it in plaintext, but the data can be left encrypted as long as the user is not logged in. Though in a message forum, messages that should be readable by other users can't be subject to this treatment, so it pretty much only works for private messages (addressed to a single user or a known group of users).
As always, you don't want to use any password directly as a key, but run it through some key-derivation function like PBKDF2. This will slow down brute-force searching the password, and give the possibility to generate longer keys than the password is (in case that's required).
As for password changes, the usual practise is to generate a random strong key, used to encrypt the data, and then store this key encrypted with (a key based on) the user's password. This way changing the password only requires re-encrypting the master key, not all the data.
Though the downside here always is that if the server is compromised, it may be configured to save the user's password in plaintext when they next log in, or just save all the data unencrypted.
Encrypting all data with the server's key
Here, I wonder what the expected threat is? A software attack that leaks all the (encrypted) data, or the server hardware getting lost? Protecting against misplaced hardware would require encrypting the data with a key that is not on the system itself, but perhaps entered by hand. The easiest way to do this would be to use some full-disk encryption solution.
As for an attack that somehow leaks all the data, but doesn't allow the code itself to be modified, sure, encryption with a fixed server key should help. But do you need to, if the data is already encrypted with the user's key? How feasible is it that the encrypted data would leak but not the server's key, given that the server is going to need that key for almost every operation involving the data? I have to say I don't know.
(If you're thinking SQL injections, better fix your practices on that where the problem is. On the other hand if you're thinking of a vulnerability that leads to arbitrary code execution, then the attacker just got the server's key, too.)
Combining the two
The obvious way to combine two keys would be to encrypt the data twice, using both keys, such that the stored data is C = E(K2, (E(K1, P)). This is what would happen in the end if you store encrypted data on an encrypted drive, but it's a bit of a waste or work.
Another way would be to derive the actual encryption key from the two keys (server's and user's) using a KDF (again). Though with random-looking inputs, I think you might get away with combining two fixed-length keys with a strong hash like SHA-256, so C = E(H(K1, K2), P).