I've used Digital Ocean for nearly 10 years. It's been good.
That said: I don't know enough about your situation, but ... what are you optimizing for?
AWS/GCP/Azure have each got a platform that provides a heap of functionality. Using that will save you time-to-delivery and engineer-hours. All the clouds have startup programs that will mean it's basically free until you get some traction.
If you're looking for investment, using AWS/etc means you instantly avoid all the questions about CapEx and risk that follow from self-hosting.
Don't underestimate the upside of not dealing with a bunch of cobbled-together service providers (hosting, billing, SMS for 2FA, email, monitoring, etc, etc). Having a single provider and a single bill simplifies your admin a lot.
And if you need to scale in a hurry, it's a whole lot easier if you've adopted a cloud platform.
Is avoiding lock-in really a big problem? In your software, you can either use a third-party abstraction, or build a shim layer that sits above the services you use that would allow you to migrate (even to self-hosting) if you had to. For the most common services, there's not even really a need for this: the AWS API is widely supported anyway. The devops/sysadm side is harder though.
Some of this won't apply if you're bootstrapping: it's more work, but vastly cheaper to do a lot of stuff yourself, and renting a half-cabinet colo and stuffing it with off-lease servers will cost you engineer-hours, but saves a heap of cash. Augmenting that with a PC at home for backup, and cheap VMs from Digital Ocean, Vultr, Hetzner, Linode, etc for scale might work out well. But it's hard to beat the free plans from the clouds.
Don't underestimate the downside of using those "heaps of services". It was funny to see someone using RDS and was warned of expiring CA certificate and AWS suddenly charging for extended support because the version they were using went out of support period.
I laughed how they were supposed to just install MySQL locally and avoided all that. If you wanted point in time recovery, just read the doc for an hour and do it yourself when you have to spend more time reading warning email from AWS and search around to see what they meant for unnecessary interactions of their artificial limitations.
Some people seem to think using "heaps of services" make them look smarter but they're not.
Free plans are to lure you into their locked up ecosystem and gives you no gain on knowledge by dealing with their limitations, rather better to learn the tools you're using.
It sounds like the OP has made their decision, and wants to avoid "the big three", so this is likely a moot point. But ...
Dependencies are always a trade-off. Be they code libraries/modules, programming languages, network protocols, services, etc, any dependency has the benefit of giving you something you'd otherwise have to implement yourself with the downside of then being tied to their schedule, quality, license, pricing, lock-in, etc.
In your RDS example, a similar problem might be a self-hosted database that has an urgent security update. If you're using a cloud provider, that's just taken care of without you even seeing any downtime. When self-hosted, that's a software upgrade, with all the attendant concerns about backwards compatibility, making sure you coordinate the replica upgrades, etc, etc. In both cases, ignoring the issue has costs (one financial, the other security).
In implementing a system, it's your task to balance these tradeoffs. In an investment-funded startup, often the evaluation of the costs and benefits is a little different to what it might be for a bootstrapped startup or an ongoing business. With a limited runway and resources, leveraging the work of others can be a lot more attractive.
Free plans do tend to make expanding your set of dependencies very easy, and cloud-based infrastructure is certainly expensive when compared to the direct costs of self-hosting. But it's there now, and will be there with no ongoing effort on your part. Sometimes, that's worth the cost for the time to market.
All that said: this isn't an either/or. Digital Ocean has a bunch of services that you might choose to use too, and they're not "the big three".
That said: I don't know enough about your situation, but ... what are you optimizing for?
AWS/GCP/Azure have each got a platform that provides a heap of functionality. Using that will save you time-to-delivery and engineer-hours. All the clouds have startup programs that will mean it's basically free until you get some traction.
If you're looking for investment, using AWS/etc means you instantly avoid all the questions about CapEx and risk that follow from self-hosting.
Don't underestimate the upside of not dealing with a bunch of cobbled-together service providers (hosting, billing, SMS for 2FA, email, monitoring, etc, etc). Having a single provider and a single bill simplifies your admin a lot.
And if you need to scale in a hurry, it's a whole lot easier if you've adopted a cloud platform.
Is avoiding lock-in really a big problem? In your software, you can either use a third-party abstraction, or build a shim layer that sits above the services you use that would allow you to migrate (even to self-hosting) if you had to. For the most common services, there's not even really a need for this: the AWS API is widely supported anyway. The devops/sysadm side is harder though.
Some of this won't apply if you're bootstrapping: it's more work, but vastly cheaper to do a lot of stuff yourself, and renting a half-cabinet colo and stuffing it with off-lease servers will cost you engineer-hours, but saves a heap of cash. Augmenting that with a PC at home for backup, and cheap VMs from Digital Ocean, Vultr, Hetzner, Linode, etc for scale might work out well. But it's hard to beat the free plans from the clouds.