Engineering Note
We didn't move to Elasticsearch because Active Record was slow.
We moved because search was starting to behave like a product of its own.
Initially, Rails + PostgreSQL was enough.
Simple filters.
A few indexes.
Straightforward queries.
Then the requirements grew:
* Full-text search
* Multiple fields
* Relevance ranking
* Typo tolerance
* Filters + sorting
* Thousands of searches per hour
We kept adding database indexes and query optimisations.
It helped.
But eventually, we were making PostgreSQL handle two very different workloads:
Transactional data + search
That's when we introduced Elasticsearch.
PostgreSQL remained the source of truth.
Elasticsearch became the search layer.
The important part wasn't the migration itself.
It was accepting the new trade-offs:
More infrastructure.
Data synchronisation.
Indexing failures.
Operational overhead.
In return, search became independently scalable and much easier to evolve.
Important learning:
Don't introduce Elasticsearch because your database query looks complicated.
Introduce a dedicated search engine when search requirements have outgrown what your transactional database should reasonably handle.
The best scaling decision is often not replacing the old system.
It's giving each system one job.
Initially, Rails + PostgreSQL was enough.
Simple filters.
A few indexes.
Straightforward queries.
Then the requirements grew:
* Full-text search
* Multiple fields
* Relevance ranking
* Typo tolerance
* Filters + sorting
* Thousands of searches per hour
We kept adding database indexes and query optimisations.
It helped.
But eventually, we were making PostgreSQL handle two very different workloads:
Transactional data + search
That's when we introduced Elasticsearch.
PostgreSQL remained the source of truth.
Elasticsearch became the search layer.
The important part wasn't the migration itself.
It was accepting the new trade-offs:
More infrastructure.
Data synchronisation.
Indexing failures.
Operational overhead.
In return, search became independently scalable and much easier to evolve.
Important learning:
Don't introduce Elasticsearch because your database query looks complicated.
Introduce a dedicated search engine when search requirements have outgrown what your transactional database should reasonably handle.
The best scaling decision is often not replacing the old system.
It's giving each system one job.