supabase questions
Can't DM you, but my last project was Supabase so have a lot of recent experience here 🙏
10 Replies
nice!
was curious if you were able to share any thoughts on pros and cons of supabase vs. convex. we're looking to get feedback so we can start to be more well-versed in answering these kinds of things
Hmm....
Supabase:
THE GREAT
An excellent Postgres As a Service provider.
This is primarily what we ended up using them for. They gave us auth for free (not without its issues. Would repeatedly log users out) and scalable Postgres for cheap (no needing to setup pg-bouncer etc. on our own.
Very fast moving team
The product was constantly improving while we were using it (you have so far been able to do the same 🔥)
Cheap and predictable pricing
Their model is very simple and they are a price competitive Postgres provider. We didn't use their cloud functions, which means I knew not to expect any surprises.
Supabase and Elixir/Phoenix is a very cheap, stable, predictable and simple setup to run in comparison.
Local development is great
On a plane? no problem. Supabase will spin up the entire infrastructure locally so you can keep going. I loved that.
THE BAD
Their "query from the client" approach is great. Until it isn't
It was really fast to prototype with, but not having RLS enforced made us nervous about moving into production with the Supabase client. I also strongly dislike maintaining authorization logic across multiple .sql files. I missed a source of truth on "who can access what?". Though you can find it through the schema, the complexity and lack of transparency made us not trust it.
Which made us... roll our own.
They make migrations easy! Until they break
Because of the client issues before, we started moving everything into a more traditional backend (Elixir and Phoenix in our case). I generally appreciate that solution, but it comes with a lot of overhead on any new feature. The speed I felt in the early days of Supabase weren't maintaned. But it did increase testing and confidence in what we were building.
We initially tried going half and half - but you either have to fully relinquish control of migrations to Supabase or you have to completely own them yourself. And when you own them yourself you've pushed yourself out of the ecosystem.
Testing is hard and unwieldy
This is true of both Convex and Supabase right now. Supabase is relying on database tests, which you won't get me to touch with a ten foot pole.
The solution is to using them just as a database provider and you get ease of testing back... at the expense of execution speed.
Convex testing is still largely undocumented. And mocking and stubbing is fine if your actions and mutations are simple - but for anything more than that it felt like I was writing 2x the test code for what I was testing.
The Ugly
Supabase try to sell themselves on real time, but the reality is very different. It's a glorified notifier, that leaves "what should be refetched?" up to you as a developer. I've also read that for people who've bet on the feature, that they start hitting scale limitations on Postgres if you go all in on the real time features.
Convex:
THE GREAT
Can move fast, for longer
So far I've had more confidence in relying on Convex's paradigms. Which in turn has allowed us to move fast for a longer amount of time.
Realtime for free
I've hand rolled realtime features in the past and it's typically a late stage backlog item. But it's one that adds a really high level of quality and fidelity to a product. For what I'm building right now it's made people go from "oh, this is cool", to "wtf, how do I invest?". It's not just because of that, but it does add a sense of magic to the experience.
No infrastructure 😍
Using Vercel (and NextJS) and Convex means I have to spend very little time thinking about infrastructure. That's a big time saver at the early stage. Which pushes those concern until the economics support it.
THE BAD
Unpredictable pricing?
The horror stories I hear from friends who made a bet on serverless and firebase is that they had to jump a lot of hoops for certain things (anything long running is hard and expensive) and that cost equation would break sooner than you think.
I've found myself limiting how I design my code a bit more as of late, because I realize that "drying up things" would result in yet another function call.
I should just ignore it - but I don't like that cost is factoring into my considerations this early in the dev cycle.
Updates are fast... until they aren't
Updates were pretty fast when I first started using Convex. Now they take 15-40 seconds on average. This is after disabling the typechecking.
Which makes me spend a considerable amount of time looking at "Backfilling indexes"... "Preparing convex functions".... "Convex functions are ready!"
I'd love love love some kind of local development setup...
THE UGLY
Testing is hard and unwieldy
Convex testing is still largely undocumented. And mocking and stubbing is fine if your actions and mutations are simple - but for anything more than that it felt like I was writing 2x the test code for what I was testing.
So I don't have any tests for my backend code right now. I'm fine flying blind right now. But I'm wary of operating in production this way.
Migrations are also undocumented
You guys have written a lot of great helper libraries, but you have to dive through your blog to find them. You're past 1.0 now. RLS, relationship helpers, migrations should all be something you guys have strong opinions on.
So far I'm wiping data, but I'm worried that dev speed will take a serious hit once I'm forced to migrate data.
Explicit data migrations is one of the things I most appreciate about Postgres.
The "no data migrations needed!" mantra of no-sql is a lie any developer will confront if they spend enough time with a no-sql system.
this is amazing feedback, thanks!
Btw, would love a call with you some time if you're up for it, @The Aleks . agree completely on the G/B/U of convex as well. we have plans for all of these things, but as a small team we're definitely not quite getting them out as fast as we'd like to and as fast as users deserve
I'd love to - can you send me a friend request?
@The Aleks it seems unfortunately I can not
@The Aleks re: build times, we have a new option available to speed things up here, assuming a lot of your build times are in bundling for node.js actions... (which is usually the case)
Convex News
Announcing Convex 1.4
Convex 1.4 introduces a new option to install packages used in your Node action environment on the server, a variety of logging improvements, a new option to pause deployments, a new npm create convex command and more!
External packages in Node.js
Before 1.4, several NPM dependencies were
Bundling | Convex Developer Hub
Bundling is the process of gathering, optimizing and transpiling the JS/TS
this allows you to create a server environment that has a foundation of pre-installed packages on it so you can avoid rebundling them every time you change your application code
That might have helped a bit! It's down to 10 seconds now... which is slow, still 🙈
But it might be because one of the packages I use brings it above the 45mb (48mb to be exact)