Before even considering removing a feature (which took resources to make) think about the following:
Who uses it? Depending on the application sorting might be a feature which only power users use and cutting your power users from a feature is a bad move. In my experience (and I'm pretty sure this applies to many other developers) power users are the ones who give you the most constructive feedback about your product. Power users are long lasting users. They don't just check out your app and then move to the next one. These are the customers you want your user base to be overflowing with. If a user is not satisfied with your app the chances of him becoming a power user are gone through the window.
Is this an unintentionally hidden feature? Perhaps the currently used design of your app's UI doesn't really show the users that sorting is even possible so most of the users don't really know about it and thus are not using it. Doing something in this direction might yield positive results or at least give you a more concrete evaluation of the usage of this feature. If you application has a tutorial of some sort or at least an overlay with helpful information about what's what, try to add the information about the sorting somewhere (more, if already present) visible. I'm often surprised how many users miss obvious (to me) things. A good user interaction starts with teaching the user in the most fast and seamless way how he/she can use your product. Sometimes not finding a certain feature might actually lead to the user dumping your app and going to your competitors.
As for the development aspects (since I'm a software engineer myself):
Issue getting the data in postgresql because of the amount of call
needed to update this data, just so that we can sort of it, if less
than 5% of our users are actually using this to sort.
If something is seldom used and yet introduces a regularly occurring overhead then something is wrong with the way your calls work. If 5% of your users use the feature than only in this 5% the overhead should occur.
Won't scale forever the way it is now
Multiple options here: apply sorting on subsets and then merge the results (-> sort of merge sort), create pre-sorted views (if the data doesn't change that often you can offer the user a really fast sorted list since you have already done it on the server), put a cap on the amount of data that can be sorted (for example if you have discovered that after 1000 entries sorting produces too much of an overhead limit sorting to only 1000 entries -> allowing the user to sort only a selected subset is also an option) etc.
Realtime. Like, really real-time. Every time you refresh the page you would see the latest performance (and not 2 minutes after or whatever)
I think we have a different understanding of what real time is. If you really have a real-time view of your data (which the user can view through a web page) this would mean that the page has to be updated constantly with very, very minimal latency. In this case the sorting would be the least of your problems (everyone loves using a mobile app which sucks the available (and expensive!) bandwidth dry in no time...). Again what you are describing here looks more like an implementation issue or general design problem with the architecture (backend here mostly) then something related to the sorting feature.
Better performance not only for the list, but for the whole product.Less "freeze" in part of the apps
See previous quotation above.
Cost optimization, because we wouldn't need to compute it every 2 minutes, although no one would actually see the data (during night or whatever). We would compute it only when necessary
This is something which totally depends on the application and the scenario(s) it handles. Since we know nothing of it, can't give you any feedback.
What strikes me as odd is the fact that you mention that your lists can reach even 100 items. Let me tell you something - 100 items in a list even for an app is not much. I would say that your developers didn't do a proper job if sorting a list of 100 items (I presume that each item doesn't contain megabytes of data but if so, what is such data even doing in a mobile app?!) poses such a big problem. I know nothing of the technology you are using (JS+HTML, Qt, Java etc.) but there are many ready-for-use list components which are optimized for handling huge number of items. Perhaps your developers have picked the wrong tools for the job?