Is there a way or how to predict the output size as a result of encryption? Is there a way or how to predict the output size as a result of encryption from 3DES, AES-128, AES-192 etc ? So that I know how to store them in the data in DB given a known possible clear text length.
This depends on:


Precise choice of encryption algorithm
Choice of representation for the ciphertext
Size of additional metadata stored with each ciphertext


On #1, 3DES, AES128, AES192 are block ciphers, so they're not ready-to-use end-user variable message length encryption algorithms.  You use them in the context of some mode, which you should really think of the "real" encryption algorithm.  For example, one very common mode nowadays is GCM (Galois Counter Mode), which instantiated with AES we would call AES-GCM.  Some modes require ciphertexts to be a multiple of the block cipher block size as well, which means that plaintexts get padded to fill up a block. 

So first and foremost, the size of a ciphertext depends on the mode.  AES-GCM ciphertexts, in binary, are generally 16 bytes longer than the plaintexts.  And you may need an additional 12 bytes to store the nonce.

Now, #2 ("choice of representation for the ciphertext"): ciphers operate on binary data and produce binary output.  But many systems and developers are very allergic to binary data and prefer all data to be in some sort of plain-text format (e.g., XML, JSON).  So the raw binary output of a cipher is in practice often encoded into ASCII using a binary-to-text encoding like Base64.  This adds about a 33% overhead over raw binary size.

Point #3 ("size of additional metadata stored with each ciphertext"): Often you want to store additional information with each ciphertext, for example metadata related to key management:


A key identifier that allows you to locate, for each ciphertext, the key that was used to encrypt it.
An encrypted data encryption key (DEK).  This is part of a common key management strategy where ciphertexts are encrypted with an ephemeral DEK key, which is then encrypted with a master key (a key encryption key or KEK), and the encrypted DEK is stored alongside the ciphertext.


So you need to work out a number of details to get a precise answer to your question.