Final audience question. Maciej: silver bullets only — kidding; depends on data size. Often Postgres or SQLite with proper indexes is enough; load-test locally, on staging, and production; if you outgrow that, secondary indexes like Elasticsearch are his choice, but joining Elasticsearch and Postgres in-app can become the new bottleneck. Stephen: 'big data' is usually smaller than you think — 30GB is tiny, hundreds of GB is small. Users don't actually use 20 filters randomly; monitor production, find the Pareto-hot filter clusters, and index 3–6 combinations covering 80% of queries. Minimize joins if you can. Caio: well-designed databases with proper indexes handle most cases without Elasticsearch; also control the UX — one product limited the combinable-filter count after metrics showed no one used many at once, and rate-limiting internal APIs is often overlooked but saves headaches. Maciej pushes back on minimizing joins: Postgres handles 20+ joins fine, don't be afraid.