A regional portal grows from 800 to 12,000 listings in eighteen months. SEO improves, traffic too — modest in global volume, but each visitor runs a search. A filter "3 rooms, balcony, < €350k, 5 km radius" triggers a heavy query, ten lazy-loaded photos, a map tile, sometimes an email alert. Shared hosting still serves HTML. MySQL goes from 200 ms to 8 seconds on popular searches.
A property portal is not a real estate blog. The constraint is not "handle 10,000 page views/day" — it is handle 10,000 filter combinations on a live catalog, with heavy media and SEO indexing every listing page.
Three pillars: indexing, media, search
| Pillar | Symptom if undersized | Lever |
|---|---|---|
| DB indexing | Searches > 2 s, MySQL CPU at 100% | Composite indexes, EXPLAIN, read replica |
| Photos | Full disk, high TTFB | Object + CDN, thumbnails, compression |
| Search | Timeouts on map / filters | Elasticsearch, Meilisearch, PostGIS |
On a property portal, the listing page is an analytical query disguised as a web page. Treat it that way.
Indexing: the query that kills before traffic does
Classic mistakes recur: missing index on (city, type, price, area) while the UI filters exactly on those fields; ORDER BY date DESC without covering index causing filesort on 50,000 rows; agency → listing → photo joins with no cap on images loaded.
Before production, EXPLAIN the ten most frequent queries (analytics dashboard or slow query log). Create a composite index aligned with UI filter order. Enforce pagination (24–48 listings max per page). Cache "top" searches in Redis (downtown two-bedroom, etc.) with short TTL.
For more detail, see Missing MySQL index: spot the query that brings down the site.
Photos: the invisible weight of the catalog
A "standard" listing: 12 photos × 1.5 MB = 18 MB stored. Multiply by 12,000 listings — the disk math explains emergency migrations.
Healthy architecture: upload to object storage (Scaleway, OVH, Infomaniak Object Storage), async processing producing 800 px WebP thumbnails, CDN with long cache on media and short on listing HTML (price changes), immediate purge when a listing is removed.
Never serve the 4000×3000 original in list views. Google Page Experience and your disk will thank you.
Faceted and geo search: when MySQL alone is enough
| Listing volume | Search | Recommendation |
|---|---|---|
| < 2,000 | Text + city | Well-indexed MySQL/PostgreSQL |
| 2,000 – 20,000 | Multi-filter + map | PostGIS or Meilisearch |
| > 20,000 | Facets + aggregations | Dedicated Elasticsearch / OpenSearch |
Interactive maps multiply queries: each zoom = new bbox. Cache tiles and clusters server-side or precompute by zone.
Hosting: beyond "WordPress + cache"
Agency vitrine front can stay on shared hosting. Custom listing engine, Elasticsearch, 500 GB photos, and bulk CSV imports need VPS or cloud with object storage, queued workers, and read replica if search dominates.
Nightly CRM imports can saturate I/O while users search in the morning. Isolate imports in a Celery queue or dedicated worker server.
The peak: SEO brings traffic your database did not plan to serve
Marketing wants "more indexed listings." Ops must answer "each search template has a performance plan" — otherwise you gain traffic and lose conversion.
Decide and move forward without blind spots
First list the ten slowest searches via slow query log. Externalize media before hitting 100 GB or 80% disk. Test bulk import combined with concurrent search traffic on staging. Enable CDN and compression on all list thumbnails. Set a tipping point: if search 95th-percentile latency exceeds 1.5 s, move to dedicated engine or read replica.
Compare hosts with object storage via our directory and compare tool. For read replication, see Database replication: availability or faster reads?.
Frequently asked questions
Why does a property portal saturate shared hosting so fast?
Each multi-criteria search can scan thousands of rows without proper indexes; each listing loads 10–20 photos. CPU, RAM, and disk I/O rise together — not just page views.
Do you need Elasticsearch for a property portal?
From a few thousand active listings with faceted search, a dedicated engine or PostgreSQL + PostGIS beats unindexed LIKE queries on MySQL.
Where should listing photos be hosted?
Object storage + CDN; WebP/AVIF thumbnails on import, never the original in list views.
How do you size geographic search?
Spatial indexes, cache for frequent queries, strict pagination — no full scan for a map.
A property portal is won or lost in SQL indexes and photo folders — not in the core count on the host spec sheet.