What is disadvantages of query database smart service

What is your use case?
Query databases and record types are not directly comparable; they serve distinct purposes.

EAch one of them are totally different, and serves for different purposes.. even when both of them works againt database....

When you work with Record Types, you work with an strcutured data model, but when you work with query database you are working with queries.

For example, if you have two records in Appian, but you need two execute an SP, a view, or just a query with an special agregation, you use queryDatabaseSmartService....even when you are working with the same tables...

I will not say those are disadvantages as others have mentioned earlier. Each serve its purpose.

The main difference would be that when querying from records, you are trying to get the data from the memory i.e., cache which gives you a quicker response. Also you would not perform a direct query on the database.

Heres something from the documentation which will make it clear

"Data sync caches your source data in Appian.

Think of it like a cache on your web browser: when you cache web content locally on your browser, your site content loads faster and improves the speed of your browsing. The same applies when you sync your source data—Appian only has to execute queries against your synced data instead of the external source, so your record data will load faster. In addition to faster queries"

https://docs.appian.com/suite/help/22.2/records-data-sync.html#how-does-data-sync-work

The main thing to remember is that the the Query Database smart service uses SQL, while querying and writing data through records uses the structure of the data model you've already defined in your application, which should make it easier and faster.

Since Appian is a low-code platform, using records is our low-code method of interacting with your database and other systems. At this point I'd only recommend using the Query Database smart service if something isn't obviously supported through records (which is getting pretty rare at this point).

Can you give some more context to the question? Are you trying to make a decision on which one to use?

The Query Database smart service is pretty horrible - cumbersome, unflexible, and also fairly dangerous in the wrong hands.  I practically never use it if it can be avoided at all.  The only time I ever willingly use it is to execute a specialty SQL statement that checks the next available ID in a database and reserves an entry using that row at the exact same time, to avoid a weird race condition.  And under most circumstances this can just be done with a regular Query Entity call and clever process node arrangement.

For everything else, you should be using Query Entity (since you said RecordType data is not usable to you - if it were, it'd probably be best to be using that at this point).  I don't know of any reason to ever use the Query DB smart service when you could be reading and/or writing using Entity data.  I know there are some extreme edge cases, but they're rare at best.