Gaming Company SUPERCAT Scales Beyond Amazon Aurora and Saves 40% in Database Costs by Leveling Up with MariaDB Xpand
SUPERCAT is a game development company and the creators behind The Kingdom of Winds: Yeon, Granny’s House, Grow Stone and Punkland. We recently spoke with Byungkee Hong, who is responsible for the gaming company’s infrastructure and database, to learn why they chose MariaDB Xpand.
Xpand is a distributed SQL database for large, mission-critical read/write scale applications which require ACID-level consistency and high availability. It supports extremely high throughput, multi-zone reliability, elasticity and capacity increase through extreme parallelism and global replication. While it is a transactional database, it supports real-time analytics through columnar indexes as their distributed SQL database.
Can you share a little bit about yourself and what project you’re currently working on?
I’m responsible for managing SUPERCAT’s infrastructure and database. We’ve been working on a project called ZEP, our open metaverse platform that enables fun and meaningful meetings and gatherings. Within eight months of launching ZEP, we’ve surpassed three million users.
How did you learn about MariaDB?
The scalability limits in our existing relational database caused too many issues and it was time to find a better database. I happened to attend a MariaDB conference where I learned about Xpand.
Can you tell me why you choose Xpand for ZEP?
Gaming is one of the most demanding industries that requires high performance and elasticity. The traffic volume of ZEP was completely unpredictable and Xpand was the best fit. Xpand has the ability to handle unexpected increases in workloads and delivers massive scalability while maintaining high availability.
What has been the biggest benefit of using Xpand?
An Xpand production workload can run on as few as three nodes, or up to a hundred nodes and thousands of core. It operates as a single logical database capable of handling high workloads – increasing and decreasing capacity is simple and Xpand will redistribute the workload and data automatically. Nodes can be added or removed at any time based on my workload. With gaming, there can be a sudden surge in traffic and it makes a huge difference if you can make that adjustment. As a result, I’m able to save money. We were very impressed by Xpand.
Which other databases did you look at?
We did a lot of comparisons with AWS Aurora database and we found Xpand’s price was 40% lower. That was a big factor since we wanted to avoid cloud provider lock-in. We were also interested in AWS Aurora but it has limited write scalability. With Xpand, we get both read and write scalability.
We also looked at Google Spanner but you’re locked in with Google once you’re using it. The cloud service lock-in was a disadvantage. We had barely heard of CockroachDB, and we didn’t know another engineer that was using them.
Do you have a recommendation for people who are starting to think about how to evaluate and adopt Xpand?
We tested Xpand for six months. First, we selected a specific instance type to test in the cloud to figure out what the right number of cores were needed for optimal performance. We also had to ensure the compatibility of queries that we were using for our relational database and run migration tests. We simulated a lot of system failures, too. There are different types of failures; for example, one forced one or two servers to turn off at the same time, and the other pulled the network cable.
I tested Xpand in different cloud services, including virtualization. I found the internal network is so important. I recommend choosing a cloud or a data center with a stable internal network, and trying it with different scenarios.
