Public key crypto instead of hashing passwords in a database Suppose I want to keep a client's password database secure (not in plaintext), while still having access to the plaintext password.

Now I generates a public/private keypair. Then I send the public key to all servers, while keeping the private key on a heavy-secured, airgapped computer. Now, instead of salting and hashing the passwords, I salt it and then encrypt it with the public key, and store it in the database.

The method to store the password is Encrypt(password+salt). The encryption algorithm is deterministic. (If the input is the same, the output is the same.

If the bad guys now hack my server, they won't be able to get the passwords, since they don't have the private key to decrypt them.

If I ever need the passwords, I can just copy the database to my airgapped machine and decrypt the passwords in the database.

What are the disadvantages of doing so?
This is a really bad (and somewhat pointless) idea (if you do it on your own), because it provides less security than standard hashing and should only be considered if password escrow is a necessary feature.
If you don't need the password escrow (= recover the password using the heavily secured airgapped private key) you can simply password-hash the password using a modern scheme such as Argon2 which won the Password Hashing Competition.
If you really need the escrow functionality you should use Thomas Pornin's (who's here around sometimes) Makwa password hashing scheme which has been recommended by the Password Hashing Competition (PHC) for special use cases (as yours).



Now for the obvious approach and why it is bad.

I'd assume you would implement this by applying straight, raw RSA to your passwords and compare the results.

Now, if you just do $E_S(PW)$ without any randomness, you're basically creating a one-way hash function (with a backdoor and without compression) which is unsalted and doesn't use stretching (like for example raw MD5 password hashes). As your update reveals you indeed planned on using salting so it's not completely bad, but still far from optimal.
The second issue is that you won't get a compression. Meaning any password will occupy 256 bytes in your database as opposed to the standard 16 or 32 because you need the whole RSA encryption for key escrow.
The next issue is that you could add a salt, but because it's RSA you need to use a big salt, because there is an attack with run-time $O(\sqrt{m})$ meaning you need at least another 32 bytes salt, which further increases storage penalty.
Now you can also quite fastly compute the RSA encryption, meaning brute-force attacks won't be slowed down. This would mean you'd have to apply RSA multiple times are do some intense pre- or postprocessing without loosing information which is quite not easy.

I presume you didn't think of all these issues (yet), so better go with Argon2 or Makwa.