Arek Borucki is a machine-learning platform and database engineer at Hugging Face, helping maintain infrastructure behind more than three million public AI models. His specialty is making enormous model catalogs searchable and dependable without allowing database operations to overwhelm the user experience.
Before Hugging Face, Borucki was a principal SRE database engineer at Beamery, working with cloud infrastructure, NoSQL databases, and Kubernetes. He became a MongoDB Community Champion in 2020, founded the Munich MongoDB User Group in 2022, and began developing and validating MongoDB certifications the following year. His mentorship and community leadership earned him MongoDB’s 2025 William Zola Award for Community Excellence.
He co-authored Mastering MongoDB 7.0 and wrote MongoDB 8.0 in Action, extending that educational work through a public companion repository. His VectorSearch project explores MongoDB Atlas Vector Search with LangChain.
Engineering an open-model ecosystem
Borucki’s account of scaling the Hugging Face Hub illuminates several concrete engineering priorities:
- P99 latency as a product concern: With millions of users, even an apparently small percentage of slow searches affects large numbers of people. Borucki prioritizes the experience of those slowest requests, not merely average performance.
- Independent scaling of metadata, artifacts, and compute: MongoDB Atlas stores repository information, permissions, billing, and model metadata; object storage holds model files; Kubernetes runs application workloads. Each layer can grow according to its particular demands.
- Precomputed tokens and Lucene-backed search: Model names are tokenized when records are written and copied into a read-optimized collection. MongoDB Atlas Search uses Apache Lucene indexes for autocomplete, while trending signals help rank results.
- Workload isolation across MongoDB replicas: Primary nodes handle writes and consistency-sensitive operations; secondaries absorb eligible reads and aggregations; a hidden replica handles reporting and expensive exploratory queries. Sharding remains a prospective scaling step.
- Two-layer Kubernetes autoscaling: Horizontal Pod Autoscaler adds application instances, while Cast AI supplies additional infrastructure when pods cannot be scheduled. Borucki has identified application-metric-driven KEDA autoscaling as a possible future improvement.
