I have a question in relation to encryption on the server.
So I am making a chat/mail system in which users are able to send messages to one another.
Before the message is sent, I run a script on my backend that encrypts the message, my question has to do with the decrypting.
In my database, I have a table that holds the encrypted messages, I do not want my database to hold any decrypted message. How do get the decrypted message to the users without holding any decrypted messages on my server?
Thank you.
Your question is almost certainly misguided. You usually don't want to encrypt messages from one user to another on the server, and you almost never want to decrypt them on the server.

First, the whole point of public-key encryption is that nobody but the user and their own trusted software has access to the user's private key.
You don't want to store users' private keys on the server—that would mean that if your server gets hacked, or some disgruntled employee wants to sabotage your company, they can decrypt every message in the world. Most users won't trust such a system, and they shouldn't.
So you have to do the decryption on the receiving user's client, where their private key is accessible.

Usually, you also want to do the encryption on the sending user's client. Otherwise, every message is being sent in plaintext to the server, where a hacker (or an unscrupulous server company) could easily steal it before it's encrypted. Again, users won't, and shouldn't, trust such a design.
This means the sending client needs the recipient's public key, of course. But that's easy to manage: You store everyone's public key on the server, and add a command that the sending client can use to fetch the recipient's public key.
In some designs, you want to use a separate out-of-band mechanism for sharing public keys instead. For example, if you're using GPG, and want to rely on its web of trust instead of using your server to manage trust in identities, you'd give the client a way to import public keys and store them, or you'd give it a way to interact with an existing key store.

If you really want to do PK encryption entirely on the server, you can. It just doesn't provide much security benefit.
To do this, you could store every user's private key in the database. Then, you just fetch the encrypted message and the private key and decrypt it before sending. Then the plaintext is only available in some short-lived memory buffer, instead of in the database. But notice that this is no better than just not encrypting things at all. Sure, anyone who can access your database can't directly get the decrypted messages—but they can get the encrypted messages and the keys needed to decrypt them, which is just as good. In fact, it's better for the attacker, because now they can decrypt other messages using the same private key, sign messages to impersonate the user, etc.
Alternatively, you can have the user submit the private key whenever they want to fetch a message. You then pull the encrypted message out of the database, decrypt it with the private key, and send it to the user. Now both the private key and the plaintext live only in temporary memory. But this still adds almost nothing over not encrypting at all. The messages—and, worse, the private keys—are traveling as plaintext over the open internet. Plus, anyone who can hack your server can't pull the private keys out of your database, but they can just store them as they come in.
Public and private key encryption delivery