Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Supabase

blog.val.town

Post reply on HN
Print view View original

31–40 of 136 posts

Re: Migrating from Supabase

#31

Post by ilrwbwrkhv »

xrd wrote: post #18
ilrwbwrkhv wrote: post #13

I also had the same experience with Supabase. Even though it looks like a great product initially, it has a lot or errors and bugs when you are trying to actually build something more robust than a toy app. Local development is a massive pain with random bugs. The response time of the database also varies all over the place. But the most important problem that we faced, was having so much of application logic in the…

I agree. I would love to see more articles on pocketbase. It's phenomenal and ganigeorgiev is an animal about responding to bugs and discussions. He's got to be a hybrid human and ChatGPT robot.

What's also really cool is that you can also just use PocketBase as a Go library and just build your app around it like any normal web framework, while still having a great UI for quick prototyping. And when you need more custom behaviour instead of database functions, you just write some Go code while still compiling everything down to a single binary that you can copy over.

Re: Migrating from Supabase

#33

Post by tmcw »

tonerow wrote: post #32

Supabase is also great for auth. Did you reimplement auth yourself or switch to another auth service or framework?

We switched to Clerk.dev. Thankfully we had only supported magic link auth, so there wasn't much information to migrate over. Clerk has been pretty good - they have a great Remix integration and solid admin experience.

Re: Migrating from Supabase

#34

Post by tr3ntg »

kiwicopple wrote: post #15

hey hn, supabase ceo here the Val Town team were kind enough to share this article with me before they released it. Perhaps you know from previous HN threads that we take customer feedback very seriously. Hearing feedback like this is hard. Clearly the team at Val Town wanted Supabase to be great and we didn’t meet their expectations. For me personally, that hurts. A few quick comments 1. Modifying the database in pr…

Appreciate this well-thought out response. As someone who has built several proof-of-concepts on Supabase (but never going far enough to test its limits), articles by Val Town here and responses like yours all work towards my analysis of the platform for future projects.

It's funny that threads like these bring up comments like "Well I use XYZ and it solves all of my problems." As if a one-time mention of a new PaaS is enough to bank on it for future projects. Although I can't lie - I do bookmark every PaaS that I see mentioned on HN.

Regardless, I'd much rather put my faith in a platform like SB that has been battle-tested in public, even if it doesn't work out perfectly every time.

Always glad to see you and the team showing up for the discussions and improving SB.

Re: Migrating from Supabase

#35

Post by doodlesdev »

tonerow wrote: post #32

Supabase is also great for auth. Did you reimplement auth yourself or switch to another auth service or framework?

PSA: Supabase Auth is based on their fork [0] of Netlify's Gotrue [1]. If you are migrating out of Supabase completely you can just drop in Gotrue for authentication.

[0]: https://github.com/supabase/gotrue

[1]: https://github.com/netlify/gotrue

Re: Migrating from Supabase

#36

Post by doodlesdev »

tmcw wrote: post #33
tonerow wrote: post #32

Supabase is also great for auth. Did you reimplement auth yourself or switch to another auth service or framework?

We switched to Clerk.dev. Thankfully we had only supported magic link auth, so there wasn't much information to migrate over. Clerk has been pretty good - they have a great Remix integration and solid admin experience.

Any specific reason to go with it instead of alternatives?

Re: Migrating from Supabase

#37

Post by tr3ntg »

pbreit wrote: post #7

The options for spinning up CRUD apps (ie, 95% of projects) are still quite miserable.

I'd say Supabase is great at spinning up CRUD apps. If anything, this article could be summarized as "Because Val Town is much more than a CRUD app, they had a harder time with Supabase than the average."

Re: Migrating from Supabase

#38

Post by PKop »

Interesting statement here:

"We rewrote our data layer to treat the database as a simple persistence layer rather than an application. We eliminated all the triggers, stored procedures, and row-level security rules. That logic lives in the application now."

Reminds me of the article and discussion here[0] over whether to put logic in the database or not and to what degree.

[0] https://news.ycombinator.com/item?id=35643432 "Use Databases Without Putting Domain Logic in Them"

Re: Migrating from Supabase

#39

Post by ahachete »

doctorpangloss wrote: post #11

> The CLI manages the Supabase stack locally: Postgres, gotrue, a realtime server, the storage API, an API gateway, an image resizing proxy, a restful API for managing Postgres, the Studio web interface, an edge runtime, a logging system, and more – a total of 11 Docker containers connected together. Can Supabase author a set of Kubernetes manifests similar to what they run in production, and perhaps distribute those…

This is not from Supabase, but as a community contribution. See upthread [1]: "at StackGres we have built a Runbook [2] and companion blog post [3] to help you run Supabase on Kubernetes."

[1]: https://news.ycombinator.com/item?id=36006308

[2]: https://stackgres.io/doc/latest/runbooks/supabase-stackgres/

[3]: https://stackgres.io/blog/running-supabase-on-top-of-stackgr...

Re: Migrating from Supabase

#40

Post by dingledork69 »

ilrwbwrkhv wrote: post #13

I also had the same experience with Supabase. Even though it looks like a great product initially, it has a lot or errors and bugs when you are trying to actually build something more robust than a toy app. Local development is a massive pain with random bugs. The response time of the database also varies all over the place. But the most important problem that we faced, was having so much of application logic in the…

I don't use supabase, but am a big postgres fan:

> that stuff in unmaintainable

Wrong. Version your functions and use something like liquibase to apply migrations.

Post reply on HN