Why We Migrated Rideez From Firebase to AWS

When we started building Rideez, Firebase was the obvious choice. It let a small team ship a real, working product fast — authentication, a real-time database, cloud functions, and hosting, all working together with almost no infrastructure setup. For the first six months of Rideez's life, that tradeoff was exactly right.

It stopped being right as we grew, and this is the story of why we moved.

Where Firebase started to show its limits

The first crack wasn't a single dramatic failure — it was a pattern of infrastructure and billing issues that kept compounding.

The biggest problem was unexpected cloud costs. As Rideez expanded its smart integrations and began using AI-powered services, including Gemini models, we started seeing cloud charges that didn't align with the services and usage we expected. In some cases, Google Cloud was charging us for services or usage that we weren't actively using.

More concerning was that Google's own systems flagged some of this activity as anomalous. On two separate occasions within a two-month period, the unexpected charges became significant enough that Rideez had to be temporarily taken offline while the billing issues were investigated and the charges were adjusted.

For a platform that handles reservations, payments, hosts, customers, and real-time services, having to take the product offline because of unexpected infrastructure charges wasn't a risk we were willing to accept.

By April 2026, it was clear this wasn't a temporary billing hiccup. The infrastructure we had originally chosen for a five-person MVP team was beginning to create operational and financial uncertainty that didn't fit where Rideez was heading.

That was the point where we stopped asking, "How do we make Firebase work?" and started asking, "What infrastructure do we actually want Rideez to run on?"

What we actually needed

Before deciding where to move, we got specific about what we needed that our existing Google Cloud and Firebase setup wasn't giving us:

• Predictable and controllable infrastructure costs as Rideez's usage grew.
• Clearer visibility and control over individual services and their consumption, particularly as AI and other managed services became part of the platform.
• Greater control over our backend architecture instead of having critical application logic tightly coupled to Firebase's ecosystem.
• An architecture that could support Rideez's growing number of independent services and access patterns.
• A foundation that could scale with the product without introducing unnecessary operational or financial surprises.

AWS wasn't the only option we considered, but it was the one that matched this direction most completely.

DynamoDB gave us the flexibility to design our data layer around the access patterns of Rideez rather than simply migrating our existing Firestore structure as-is. Lambda allowed us to run backend workloads independently and scale compute around individual services. And the broader AWS ecosystem gave us the flexibility to build Rideez as a collection of services rather than continuing to grow one increasingly interconnected backend.

The goal wasn't simply to replace Firebase with AWS.

The goal was to change how Rideez's infrastructure was designed.

How we actually did it

We didn't do a single cutover.

Rideez had already accumulated a substantial amount of functionality on Google Cloud and Firebase, including authentication, APIs, real-time functionality, and integrations. Moving everything at once would have introduced unnecessary risk, so we approached the migration incrementally.

We started with the foundation: users and authentication. Rather than attempting to rebuild the entire platform simultaneously, we began separating the pieces of Rideez's backend into services that could eventually operate independently.

From there, the migration became an architectural exercise rather than a simple platform switch. Existing Google Cloud Functions and Firebase-dependent functionality had to be mapped to their new AWS equivalents, while the underlying data model was redesigned around DynamoDB and our Node.js backend.

The hardest part wasn't simply moving data from one database to another. It was changing the architecture underneath a live product without losing the behavior that users already depended on.

That meant thinking carefully about API contracts, authentication, data access patterns, real-time functionality, integrations, and how individual services would communicate with one another.

We also made a deliberate decision not to move everything we already had simply for the sake of consistency. For example, Firebase Cloud Messaging remains part of Rideez because push notifications are a service we were already comfortable with and had no reason to replace.

The migration therefore became less about "leaving Firebase" and more about choosing the right infrastructure for each responsibility within Rideez.

What changed after the migration

The biggest change wasn't a single performance number.

It was control.

Moving toward AWS gave us a much clearer understanding of what services Rideez was running, what each service was responsible for, and where infrastructure costs were coming from. Instead of treating the cloud platform as one large abstraction, we could make deliberate architectural decisions around individual workloads.

The migration also gave us the foundation to move Rideez toward a more modular, microservices-oriented backend. Services can evolve independently, and infrastructure decisions can be made around the requirements of each workload rather than around the limitations of a single platform.

Not everything became easier.

Firebase's biggest strength is still its simplicity. A small team can get an impressive amount of functionality running quickly without needing to think deeply about infrastructure. AWS requires more architectural decisions, more configuration, and a much stronger understanding of the underlying services.

But that tradeoff became worthwhile for us.

We weren't building the same six-month MVP anymore.

We were building the infrastructure that Rideez would need for its next stage.

What we'd tell another team considering the same move

Firebase wasn't a mistake for us.

In fact, it was probably the right decision when we made it. It allowed a small team to move quickly, validate Rideez, and get a working product into the hands of users without spending months designing infrastructure.

The mistake would have been assuming that the infrastructure that was right for our first six months had to remain the infrastructure for everything that came after.

Our migration wasn't triggered because Firebase suddenly became a bad product. It happened because our requirements changed.

Unexpected cloud costs and billing anomalies were the catalyst, but the deeper realization was that Rideez needed more control over its infrastructure, backend architecture, data layer, and scaling strategy.

If you're considering a similar move, don't migrate simply because another platform is more popular or because someone tells you that you have "outgrown" Firebase.

Instead, write down exactly what is causing friction.

For us, it was unexpected costs, limited control over how infrastructure was consumed, and the need for a backend architecture that could evolve with Rideez.

Once we understood what we were actually solving for, choosing AWS became much easier.

The migration wasn't really about leaving Firebase. It was about building Rideez on infrastructure we could understand, control, and grow with.