How Search Works on niranar.com: Location, Dates, and Filters

A family of four is looking for a villa with a private pool in Antalya. Their dates are set: July 12–19. To make that search meaningful, the system has to answer five distinct questions simultaneously: Is this the right location? Is it available for those dates? Can this villa sleep four people? Does it have a pool? Does it fit the budget? Getting any one of these wrong produces irrelevant results. Getting all five right is what a working vacation rental search actually means.

niranar.com is a vacation rental marketplace for Mediterranean Turkey with over 300,000 active listings. This article focuses on how the platform's search coordinates five separate concerns into a coherent experience — and the deliberate engineering choices behind the system, including why PostgreSQL handles the search layer rather than a dedicated search engine. For a broader introduction to the platform itself, see the niranar.com Product Overview.

Search Is Five Problems, Not One

It's tempting to think of vacation rental search as a simple query-and-result operation. Type a destination, get a list. But "a villa with a pool in Antalya" is not a text-matching problem — it's the simultaneous coordination of location resolution, availability filtering, capacity matching, attribute filtering, and price segmentation.

Each of these operates by different rules. Location is geography, not text: when a user types "Bodrum," the system needs to resolve that to a geographic scope covering the peninsula and its dozens of distinct neighborhoods. Date range is dynamic data: it must be compared against per-property availability records, not a static database field. Guest count is a capacity constraint: it determines which properties are structurally eligible to host the group.

Running these five operations independently is possible. Running them in the right sequence, at speed, and with accurate results against 300,000+ listings is what defines the quality of the search experience. A platform that returns available results for wrong dates, or shows three-bedroom villas to a couple looking for a studio, has failed at the coordination layer even if each individual component technically works.

For travelers unfamiliar with the Turkish market: Mediterranean Turkey — the coastline running through Antalya, Bodrum, Fethiye, Alanya, and neighboring regions — is one of Europe's most visited summer destinations. It draws millions of international visitors annually, primarily from EU countries. The search infrastructure that niranar.com has built serves this high-volume, high-expectation traveler base.

Location and Dates: The Foundation Inputs

Every search on niranar.com starts with three required inputs: location, date range, and guest count. These three inputs together define the meaningful search universe. Without all three, the result set is either too broad or too incomplete to be useful.

Location Resolution

niranar.com covers Turkey's primary coastal vacation destinations: Antalya, Bodrum, Fethiye, Alanya, Kuşadası, and Sapanca. Each of these destinations is a substantial geographic area containing thousands of properties across distinct micro-regions. When a user types "Antalya," the system resolves that input to the full geographic scope of the region — including sub-areas like Lara, Belek, and Kemer.

This matters more in Turkish vacation rental than in some other markets. Destinations like Bodrum span an entire peninsula, where the character of different neighborhoods varies considerably. A traveler specifically seeking the quieter atmosphere of Yalikavak is looking for something fundamentally different from someone who wants Gümbet's proximity to nightlife. The location input is the first filter, but it also feeds directly into the map layer — giving users spatial browsing as an alternative or supplement to form-based search.

Date Range and the Availability Calendar

Check-in and check-out date selection drives availability filtering. niranar.com uses a custom-built calendar implementation — not a third-party calendar service — to track per-property availability. Each property's occupied and available dates are maintained as a separate record, which the system queries against the user's selected date range.

Building availability tracking in-house rather than relying on an external service has operational significance. Third-party calendar integrations bring their own API constraints, data format requirements, and service dependency risks. A custom implementation means the availability data model lives entirely within the platform's control, can be optimized for the platform's specific query patterns, and isn't subject to third-party service outages or API changes.

The practical result for the user is direct: properties that are booked during the selected dates simply don't appear in results. The availability filter runs before anything else, ensuring that the results list contains only genuinely bookable options for the requested window.

Availability and Capacity: Invisible Filtering

After location and dates are entered, two additional constraints run automatically: availability and capacity. These don't require separate user input — they're built into the search logic as defaults.

The guest count input activates capacity matching. A group of four searching for accommodation will only see properties that can sleep four or more guests. A studio that sleeps two won't appear. A six-bedroom villa that sleeps twelve will appear, but so will a three-bedroom villa that sleeps six. The system matches capacity to the stated group size from the start.

The value of this filtering is measured by what users don't see: properties with insufficient capacity are excluded before the results page ever loads. For a market like vacation rental in Turkey, where villa sizes can range from two-bedroom cottages to twelve-bedroom estates, capacity filtering prevents the results list from becoming an unstructured catalog that users have to manually sort through.

This is a standard expectation in mature vacation rental search — Airbnb and Booking.com both do it — but it requires the underlying data to be reliable. Capacity filtering only works as well as the per-property capacity data it queries against. At 300,000+ listings, maintaining accurate capacity records across the full catalog is a data quality challenge that runs beneath the surface of the search experience.

Attribute Filters: Pool, Beachfront, Property Type, Price

Location, dates, and capacity form the required parameters. Attribute filters are the optional constraints that let users express their actual preferences within the eligible result set.

Property Type

Users can filter between villas (Villalar) and apartments (Daireler). This distinction matters because the experiences are fundamentally different. A villa is typically a standalone property with a private garden, often a pool, and multiple bedrooms — the dominant format for group travel in Turkish vacation rental. An apartment is a vacation-use flat in a residential complex or city center, suited to couples or small groups who want a more accessible price point and urban proximity.

Filtering by property type early in the result set removes a large category of irrelevant listings before users invest time reviewing individual properties. It also reflects how travelers actually think about their search: someone who has decided they want a villa isn't browsing apartments, and vice versa.

Pool (Havuzlu)

The pool filter surfaces only properties with pool access — private or shared. In Turkish vacation rental during summer months, pool access is a primary decision criterion for many renters, particularly families and groups. The Mediterranean climate makes outdoor swimming a core part of the vacation experience for the majority of peak-season travelers.

This filter's accuracy depends entirely on per-property data quality. If pool information is inconsistently recorded across the catalog, the filter becomes unreliable, which undermines user trust in the entire search experience. At platform scale, maintaining accurate amenity data is a continuous data management problem.

Beachfront (Denize Yakın)

The beachfront filter highlights properties with direct beach access or near-beach proximity. Coastal location quality — how close a property is to the water — is the second major decision criterion alongside pool access for many vacation travelers. In destinations like Fethiye and Kuşadası, where some properties sit directly on the coast while others are a twenty-minute drive inland, proximity to the sea determines a significant portion of the vacation experience.

This filter works in natural combination with the map view: a user can apply the beachfront filter and then switch to the map to see which properties cluster along the coastline versus which are located further inland.

Price Tier

All listings on niranar.com are priced in EUR. The price tier filter provides a band from budget (approximately €50/night and under) to premium. EUR-denominated price tiers are immediately useful for the platform's primary international audience.

Turkey's vacation rental market draws heavily from EU countries — Germany, the Netherlands, Scandinavia, and others — whose travelers are accustomed to evaluating vacation costs in EUR. Pricing in EUR removes the friction of currency conversion and makes niranar.com's listings directly comparable to similar properties in Spain, Greece, or Croatia. A traveler can set a budget boundary in a currency they understand intuitively, without mental arithmetic about exchange rates.

Map Integration: The Spatial Dimension

niranar.com offers a map-based browsing interface powered by Leaflet, an open-source JavaScript mapping library. This is the alternative navigation path alongside form-based search.

The choice of Leaflet over Google Maps is deliberate cost engineering. Google Maps API charges per request — map loads, place searches, and geocoding queries all accumulate costs. For a pre-revenue beta product, these per-request fees create a financial exposure that scales with usage but doesn't yet scale with revenue. Leaflet is open-source, runs against self-hosted or free tile sources, and generates no per-request API costs. Using Leaflet makes it possible to offer full map functionality without adding a variable cost line to the operating budget.

From a user perspective, the map view solves a problem that the list view cannot: it answers "where, exactly?" in a way that an address or neighborhood name alone cannot.

Consider Bodrum. The Bodrum peninsula is a collection of distinct coves and neighborhoods, each with a different character: Yalikavak has a quieter, upscale feel; Gümbet is livelier with a younger tourist crowd; Türkbükü is known as a celebrity-frequented bay with a premium atmosphere; Bitez has a relaxed watersport culture. A property listing that says "Bodrum" tells an international traveler almost nothing about which of these experiences they're choosing. The map makes those distinctions visible instantly — users can orient themselves geographically and select properties based on their preferred area within a destination.

Map and list views are complementary, not competing. A traveler can begin with a form-based search and switch to the map to verify locations after getting a result set. Or they can start by browsing the map to select a preferred area, then let the form parameters narrow availability and capacity. Both paths draw from the same 300,000+ listing pool with the same filter set applied.

PostgreSQL as the Search Engine

niranar.com's search backend runs on Supabase PostgreSQL queries. There is no dedicated search engine — no Elasticsearch, no Algolia, no Solr.

This is a deliberate architectural choice, not a constraint. Dedicated search engines are the right answer for certain problems: high-volume full-text search with fuzzy matching, synonym handling, relevance ranking across unstructured text. But vacation rental search is primarily structured query work: "properties in region X, available on dates Y to Z, with capacity for N guests, having attribute A, within price band P." That's a join-and-filter problem, not a full-text relevance ranking problem. PostgreSQL handles it well.

Adding Elasticsearch or a similar service means adding another system to deploy, configure, index, monitor, and keep in sync with the primary database. For a solo developer building a pre-revenue product, each additional service is an operational burden that doesn't contribute proportionally to the user experience at beta scale. The simplest architecture that solves the actual problem is usually the right architecture — and the actual problem here is structured query filtering, not free-text relevance scoring.

Supabase makes this approach especially practical. Supabase provides the database, API layer, and serverless functions as a single integrated service. The solo developer building niranar.com works with one system instead of coordinating between a relational database, a separate search index, and an API gateway. Reducing service count reduces the surface area of what can go wrong and what needs to be maintained.

At 300,000+ listings, PostgreSQL-based search provides sufficient performance for the search patterns that vacation rental queries actually produce. The architecture can evolve as scale and search complexity grow — but the right time to add that complexity is when the product has validated the user need at scale, not during beta.

Structured Data: Search Engine Visibility

niranar.com implements two schema.org structured data schemas in the page head: WebSite and SearchAction.

The SearchAction schema makes the site eligible for Google's sitelinks search box — a feature that can display a search input directly in Google search results when users search for the site by name. Instead of clicking through to the homepage and then using the search form, a traveler could enter a destination query directly from the Google results page.

For a vacation rental platform where the primary acquisition channel is organic search, this has clear value. Travelers searching for vacation rentals in specific Turkish destinations are likely to find niranar.com through search. The SearchAction schema shortens the path from discovery to first search action.

The WebSite schema signals the site's identity and structure to search engines, supporting broader indexability and the association between the domain and its content scope.

What this implementation reveals about engineering priorities: SEO infrastructure was built into the product during development, not added afterward. Structured data is most valuable when it's present from launch — search engines need time to discover, validate, and act on it. Treating it as a launch-day decision rather than a post-launch task reflects a product approach that sees organic search visibility as an architectural requirement, not a marketing add-on.

What This Demonstrates

niranar.com's search architecture is evidence of a specific capability: building multi-parameter search that coordinates location, availability, capacity, and attribute filtering in a way that produces a coherent, reliable user experience at scale.

Each engineering decision reflects a deliberate trade-off. PostgreSQL over Elasticsearch is a simplicity bet — the search problem doesn't require full-text relevance machinery, and avoiding an additional service reduces operational overhead. Leaflet over Google Maps is a cost structure bet — map functionality at pre-revenue scale shouldn't carry per-request API cost. A custom calendar implementation is a control bet — availability data is too core to the platform's value to depend on a third-party service's reliability and interface contract.

For a potential client considering a similar project — a marketplace with multi-parameter search, geographic browsing, and availability filtering — niranar.com is a live demonstration of how these problems get solved in practice. The system works, it handles 300,000+ listings, and the architectural choices behind it are explainable, not arbitrary.

Conclusion

niranar.com's search coordinates five concerns: location resolution establishes the geographic scope; the custom availability calendar filters by date; capacity matching eliminates undersized properties; attribute filters — pool, beachfront, property type, price tier — let users refine by preference; and the Leaflet map layer adds a spatial dimension that makes location legible in a way a list cannot. PostgreSQL handles the full query stack without the overhead of a dedicated search engine. Structured data connects the search experience to Google's indexing infrastructure from launch.

For the architectural context behind these decisions, see niranar.com's Technical Architecture. The search implementation described here sits on top of an infrastructure stack — Supabase, Next.js, AWS Amplify — that the architecture article covers in detail.