Every small game startup dreams big: building a captivating game, seeing it scale globally, and delivering an “MMO-like experience” without a massive team or budget. But for many, that ambitious vision often hits a very real roadblock: the database.

Meet the founder of OmoLab Games, a seasoned veteran of the game industry. He’d spent years in engine development and engineering management before charting his own course. His mission? To build “my own game studio with a special focus on ‘fun’ research,” crafting “Idle incremental RPGs with infinite progression and social features.” He envisioned players connecting and progressing through challenges – a noble goal that hinged entirely on a robust, scalable backend. For a startup, that’s a monumental task.

The Startup’s Core Dilemma: Scaling Dreams on Lean Resources

OmoLab wasn’t just planning a single hit; the ambition was a reusable, sharable backend system for several games. This made scalability non-negotiable, the absolute biggest requirement.

omolab games

“Mobile game traffic is driven by paid advertisements and app store exposure,” the founder said, detailing the volatile nature of the industry. “Oftentimes not controllable.” The startup needed a system that could comfortably support at least 10,000 Daily Active Users (DAU) per game, with ample room to grow as new titles launched. Crucially, they couldn’t afford to “worry much about this potential increase.”

OmoLab’s games are packed with features like:

Player network: Friends, Player Profiles, GuildsExperience augmentation: Asynchronous PvP, Realtime LeaderboardsDigital wallet: Save data management, Virtual Currency, In-app purchasesLiveOps features: Gift boxes, login bonuses

Each of these demanded a database capable of handling diverse data types and intense, concurrent transactional workloads. The stark reality? As a startup founder, “my resources are very limited, a self-managed solution was time-consuming and costly.” Early tests with other solutions confirmed their fears: “Before TiDB our solution didn’t scale at all and it was going to be a critical part of our platform.” They needed a centralized, shared, and cost-efficient database – essentially, their own “PlayFab” – without the soul-crushing operational burden.

Finding the ‘PlayFab-like’ Backbone

The search for this crucial backend led OmoLab to explore various options, including fly.io Postgres, CockroachDB, and Superbase. The founder needed a unified system that could handle everything from player profiles and virtual currency to real-time leaderboards and chat history backups.

TiDB Cloud Starter quickly stood out. It wasn’t just about features; it was about how it addressed OmoLab’s unique needs:

  • Scalability that just works: The promise of “elastic scalability” was the silver bullet for unpredictable game traffic, providing the elastic capacity to grow without constant manual intervention.
  • A familiar foundation: “I was more familiar with MySQL,” the founder noted. This compatibility meant less time wrestling with new syntax and more time building game logic.
  • Predictable costs, even for a startup: The “generous free allowances” and “predictable cost” model were absolutely critical, allowing OmoLab to scale without “worrying about its bills.”
  • The potential for multi-region replication, a key feature for future global expansion, also caught his eye.

TiDB Cloud Starter became the robust core of what he envisioned as a “shared cloud SaaS-like game LiveOps backend, something similar to Microsoft’s ‘PlayFab’.” It seamlessly managed all critical game data and operations, from player relationships and LiveOps events to in-game economies and customer support tracking.


OmoLab Games architecture powered by TiDB

The Ultimate Test: A Business Saved

Every developer lives in fear of that one critical error – the one that jeopardizes user data and business reputation. For OmoLab, that moment arrived during a user migration.

“There was a time that I wanted to migrate a group of users to another group, but the query had a major issue due to how the client worked,” the founder said. A subtle client-side bug, undetected until deployment, caused a critical data issue.

The immediate problem? “Client updates take time for app stores since a review is required before it is published, so the fastest fix was to revert the change in the servers first,” the founder said. Without a robust recovery mechanism, the situation was dire. “It would have ended horribly, since if any user had made some actions on the server while in this state, some users could have potentially lost their data indefinitely.”

Fortunately, TiDB’s point-in-time recovery (PiTR) was there. The actual restoration was completed within “about two hours from the change, in low traffic time which resulted in  minimal damage which most users didn’t even notice.” This wasn’t just a technical fix; it was a business-saving moment, a stark demonstration of how crucial robust data integrity and continuity are. As the founder noted, “The backup and history retention was one of the features that I didn’t pay much attention to until I had to use it, but it saved my business in one extreme case I had.”

Beyond the Crisis: Daily Wins & Operational Peace of Mind

The impact of TiDB Cloud Starter extends far beyond critical incident recovery, fundamentally transforming OmoLab’s daily operations:

The Budget Breakthrough

Money is always tight for a startup, and every dollar counts. “It has definitely been a cost saver… I would estimate the cost was saved by about half,” the founder said. That’s not just a line item on a spreadsheet – it’s real money that can go toward hiring an artist, polishing gameplay, or marketing a new release. For OmoLab, it meant the difference between scraping by and actually investing in their games.

Reclaiming Time to Build

Perhaps the most profound change was psychological. As any solo founder knows, there are never enough hours in the day. Before TiDB, database management was always lurking in the back of his mind – another task on an endless to-do list. Now? “I don’t usually do any ‘infra’ tasks,” the founder said. “I don’t check for DB uptimes or if an update for the DB or OS is required. The only focus is on the core logic.”

It sounds simple, but this shift was revolutionary. Instead of splitting his attention between keeping servers running and building great games, he could pour all his energy into what mattered: creating fun experiences for players. “This allows me to focus on the real problem instead of having to worry if my service is really up and doing ok.”

The Tools That Became Daily Habits

Some features surprised him with how useful they became. Take the SQL Editor – initially, he didn’t expect to use it much. But it quickly became his go-to tool for everything from debugging tricky issues to understanding customer support cases. “Being able to come up with queries for a certain case is a good way to understand the root cause of the issue,” he said. What used to require exporting data and running complex analysis could now be done with a quick query.

The TiDB Dashboard became another daily companion, especially the slow query logs. When players complained about leaderboard loading times, he could quickly identify the bottleneck and work with the TiDB team to add “use index” hints that dramatically improved performance. These weren’t just technical wins – they were direct improvements to the player experience.

An Unexpected Partnership

Perhaps most surprising was the relationship that developed with the TiDB support team. “I did not expect to be in close contact with the support team,” he said. “I always thought services like these took time to respond to inquiries from basic grade customers.”

Instead, he found a responsive, knowledgeable team that felt more like colleagues than vendors. “The TiDB support team has been really active and helpful whenever I need to know something or I am having an issue.” This wasn’t just good customer service – it was having a “virtual DBA team” in his corner, giving him the confidence to think bigger.

“The support team has been amazing overall which makes me think about going full on server-controlled architecture in the future,” he said. For a solo developer, that kind of backing makes ambitious technical decisions feel achievable rather than overwhelming.

The Road Ahead: Building Bigger Dreams

OmoLab Games is just at the beginning of its journey. With TiDB Cloud Starter as its rock-solid foundation, the startup is poised for significant growth:

Global Expansion

Plans to “expand to other territories and gather users there as well.”
Data-Driven Analytics

Ambitions to build a “stronger analysis system which is essential for growth,” leveraging TiDB’s HTAP capabilities.
Data Granularity

A desire to “increase the granularity of our data to allow DB writes more often than now.”

The founder’s feedback remains honest and forward-looking. While acknowledging ongoing efforts to enhance service stability, they eagerly anticipate multi-region support for TiDB Cloud Starter, seeing it as a key enabler for further optimizing global game operations.

For OmoLab Games, TiDB Cloud Starter isn’t just another database; it’s the invisible co-pilot powering a small startup to chase its dreams, build engaging games, and scale without the usual pains. It’s the resilient foundation for their very own “PlayFab,” proving that even with lean resources, truly scalable and robust game operations are not just possible, but within effortless reach.

omolab-logo

Spin up a database with 25GiB free resources.

Start Right Away