Supabase and a relook at vendor risk

Vendor risk Is not just about outages or pricing

A few weeks ago I ran into an unusual issue. A few of my projects stopped working overnight. The reason was unexpected. Supabase had been blocked in India. There was no warning and no migration window, something I had neither anticipated nor planned for.

The incident was another reminder of how unpredictable the environment around software systems can be. The biggest learning for me was how vendor lock-in can introduce unexpected risk.

Today it was Supabase, but the same thing could happen with an LLM provider, a cloud platform, or any other critical service in a project.

A ban is just one scenario. Vendors shut down, get acquired, change pricing, or introduce breaking changes in their ecosystem.

In one of the projects I counted more than 25 files directly calling Supabase APIs. Migrating away would take a few days of work, which in many situations can quickly turn into a crisis.

We usually think about vendor risk in terms of outages or pricing changes. But there are actually three different layers to it.

Geopolitical risk

A service can suddenly become unavailable in a region because of regulation, sanctions, or policy changes.

Vendor risk

Companies shut down, pivot, get acquired, change pricing, or discontinue products.

Architectural lock-in

This is the part that is completely in our control. When a vendor SDK ends up scattered across the entire codebase, switching providers becomes painful.

The first two risks are difficult to predict. The third one is a design decision.

Third-party services should be treated as replaceable infrastructure.

Most of the time you will never need to switch providers.

But when something outside your control breaks a dependency, the difference between a few hours of work and a week of cleanup usually comes down to how the system was structured in the first place.