What is disadvantages of query database smart service

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.

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.