How we sped up resident search in the PDP Mobile admin panel with Elasticsearch

“Why do I enter a resident, and the admin panel thinks longer than it would take me to find them in the list by eye?”

It’s not a pleasant question to hear when we’re not talking about some rare report, but about a basic operation in a property management admin panel. In PDP Mobile, administrators search for users constantly: by residents, units, assignments, and tickets. While the data set is small, SQL queries behave just fine. Once the system has tens of thousands of residents across several residential complexes, search starts to run into the fact that the database is good at storing transactional data, but not at pretending to be a fast full-text engine.

We moved user search to Elasticsearch. Not for the sake of architecture, but because the admin workflow became too sensitive to latency: the operator enters a string, waits for the result, and loses momentum.

Where SQL stopped being convenient

Search in a property management system rarely looks like a neat filter on a single field. In a real admin panel, people enter a fragment of a name, phone number, address, unit, or something else the operator has in front of them. The data is spread across buildings, sections, units, and resident relationships.

You can make SQL search across multiple fields. You can add indexes. You can rewrite queries. But in our case, the volume had already reached tens of thousands of residents, and not in a single building, but across several residential complexes. For an admin panel, that became noticeable: search stopped being an instant supporting feature and turned into a separate wait.

The solution was pragmatic: keep the data where it lives, and hand fast full-text user search over to Elasticsearch. For the operator, only the feel of the search form changes. For development, it introduces a separate path that needs to be monitored: the index, updates, and consistency with the main system.

What we moved to Elasticsearch

We moved the task of fast user search in the property management admin panel to Elasticsearch. This is an important boundary. We did not move business logic there, and we did not try to turn the search index into a new primary database.

The index is there to answer the question: “which users match the entered string?” After that, the admin panel can open the card and continue working with the data in the usual flow.

The most useful debate was not about Elasticsearch itself. That part is straightforward: if you need fast full-text search over a large set of entities, it’s the right tool. The debate was about the responsibility boundary. Where does search end and exact filtering begin? What should we show if a user is found through a related unit? How do we avoid turning the index into a dumping ground for everything?

It’s easy to overdo this and start indexing every entity “for the future.” We tried to stay focused on the original pain: the administrator needs fast resident search. The narrower the purpose of the index, the easier it is to explain odd results later and fix mismatches.

DevFeedbacks as a separate signal

Alongside search, another layer of the task surfaced: user feedback. In PDP Mobile it is collected as DevFeedbacks, and we started splitting it into categories:

• charges;
• metering devices;
• payments;
• units;
• residents.

This is not about query speed, but about prioritizing improvements. When feedback sits in one pile, it’s hard to tell where the pain is more common: in payments, meter readings, or unit cards. Categories at least provide a workable basis for analysis.

The connection to search is direct, even if not technical. The admin panel is where data problems become visible. If a user can’t be found, the wrong resident is found, or it’s unclear which unit they belong to, that quickly turns into a support request. That’s why speeding up search and classifying DevFeedbacks became part of the same story: less guesswork when working with residents, and a clearer queue of fixes.

A question for those who have built admin search

Our solution ended up like this: for tens of thousands of residents across several residential complexes, we moved full-text user search to Elasticsearch, and started splitting feedback into categories so we could see which parts of the product need attention.

The remaining question is where the right boundary lies. Elasticsearch speeds up search well, but it also adds the index as a separate entity: it has to be updated, checked, and not overloaded with unnecessary data.

How do you handle a similar scenario in admin panels: up to what scale and complexity do you keep search in SQL, and when do you move it to Elasticsearch or another search engine?