Evaluating Supabase

Working on a new app this weekend and through the YC network I’ve heard a lot about Supabase, an open source firebase alternative. Always being interested in new tech I thought I’d try it. I’m a huge postgres fan, and it was very intriguing how easy they make things like auth etc.

I did a spike on the docs and playing with the tool, and quickly came to the conclusion: this is great for simple CRUD apps, and probably pretty terrible for everything else.

What Supabase is Great For

Anything that’s a pure CRUD app.

I think if you’re doing a simple weekend project that’s a CRUD app, needs auth etc. Supabase is perfect. It’s probably the fastest way to get going with something custom and ship a CRUD app with a nice Nextjs interface. The idea that you can avoid writing endpoints and just manage permissions from postgres is pretty cool, and really sets a new precident for data management and transformations. I generally like this idea: developers spend too much time writing glue code that pulls data from postgres, has some application logic, and sends the data back to a client.

The Blockers

Probably the biggest blocker is that Supabase doesn’t have the features of a public cloud, and without those features it becomes difficult to build more complex apps. Things like workflows, async activities, and streaming are missing. You can’t even run a server if you wanted too, it all needs to be serverless typescript.

This means that when you want to do anything more complicated you need to use Supabase plus something gluing it (likely a serverless function) to a public cloud that is extra, creating this hacky architecture that won’t scale.

Example: say you want async activities or streaming (anything with a streaming backend or websockets). All of a sudden you can’t build any of that on Supabase so you need to go off platform, run your own servers and infra, and connect the two through what Supabase makes available.

I ran into this directly when I wanted to start running workflows. I wanted something like temporal or celery to run async jobs. This would mean setting up a separate temporal or celery service, and having serverless endpoints through supabase integrate with that separate service to run workflows. Want to cancel jobs or monitor their status? That’s just more glue code, hacking the two backends together.

In this world, any time I’d save on auth would go to gluing together two imperfect backends together in an architecture that I wouldn’t really want to live with long term. The costs of that bad architecture choice and lock-in are too great to justify using it.

Conclusion

The main problem I have with choosing this as a solution is the lock in it provides. It’s such a different paradigm than a rails or flask app that migrating off becomes nearly impossible. Whenever the scope of your project inevitably turns into something that Supabase can’t do, all of a sudden you’re locked into bad architecture choices that will follow you for the lifecycle of your company, and it’s really really hard to build out of it.

Whether Supabase realizes it or not, they’re directly competing with google cloud and aws, and they need most if not all of the services and features those platforms provide to really compete.