Why We Shipped Object Storage Before Managed Databases
If you only look at feature checklists, managed databases probably seem like the more obvious thing to ship first.
They are easy to market. Everyone understands the pitch. “We run PostgreSQL, MySQL, or Redis for you” is a very clean sentence. For a lot of cloud companies, that sounds like the natural milestone that proves the platform is becoming more serious.
We did not see it that way.
We shipped object storage first because we think infrastructure should be built in the order that makes the platform stronger, not just in the order that makes the homepage look more complete. And for us, object storage solved a more foundational problem earlier.
The wrong way to build a cloud platform
A lot of infrastructure roadmaps are shaped by optics.
What looks good in a comparison table. What sounds more advanced in a launch post. What makes people say, “Okay, now this is a real cloud.”
I understand the temptation. I really do.
But we have tried to build Raff around a different principle: the next thing we ship should make the whole platform more useful, not just more crowded. If a feature introduces a lot of operational weight without improving the foundation underneath, it can make the platform look broader while actually making it weaker.
That is the context behind this decision.
We did not ask, “Which launch sounds bigger?”
We asked, “Which layer makes more of the platform better right now?”
For us, the answer was object storage.
Object storage is more foundational than many people think
Object storage sounds simple until you list the number of things that depend on it.
Backups. Media files. Build artifacts. Static assets. User uploads. Exports. Logs. Generated files. Application blobs that should not live on the same disk as the VM that serves the app.
That list cuts across a huge number of workloads.
A team running one VM may already need it. A team running a web app almost certainly benefits from it. A team doing automation, CI, media handling, backup retention, or file-heavy application work starts needing it even faster.
That is why we did not think of object storage as a side product.
We thought of it as a platform layer.
Once it exists, a lot of other things get cleaner.
Managed databases are powerful, but they are not neutral
This is the part people miss.
Managed databases are not just “database hosting with nicer branding.” They are one of the most trust-sensitive infrastructure products you can ship.
If you get a VM slightly wrong, a customer can often work around it. If you get object storage slightly rough around the edges, many users can still adopt it gradually. If you get a managed database wrong, the blast radius is much bigger.
Because now you are taking responsibility for:
- backups
- recovery design
- failover behavior
- versioning
- storage performance under real load
- connection handling
- maintenance windows
- scaling expectations
- the customer’s confidence that their data layer is safe
That is not a feature I wanted to rush for the sake of sequence.
We were not interested in launching a shallow managed database product just so we could say we had one.
Object storage made more of Raff make sense immediately
When we launched object storage, it was not only about adding another SKU.
It made the rest of the platform more coherent.
A VM is useful on its own, of course. But modern applications should not force every kind of data onto the VM disk forever. Once object storage is in the platform, a more sensible application shape becomes possible:
- your VM runs the application
- your object store holds large files, assets, backups, and static data
- your networking model gets cleaner
- your recovery model gets cleaner
- your architecture starts looking less like “everything on one server” and more like a real cloud system
That is a more meaningful step than people sometimes realize.
It is one reason I see object storage as infrastructure, not decoration.
We wanted to launch a storage layer that people could use broadly
There is another practical reason behind the decision.
Object storage has a broader early-use footprint than managed databases for the kinds of teams Raff serves.
A lot of users do not want us to run their primary database on day one. Not yet. They still want control. They are still testing. They are still deciding whether the workload belongs in a VM, a container, or a more opinionated managed layer later.
But many of those same users absolutely do want:
- a place to store backups
- a place to keep media files
- a place to serve static assets
- a place to keep artifacts and exports
- a simpler way to separate storage concerns from VM concerns
That is a much wider adoption surface.
And if you are building a young platform, that matters.
It means the thing you ship first has a better chance of becoming part of many workloads instead of being reserved only for a narrower category of production users.
S3 compatibility mattered a lot in this decision
Another reason object storage came first is interoperability.
We did not want to invent an awkward storage product that forced users into a Raff-specific habit just to do something basic. We wanted a storage layer that fit the way builders already work.
That is why S3 compatibility matters so much.
If the API is familiar, the integration story is easier. Existing tools make sense. Migration is easier. Scripts and workflows do not need to be reinvented. The product starts life as something useful, not something the user has to translate first.
That is a strong platform move because it lowers friction immediately.
And that is very different from shipping a feature that sounds impressive but still requires the user to adapt heavily to the platform.
Shipping databases later was not hesitation. It was discipline.
I want to be clear about that.
Choosing not to ship managed databases first was not a sign that we underestimated them. It was the opposite.
We respected the complexity enough not to rush it.
A managed database service should not just exist. It should behave in a way that makes people trust it with something important.
That means we needed the surrounding platform and operational assumptions to be ready for it. We needed the product direction to make sense. We needed to be honest about what should be foundational first.
Object storage passed that test earlier.
Managed databases are still an important part of the platform direction. They are already visible publicly on Raff’s site, and they are clearly part of where the platform is going. But I would rather launch them later and correctly than earlier and thinly. That is an easy decision for me. :contentReference[oaicite:2]{index=2}
The order of launches says something about how we think
This decision also says something broader about Raff.
We are not trying to build the platform in the order that looks most dramatic in a pitch deck.
We are trying to build it in the order that creates a stronger operating model.
That means we care about the layers underneath:
- virtual machines that are fast to launch and easy to reason about
- networking that helps workloads stay cleanly separated
- storage layers that let applications be structured properly
- protection and recovery tools that make the platform safer to trust
- higher-level services only when they are ready to carry real responsibility
That is why Linux VMs, private cloud networks, and object storage fit together so naturally already.
They are not random product checkboxes. They are pieces of the same infrastructure logic.
Managed databases are still important — just not first
There is no anti-database message here.
Managed databases are a very important product category. For many workloads, they are the right abstraction. They remove operational burden, standardize backups, simplify failover, and make scaling more approachable for teams that do not want to own every database operation themselves.
That is exactly why they matter.
And it is exactly why they deserved patience.
If we had shipped managed databases first, before object storage, I think we would have been building the platform upside down. We would have been jumping to one of the most responsibility-heavy layers before establishing a storage primitive that many more workloads can use immediately and repeatedly.
To me, that would have been the more shortsighted move.
This is also about the kinds of teams we serve
Raff is not being built only for giant platform teams.
A lot of our users are developers, growing startups, lean engineering teams, and builders who need the cloud to be practical before it is theatrical.
Those teams do not always need the biggest-looking launch first.
They need the next useful layer first.
A team with a VM and an app can benefit from object storage very quickly. A team with backups, uploads, artifacts, or static assets can use it almost immediately. A team trying to clean up how application data is shaped can use it without redesigning everything.
That is a better first-use story.
And if you are building a cloud platform that wants to be genuinely useful, not just loudly expanding, that matters a lot.
What This Means for You
If you are building on Raff, the practical takeaway is simple:
we did not ship object storage before managed databases by accident.
We shipped it first because we think good platform sequencing matters. A strong cloud platform is not only a list of products. It is a set of layers that make more sense together over time.
Right now, that means you can already build around the pieces that are live and broadly useful: Linux VMs, private cloud networks, data protection, and object storage. And as higher-level layers like managed databases arrive, they will sit on top of a platform that already makes more architectural sense.
That is how we want Raff to grow.
Not by shipping the loudest thing first.
By shipping the right layer first.