When we started building Odavio, we made a decision that raised eyebrows: we went all-in on Cloudflare. Not just for hosting or CDN, for everything. Our API runs on Workers. Our database is D1 (SQLite at the edge). Our file storage is R2. Our real-time messaging runs on Durable Objects. Our frontend deploys to Cloudflare Pages.
Most people thought we were crazy. "You are building a business platform on SQLite?" Yes. And we'd do it again.
The decision framework
We evaluated our stack against three criteria:
- Operational simplicity — We are a small team. Every piece of infrastructure we do not have to manage is time we can spend on product.
- Global performance — Our users are in Canada, the US, and Europe. They should all get the same fast experience.
- Cost predictability — Traditional cloud bills are unpredictable. We wanted a model where costs scale linearly with actual usage.
Why Workers + D1
Cloudflare Workers run at the edge in 300+ cities. There is no cold start problem (unlike Lambda). There is no region to choose. Your code just runs close to your users, everywhere.
D1 is SQLite, replicated globally. For a multi-tenant SaaS serving small businesses, the query patterns are simple and SQLite handles them well. We don't need the complexity of Postgres for what we're building.
The combination means our API responses typically complete in under 50ms for users worldwide. Try getting that with a traditional VPS in us-east-1.
Durable Objects for real-time
The most underrated part of our stack is Durable Objects. We use them for our real-time messaging system. Each conversation gets its own Durable Object, essentially a tiny stateful server that lives at the edge. It handles WebSocket connections, message ordering, and presence detection.
The nice part is that we didn't have to set up Redis, manage WebSocket servers, or worry about horizontal scaling. Cloudflare handles all of that. We just write the business logic.
The hard parts
Let's be honest about the challenges:
- D1 is still maturing. We hit row limit constraints early on and had to redesign some query patterns. No full-text search meant we built our own lightweight search.
- Debugging distributed systems is hard. When your code runs in 300 cities, reproducing a bug that only happens in one location requires good logging infrastructure.
- The ecosystem is smaller. Compared to AWS, there are fewer blog posts, fewer Stack Overflow answers, fewer libraries. You are sometimes the first person to solve a specific problem.
- Vendor lock-in is real. Our code is deeply integrated with Cloudflare's APIs. Moving would be significant effort. We've accepted this trade-off because the benefits outweigh the risks for us.
The unexpected benefits
Development velocity. With no infrastructure to manage, our deployment pipeline is just "push to main." No Terraform, no Kubernetes YAML, no Docker compose files. This simplicity compounds over time.
Cost efficiency. Our monthly infrastructure cost for serving thousands of users is under $50. That includes database, file storage, Workers compute, and Durable Objects. Try doing that on AWS.
Resilience. We've never had a self-inflicted outage. No misconfigured security group, no database running out of disk, no container OOM-killing. The managed infrastructure just works.
Would we do it again?
Without question. For our use case, the Cloudflare stack is nearly perfect. The constraints of D1 forced us to write simpler, more efficient queries. The limitations of Workers forced us to keep our API lightweight. These constraints made our product better.
That said, this stack is not for everyone. If you need complex SQL joins across millions of rows, or if you need GPU compute, or if vendor diversity is a hard requirement, look elsewhere. But if you're building a modern SaaS product and you value simplicity, performance, and cost efficiency, give Cloudflare a serious look.