How ElasticRun Adopted TiDB to Seamlessly Scale Peak E-Commerce Workloads

In India’s dynamic e-commerce landscape, ElasticRun plays a pivotal role as the invisible infrastructure behind last-mile deliveries and deep rural distribution. The company’s ability to connect rural grocery stores to modern commerce hinges on technology and more specifically, a backend architecture that can keep up with relentless growth and fluctuating demand.

But as their user base and traffic surged, ElasticRun hit a scaling wall not in the front-end or application tier, but at the database layer. With only six weeks before a high-stakes sales season, the team faced a critical decision: How do you evolve your database infrastructure fast enough to avoid performance bottlenecks without compromising uptime or reliability?

This blog recaps insights shared by Ajit Pendse, Chief Architect at ElasticRun, during his keynote at TiDB User Day India. It explores how ElasticRun scaled past database bottlenecks by migrating from MariaDB to TiDB in just six weeks ahead of a critical sales season, covering their evaluation of alternatives, the migration journey, and the key outcomes and lessons learned.

Fig. 1: Ajit Pendse, Chief Architect at ElasticRun, presenting at TiDB User Day India

The Challenge: Scaling a Platform Built for Speed Not for Infinite Scale

ElasticRun’s architecture was originally optimized for speed of innovation. Like many startups, their early decisions prioritized time-to-market, not horizontal scalability.

Built on a low-code Frappe framework, ElasticRun initially launched with a traditional three-tier architecture: web, application, and database tiers running on just two VMs. The system was effective, but as the platform expanded to support e-commerce logistics, rural FMCG (fast-moving consumer goods) distribution, and even white-labeled SaaS offerings, cracks began to appear.

The web and application layers were proactively moved to Kubernetes. That migration provided flexibility and scalability in those tiers. But the database tier remained monolithic, and increasingly, it became the bottleneck.

The team employed every trick in the book:

• CQRS pattern for separating reads and writes
• Read replicas for analytical vs. real-time workloads
• Database federation for functionally independent microservices

These strategies worked for a while. But as volumes soared, especially write-heavy traffic during peak sales seasons, ElasticRun’s MariaDB-based infrastructure reached its limits.

Exploring Alternatives: Galera, Sharding, NoSQL, and Vitess

With three months until their next peak event, the team began a rapid assessment of alternative architectures. The stakes were clear: their current setup could not handle projected load spikes. And failure during peak season could mean major business disruption.

They explored:

• Galera clusters for MySQL/MariaDB: Horizontal scaling via synchronous replication, but limited flexibility under heavy write pressure.
• Sharding: Viable, but operationally complex. Choosing the right shard key proved challenging given the breadth of their application logic.
• Application-level federation: Functional sharding offered logical separation, but introduced complexity across teams and microservices.
• NoSQL options: These were ruled out due to lack of consistency guarantees and the need for major rewrites as their framework was designed for relational SQL databases.

That led to a more focused look at distributed SQL, specifically Vitess and TiDB.

Vitess vs. TiDB: Choosing the Right Path

ElasticRun’s team initially tested Vitess, already familiar from past experimentation. Performance benchmarks were promising, but the migration overhead was steep. The issues ElasticRun experienced testing Vitess included:

• Required manual definition of sharding keys, which limited flexibility
• SQL queries had to be rewritten to be sharding-aware for performance
• Monitoring and operational tooling were limited compared to expectations
• Overall, it demanded significant effort for incremental gains

With time running out, Vitess didn’t offer the operational simplicity they needed. That’s when the team gave TiDB a serious look.

Within two weeks, they had a TiDB cluster up and running and were impressed.

Why TiDB Won

• MySQL compatibility meant minimal changes to application code
• No manual sharding; automatic horizontal scalability just worked
• TiDB provided first-class monitoring and observability tools
• PingCAP’s documentation and support accelerated adoption

Migration in 6 Weeks: From Decision to Production

ElasticRun completed its migration to TiDB in just six weeks. The early stages focused on compatibility testing and ensuring the Frappe-based application adapted smoothly from MariaDB. To validate performance, the team used traffic mirroring duplicating live reads from production into TiDB, which provided far greater confidence than synthetic benchmarks.

For the 12 TB data migration, they leaned on familiar tools, Kafka and Debezium, and provisioned three TiDB clusters in parallel for redundancy: one for mirroring, one for backup, and one for go-live. This setup minimized risk and kept production safe. After a phased cutover where reads moved first and writes followed, MariaDB was briefly retained as a failover but never needed.

Fig. 2: ElasticRun’s TiDB Supported Architecture 

On the day of the switch, ElasticRun’s TiDB cluster supported:

• 4,000+ QPS on writes
• 50,000+ QPS on reads
• Growing datasets and traffic, without breaking a sweat

“We’ve since doubled those numbers. TiDB continues to scale effortlessly.”
Ajit Pendse, Chief Architect at ElasticRun

Key Takeaways and Lessons Learned

Ajit concluded his keynote with a few strategic insights:

• Choose tools based on your team’s comfort- Debezium and Kafka worked for ElasticRun due to prior familiarity. While TiDB offers excellent native migration tools, the right path depends on your expertise and timelines.
• Over-provision to move fast- ElasticRun deliberately over-provisioned clusters to eliminate performance bottlenecks during migration. TiDB’s support team helped size infrastructure effectively.
• Leverage TiDB’s rich monitoring and documentation- TiDB’s built-in observability tools (like Key Visualizer) helped the team fine-tune performance post-migration.
• Don’t underestimate the value of traffic mirroring- It gave ElasticRun the confidence to switch databases without impacting real users; a powerful pattern for other teams exploring major infrastructure changes.

The Outcome: Ready for What Comes Next

Since moving to TiDB, ElasticRun has continued to grow rapidly without needing another major overhaul of its backend. Their TiDB-powered infrastructure supports high read/write throughput, maintains strong consistency, and scales seamlessly with traffic demands.

And they accomplished it all in just six weeks, during one of the most business-critical windows of the year.

ElasticRun’s journey shows that you don’t need six months to adopt distributed SQL. Just the right plan, the right tools, and the right team.

Whether you’re facing bottlenecks in MariaDB, struggling with horizontal scaling, or preparing for your own peak season, TiDB might be the solution your team needs.

Curious how TiDB can help your team scale without sharding? Let’s talk.

Watch Ajit Pendse’s full talk here