Beyond the Scaling Wall: Key Insights from Our Distributed SQL Meetup with TiDB and AWS


On a bright Saturday morning in Bengaluru, a room full of data architects and engineers sat listening, nodding knowingly. They weren’t just attending a workshop; they were seeing their own daily struggles reflected on the presentation screen. The problem wasn't a niche technical issue; it was the monster in the closet of every successful, growing company: a database architecture groaning under the weight of its own success.
This was the scene at the TiDB - Mydbops - AWS Distributed SQL Meetup, an event we at Mydbops were proud to co-host. It was a day for honest conversations, not just sales pitches. A day to dissect the problem before celebrating the solution. If you missed it, this isn't just a summary—it's the story of a shared journey from frustration to a future where data just works.

The Diagnosis: "A Self-Created Complexity"
The day began with a simple but powerful story from Bhanu Jamwal, Head of India Business at TiDB.
"I just swiped my credit card," he began, "and I got an intimation from my bank, HSBC. There was a transaction which happened in the US, where I never visited. They said, 'Did you do this transaction?' and I said no. They said, 'We have blocked your card.'"
This, he explained, is a perfect example of real-time analytics. But how do you build a system that can do this without crumbling? This question led to the core diagnosis of the day.
"Imagine you start a new business today," Bhanu continued, painting a picture familiar to everyone in the room. "You pick a MySQL database. Your business outgrows it. The first step you will do is you will scale up your system—add more cores, more memory. But at some point, there will be a hard limitation to how much you can scale up."
What happens next is the critical moment where things get messy.
"The next alternative you have is you start creating multiple MySQL databases and manually sharding your data," he said. "This creates so much complexity. Everything now becomes manual. The application which is supposed to focus on my business, unfortunately, is also now managing my infrastructure."
He then showed a slide that elicited gasps and knowing chuckles: a real-life architecture diagram from a customer. It started with one database. Then came a hot standby for backup. Then a read replica for reports. As data grew, they had to add another shard, which also needed its own master, standby, and replicas. Add a disaster recovery site, and suddenly…
"One single application eventually needed 25 databases to run at the back end," Bhanu concluded. "That was the complexity which was created, not because they wanted to, but because there were not many options available." He called it a "Frankenstack"—a monster built from necessity, and a monster that devours time, money, and developer sanity.

The Prescription: A Database That Thinks Differently
If the Frankenstack is the problem, what's the cure? This is where the concept of Distributed SQL entered the conversation. Instead of a single, monolithic server, TiDB is built from the ground up to be a team of coordinated nodes.
Bhanu explained it simply:
- The TiDB layer is the "face" of the database. It speaks MySQL, so your existing applications can connect with little to no code changes.
- The TiKV layer is the storage engine. This is where the real magic happens. Need more storage or power? You don't buy a bigger box; you just add more TiKV nodes. The system automatically spreads the data and workload across them.
This architecture enables what was previously thought impossible: massive scale and real-time insights on the same platform. "We have customers like Pinterest who have gone beyond 1 petabyte of data on one single TiDB cluster," Bhanu noted. "Flipkart runs at 1 million queries-per-second with latency as low as 5 milliseconds for their SuperCoins wallet, which is hosted on TiDB."
No more choosing between a database that's good for transactions (like MySQL) and one that's good for analytics (like a data warehouse). A distributed system can do both.
From Theory to Reality: The Mydbops Perspective
An elegant architecture is one thing; making it work in the real, messy world of production is another. This is where our Founding Partner, Kabilesh P R, stepped in, grounding the conversation in the practical experience that defines Mydbops.
"Scalability has a different meaning for each customer," Kabilesh began. "If you ask an e-commerce website, they'll say 'we need to handle more concurrent users.' If you ask a bank, it's about making transactions as smooth as possible."
He then turned the spotlight back on the specific pains of traditional databases, speaking directly to the DBAs in the room. "How many of you have done a DDL with respect to your MySQL instance having a size of more than 500GB?" he asked. The knowing looks in the audience said it all. "You might know the pain. It takes minutes or hours. There's a potential to bring down your system altogether by locking all the connections."
He also addressed the constant headache of replication lag, where your read replicas are always slightly behind, making true real-time reads impossible.
During the Q&A, a fantastic question came from the audience: "Is there a use case where an organization has moved from a modern database, not just legacy MySQL?"
Kabilesh had a direct, hands-on answer. "You have heard about Kissflow," he said. "They have a SaaS platform and were using Mongo DB Atlas. They felt a bottleneck with respect to cost. The first thing is cost. Atlas comes with a huge cost. And after paying this huge bulk of cost, the performance they could not get. So they did a proof-of-concept and have moved their workloads completely from Atlas to TiDB."
This is the core of what we do at Mydbops: we guide companies through these complex evaluations and migrations, ensuring the technology solves a real business problem, whether that’s performance, complexity, or cost.


The Leap Forward: When You Can Just Talk to Your Data
Just as the audience was processing the shift to distributed systems, Shubham Londhe, Developer Advocate at AWS, took the stage to pull the future into the present.
"How many of you remember doing this?" he asked, "Going to browsers, writing www.google.com? Then came a time when we started exploring mobile applications. All that website surfing went down, and we started working with APIs. We all are in this era. But something exceptionally beautiful is happening."
That beautiful thing is what he calls the "Agentic Web," where you don't use an interface to get to your data; you simply have a conversation with an intelligent system that does the work for you.
"How many S3 buckets do I have in my account?" Shubham asked his screen. "Will I go to my browser? Will I go to my mobile phone? Or will I talk to an agent?" He typed the question into Amazon Q, and a moment later, the answer appeared: "You have 103 S3 buckets in your AWS account."
The most stunning part? He revealed that a production-ready system like this can now be built not in months, but in three weeks. Then, in a live demo that captivated the room, he showed how to build the core of it in minutes.
Using the Strands Agents toolkit, he wrote just a handful of lines of code.
from strands import agent
my_agent = agent.Agent()
He connected it to a TiDB cluster, and then simply started asking it questions in plain English: "Can you name the cluster?"
The agent responded, using a tool to list the databases. The audience watched as a simple English prompt was translated into a database query and returned a result, live on screen. It wasn't science fiction; it was five lines of code and a well-designed database.

A New Path
We started the day talking about a 25-database Frankenstack and ended it by having a conversation with a database. The journey between those two points is the story of modern data infrastructure. It's a path away from complexity and towards simplicity, away from limitations and towards limitless scale.
The day was a powerful reminder that the biggest challenges in technology are often solved not by working harder, but by finding a smarter way to work.
A heartfelt thank you to everyone who attended and brought their energy and insights, and to our incredible partners at TiDB and AWS.

Every scaling challenge, every late-night database migration, every “why is this slow now?” moment becomes easier when there’s a community that understands. Events like the TiDB–Mydbops–AWS Distributed SQL Meetup aren’t just about introducing new tools—they’re about connecting the people who will shape how those tools evolve.
This is how the next generation of data architecture will be built—not in isolation, but together. Because the future of databases isn’t just distributed systems… it’s distributed knowledge.
So here’s to every DBA, architect, and engineer who shows up, asks the hard questions, and shares their hard-won answers. You’re the reason we move forward faster, together.
If your team is facing its own scaling wall or you're ready to move beyond your own "Frankenstack," the path forward is clearer than ever. Let's have a conversation about it. Contact the experts at Mydbops today.