[adamcharnock]

This is exactly true, and is something we have built our business around. In fact, I just kicked-off a multi-TiB Postgres migration for one of our clients this morning. We're moving them out of Supabase and onto a bare-metal multi-AZ Postgresql cluster in Hetzner.

I'm going to say what I always say here - for so many SME's the hyperscaler cloud provider has been the safe default choice. But as time goes on a few things can begin to happen. Firstly, the bills grow in both size and variability, so CFOs start to look increasingly askance at the situation. Secondly, so many technical issues start to arise that would simply vanish on fixed-size bare-metal (and the new issues that arise are well addressed by existing tooling). So the DevOps team can find themselves firefighting while the backlog keeps growing.

The problem really is one of skills and staffing. The people who have both the skills and desire actually implement and maintain the above tend to be the greying-beards who were installing RedHat 6 in their bedrooms as teenagers (myself included). And there are increasingly few of us who are not either in management and/or employed by the cloud providers.

So if companies can find the staff and the risk appetite, they can go right ahead and realise something like a 90% saving on their current spend. But that is unusual for an SME.

So we started Lithus[0] to do this for SMEs. We _only_ offer a 50% saving, not 90%. But take on all the risk and staffing issues. We don't charge for the migration, and the billing cycle only starts once migration is complete. And we provide a fixed number of engineering days per month included. So you get a complete Kubernetes cluster with open source tooling, and a bunch of RedHat-6-installing greying-beards to use however you need. /pitch

[0] https://lithus.eu

[tecleandor]

I've been trying to start a very similar thing around here (Spain) at first specializing a bit on backups and storage, still working very small as an independent contractor while I keep my daily job (at least for now, I'm testing the waters...).

I don't really totally miss the days where I had to configure multipath storage with barely documented systems ("No, we don't support Suse, Debian, whatever...", "No, you don't pay for the highest support level, you can't access the knowledge base..."), or integrate disparate systems that theoretically were using an open standard but was botched and modified by every vendor (For example DICOM. Nowadays the situation is way better.) or other nightmare situations. Although I miss accessing the lower layers.

But I've been working for years with my employers and clients cloud providers, and I've seen how the bills climb through the roof, and how easy is to make a million-dollar mistake, how difficult (and expensive) is to leave in some cases, and how the money and power is concentrated in a handful of companies, and I've decided that I should work on that situation. Although probably I'll earn less money, as the 'external contractor' situation is not that good in Spain as in some other countries, unless you're very specialized.

But thankfully, the situation is in some cases better than in the 00s: documentation is easier to get, hardware is cheaper to come by and experiment or even use it for business, WAN connections are way cheaper...

[h_ko]

Just curious: Did you move to self-hosted Supabase? Or migrated to the underlying OSS equivalents for each feature/service?

I find Supabase immensely helpful to minimize overhead in the beginning, but would love to better understand where it starts breaking and how hard an eventual migration would be.

[adamcharnock]

In this particular case the only need was for Postgres migration, no other services needed.

The problems we've seen or heard about with Supabase are:

* Cost (in either magnitude or variability). Either from usage, or having to go onto their Enterprise-tier pricing for one reason or another * The usual intractable cloud-oddities – dropped connections, performance speed-bumps * Increased network latency (just the way it goes when data has to cross a network fabric. Its fast, but not as fast as your own private network) * Scaling events tend not to be as smooth as one would hope

None of these are unique to Supabase though, they can simply all arise naturally from building infrastructure on a cloud platform.

Regarding self-hosted Supabase - we're certainly open to deploying this for our clients, we've been experimenting with it internally. Happy to chat with you or anyone who's interested. Email is adam@ company domain.