How we pulled off a massive database migration without anyone noticing

Databases are foundational to most software companies—and Rownd is no exception. One of the most critical parts of our job is ensuring that our customers’ user data is safe, secure, easily retrievable, and performantly accessible at all times. We take this responsibility seriously and spend a lot of time making sure the core of our platform is stable, scalable, and thoroughly tested.

Choosing the right database is one of the most important decisions a product team will make. When we built Rownd, we evaluated a number of options but kept coming back to FaunaDB for its strong data isolation properties, global scale, ACID compliance, and GraphQL API. So, we built the first version of Rownd on Fauna.

That was a huge mistake.

It’s easy to get distracted by the shiny new thing—and that was totally us. Fauna seemed like the up-and-coming cool-kid-on-the-block with big advantages over traditional RDBMSs. Instead of SQL, it used a functional query language called FQL. It had some relational-like features and even allowed you to embed logic directly into the database engine. Honestly, there was a lot to like, and the Fauna team had some genuinely exciting ideas about how a modern database could work.

But two major issues quickly became apparent.

First, Fauna lacked traditional indexing capabilities. You couldn’t query data without creating an index—fine in theory—but the indexes didn’t support fuzzy or inexact matching. SQL’s LIKE operand? Not a thing. The only workaround was building n-gram indexes, which didn’t suit our use case and would have added a mountain of engineering complexity.

Second, Fauna was entirely proprietary and hosted. Aside from a limited local container for basic testing, there was no way to self-host it. No data portability. No escape hatch. This should be a massive red flag to any startup founder: your primary database should be portable and ideally built on open-source technologies. Even if you don’t plan to self-host, you should be able to.

As Rownd matured, those two limitations—along with a handful of other friction points—made it clear that Fauna was no longer the right foundation. We needed something we could deploy into standalone, private customer environments. And we couldn’t afford to depend entirely on one vendor in case of outages—or worse.

So in 2023, we began migrating to a more traditional DBMS. The migration was split into two phases: first, moving all shared “control plane” data. Second, migrating “data plane” customer and user records.

Both phases had the same core requirement: zero downtime, no maintenance windows, and no noticeable impact to customers. To do this, we had to run both databases in parallel and ensure data consistency before switching anything over. And that’s not a trivial problem.

We searched for prior art, libraries, or tooling to help—but came up short. While there are plenty of ETL tools and change-feed streamers, we found very little in the way of runtime libraries that could prevent the dreaded “flip the switch and pray” moment when transitioning to a new database.

So we built our own.

We added a database routing layer into Rownd’s core. Every read and write request passed through this layer, which would evaluate configuration and determine which database to query. This allowed us to migrate resource types (tables) one by one.

Each migration followed a staged process:

1. Read/write primary – Fauna handled both reads and writes.
   
   
   

2. Read primary, write all – Reads came from Fauna, writes went to both.
   
   
   

3. Read/write any – Reads could come from either database, favoring the new one.
   
   
   

While writes flowed to both databases, we ran ETL processes in the background to backfill and synchronize records. Once the data was consistent, we shifted reads over and eventually turned Fauna off for that resource entirely.

This strategy gave us fine-grained control over the migration. More importantly, it laid the groundwork for a dynamic and flexible future. Now, we can redirect data flows at runtime based on customer needs or compliance requirements. If a customer wants their data stored in a specific country or on a specific medium, we can make that happen—as long as the target supports the queries we need. This opens the door to powerful new capabilities like decentralized identity and data self-sovereignty.

By the end of 2024, we had fully migrated the control plane and were storing all new customer data on the new platform. Performance was excellent. We began laying out plans to migrate all legacy customer data as well.

Then, Fauna made another move: they announced the sunset of FQL v4 in favor of a completely incompatible language called FQL X. That sealed it. We needed to accelerate our plans and complete the migration well before the scheduled sunset in late 2025.

But of course, we couldn’t just focus on that. We still had a business to run—new customers to onboard, features to ship, bugs to fix, and a growing team to support. The migration was critical, but not always the top priority.

In mid-March, our team was together in Raleigh for an on-site. We were working on a wave of new ideas around AI-powered authentication—things like adaptive security, identity fingerprinting, and contextual trust scoring. It was an exciting time, full of energy and momentum.

Then the other shoe dropped.

We were all in a conference room when the email from Fauna landed. They weren’t just sunsetting FQL v4. They were shutting down the entire Fauna service—at the end of May.

We had just over two months to complete the migration of millions of user records. Again: no downtime. No customer disruption.

Thankfully, we had the infrastructure ready. But we still needed to build the final transformation pipelines to migrate all remaining user records in real-time. Carefully. In batches. In production.

We got to work.

We deployed a new queuing system using NATS, built a data migration and transformation pipeline on top of it, implemented dynamic parallelization to control throughput, and extended our routing strategy to the user management layer. All of this ran while continuing to support thousands of user sign-ins every hour—live, in production.

It wasn’t easy. In fact, it was one of the hardest infrastructure projects we’ve ever tackled. But on May 30—just one day before Fauna shut down—we completed the migration.

✅ Zero downtime.

✅ Zero customer disruption.

✅ Millions of records, safely migrated, transformed, and reindexed.

This experience reinforced a critical lesson: infrastructure decisions aren’t just about performance or ease of use—they’re about control, resilience, and long-term durability. Shiny tools will come and go. But your customers are counting on you to make decisions that stand the test of time.

At Rownd, we build systems that prioritize flexibility, reliability, and ownership. We choose open standards. We leave ourselves exit ramps. And we never outsource core infrastructure decisions to a third party.

We emerged from this migration faster, stronger, and more ready for what’s next.

And if there’s one takeaway we’d share:

Don’t wait until you’re forced to move.

Own your infrastructure. Build with optionality. And trust your roadmap more than any vendor’s.

Looking ahead, we’re building on this momentum. At Rownd, we’re committed to enabling our service to run anywhere—whether in the cloud, on-premises, or within a customer’s own infrastructure. We’re actively working to give customers full ownership of their data by supporting self-hosted deployments and offering a clear “off-ramp” from our hosted platform. That means customers can continue using Rownd’s core technology without changing their stack—even if they decide to stop using our hosted service. Stay tuned—there’s more to come!