YugabyteDB Community Spotlight – February 2022
In this ongoing series, we highlight community members who are solving interesting problems with YugabyteDB, the first—and only—100% open-source, hybrid, multi-cloud, distributed SQL database on the planet.
James Hartig, Co-Founder, Admiral
Admiral is a leading Visitor Relationship Management (VRM) platform, serving thousands of publishers worldwide. The company empowers publishers to engage their audiences to drive and optimize revenue streams from paywalls to adblock recovery.
Admiral chose YugabyteDB for its comprehensive geo-distribution capabilities and to drive single-digit low latency, massive scalability, and high performance—all while future-proofing their system for exponential growth.
In this post, we shine a spotlight on Admiral’s Co-Founder, James Hartig. Read on to learn more about James’ passion for databases and the first time he heard about YugabyteDB. He also discusses his experience using YugabyteDB Managed (formerly Yugabyte Cloud) to serve 10,000 queries per second across three continents.
How long have you been coding? What got you started? What languages and databases have you focused on?
James Hartig: Computers have always fascinated me. After making a few personal sites and tiny games at home, I started seriously programming in high school. I originally started out contracting for others until I found a few annoying bugs in a music streaming website, Grooveshark. After emailing with support for several weeks, I decided to fix them using the browser’s console to manipulate the code. The support team at Grooveshark was surprised to receive a patch and forwarded me to the CTO of the company, Josh Greenberg. He offered me a contracting position which, upon graduation, turned into a full-time position in Gainesville, Florida.
At Grooveshark, I learned a few different databases, such as MySQL, MongoDB, and Memcached. We used PHP and JS primarily, but I also got some exposure to Java and Go. We had millions of users but a small budget to operate within. This meant we had to scrutinize every feature and database interaction to ensure it was going to be efficient at scale. The team was awesome and we had lots of passionate fans constantly pushing us to make online music streaming better.
After Grooveshark ended, several of us founded Admiral to help online publishers build relationships with their visitors. We had firsthand experience with ad blocking and decided to start focusing our efforts there first. Our product—and team—has grown significantly since then. We’re now working with many top publishers around the world. Our scale presents a lot of challenging problems and our team is flexible enough to ensure we’re using the right software for the job. Our backend is primarily written in Golang and we use several different databases depending on the workload.
JH: At Admiral, we use MongoDB for simple CRUD services and YugabyteDB for our high-traffic datasets. We most recently switched to BigQuery from BigTable for big data. However, I’ve previously used many other databases including MySQL, Cassandra, CockroachDB, Redis and Clickhouse. It is unrealistic, at our stage, to throw money at a problem, so our biggest pain point is operating a database at tens of thousands of queries per second while keeping costs and maintenance manageable.
Admiral had been using MongoDB for a few years before we grew enough to require sharding one of our clusters as an attempt at horizontally scaling. Unfortunately, we ran into several show-stopping bugs with shard ranges and performance issues with small traffic spikes. For our even larger datasets we first started with our own Cassandra cluster. But the ongoing compaction and scaling work was too much for our team. We’ve since transitioned several workloads over to YugabyteDB, which allows us to scale effortlessly as well as squeeze even more performance per dollar.
JH: In 2019, Admiral was building a new zero-party data platform for our customers to facilitate storing data their visitors gave them. With third-party cookies being phased out, Admiral’s platform allowed publishers to still personalize their content while also giving visitors control over their data. Our service needed to be highly available and respond in milliseconds to visitors from anywhere around the world as publishers use this data to customize their experience for each visitor.
After trying out other distributed SQL databases, we weren’t happy with the results. But luckily, I ran into the Yugabyte team at a Google Next event. YugabyteDB seemed like the perfect solution for what we needed—provided it held up at scale—via their YCQL interface. And even though we didn’t originally have plans to use the YSQL interface, it was an added bonus for future workloads we might add or migrate.
JH: I just completed migrating our largest service, which handles visitor events and sessions, to YugabyteDB Managed. This service does almost 10k queries per second at peak across 3 continents via YCQL. Unlike our other workloads, each region is a separate cluster for performance, and YugabyteDB Managed made this simple to orchestrate and maintain.
Admiral is still running a self-hosted cluster for our zero-party data platform and will be moving it to cloud over the coming months. After the success we’ve had thus far with YugabyteDB, later this year we will begin migrating our smaller CRUD services to cloud from MongoDB so we can utilize YSQL’s relational features as well as simplify our team’s platforms.
JH: Read replicas have been an important feature for Admiral in YCQL as our platform exists across many regions. So I’ve been eager for follower reads to come to YSQL. Now that YugabyteDB 2.8 added support, I will be able to begin testing and migrating the next set of Admiral services. Additionally, Admiral mirrors our application data to BigQuery to facilitate larger, complex queries across multiple datasets. I’m also looking forward to the upcoming improvements to change data capture (CDC) so we can begin replicating our data stored in YugabyteDB.
JH: YugabyteDB blew away my expectations, serving reads in under 5 milliseconds (90th percentile) for our new data platform. Admiral is able to host the dataset across 3 continents and using YCQL’s read replicas we can still service reads without crossing an ocean. Our initial cluster was self-hosted back in 2019, and it’s been a breeze scaling, backing up, and updating the cluster as we’ve grown over the last few years. I don’t have time to spend managing a database cluster. And YugabyteDB doesn’t require me to since it shuffles data and leadership automatically.
Every database has its bugs or quirks. But the Yugabyte team has been quick to address—and fix—issues our team has encountered. They’ve also helped us tremendously with planning migrations and schema design. I’ve brought up several feature requests with the team. And not only have they been receptive to the ideas and feedback, but many of them have already been released.