# From Static Catalogue to Smart Discovery: Engineering Lightning-Fast Search at DreamSetGo

DevFeed: [From Static Catalogue to Smart Discovery: Engineering Lightning-Fast Search at DreamSetGo](<https://devfeed.tech/articles/from-static-catalogue-to-smart-discovery-engineering-lightning-fast-search-at-dreamsetgo-22620.md>)

Original publisher: [Read original article](<https://medium.com/dreamlockerroom/from-static-catalogue-to-smart-discovery-engineering-lightning-fast-search-at-dreamsetgo-d99c9a91197b?source=rss----5c7a7f580b01---4>)

Author: Dream Blog

Published: 2026-03-09T13:50:30Z

Content type: article

Language: en

Sources: [Dream11 Engineering](<https://devfeed.tech/sources/dream11-engineering.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Microservice](<https://devfeed.tech/topics/microservice.md>), [systems](<https://devfeed.tech/topics/systems.md>), [elasticsearch](<https://devfeed.tech/topics/elasticsearch.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [dream-sports](<https://devfeed.tech/tags/dream-sports.md>), [elasticsearch](<https://devfeed.tech/tags/elasticsearch.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [open](<https://devfeed.tech/tags/open.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [search](<https://devfeed.tech/tags/search.md>), [search-engines](<https://devfeed.tech/tags/search-engines.md>), [sports](<https://devfeed.tech/tags/sports.md>), [tech](<https://devfeed.tech/tags/tech.md>), [travel](<https://devfeed.tech/tags/travel.md>)

## AI overview

DreamSetGo's tech team explains how its growing sports-travel catalogue created a need for faster, more intuitive product discovery. The article describes rebuilding the catalogue as a microservice, considering PostgreSQL with Elasticsearch, and choosing PostgreSQL based on architectural and operational trade-offs.

## Source excerpt

By the DreamSetGo Tech Team If you're excited about building high-performance systems that power premium sports travel experiences, explore our open roles at DreamSetGo. Why Search Became a Product Imperative Over the past couple of years, DreamSetGo's catalogue didn't just grow, it accelerated. We were introducing access to new tournaments, adding destinations across continents, and were expanding into different hospitality formats. What began as a few structured products quickly evolved into a layered catalogue of packages and experiences. And that's when we started noticing something subtle but important. Adding products was straightforward. Making them discoverable wasn't. Every new experience meant longer descriptions and richer metadata. On paper, this was definitely progress. But from a user perspective, it introduced friction. If a traveller already knew exactly where to click, they could navigate their way through the catalogue. But if they came in with intent like: "Wimbledon finals hospitality" "Hot air balloons in Cappadocia" "Scuba diving in the Andamans" ...there was no fast, intuitive way to show them the most relevant experience. Once we acknowledged this gap, the next step became clear: we needed a search system that was scalable, resilient, and fast enough to keep up with our growth. This blog takes you through how we designed that search, from architectural trade-offs to production optimisations, and why PostgreSQL turned out to be the best choice for this. The Obvious Architecture (That We Didn't Choose) We started revamping our architecture six months back and rebuilt our travel product catalogue as a dedicated microservice, one that would eventually power search, and filter it by date, price and more. At that point, we had roughly 1,000 products. But we weren't building for 1,000. We had a clear vision of significantly expanding the catalogue within the near future. Like most teams, our first instinct was predictable: PostgreSQL -> Source of Truth