Cool to see dev-ex improvements around local Postgres testing. At Graphite we use pg-mem for fast unit tests, but it's not ideal. It's extremely fast, but certain advanced queries aren't supported. Curious about what others do for unit testing Postgres operations?
Supabase Local Dev: migrations, branching, and observability
11–20 of 57 posts
Re: Supabase Local Dev: migrations, branching, and observability
#12hey hn, supabase ceo here a few months ago one of customers migrated away from supabase and they wrote a blog post about it. That blog post appeared here[0] on hacker news. many of the issues they encountered were related to local development. we made several promises to improve based on that feedback and the various comments in the HN thread today’s launch delivers on many of those promises. We’ve added better suppo…
Love the candor and follow-up on community feedback! Sounds like y'all are working hard, keep it up :)
Re: Supabase Local Dev: migrations, branching, and observability
#13Are you considering releasing an ORM or providing better support for Prisma?
We provide libraries for PostgREST, which auto-generates an API from your Postgres tables. Is that sufficient or are you looking for something else?
Prisma is already well-supported in supabase (since it’s just Postgres and prisma already works with Postgres)
edit: here is the prisma guide -https://supabase.com/partners/integrations/prisma
Re: Supabase Local Dev: migrations, branching, and observability
#14I hate to be this guy, really. I would like to adopt Supabase in my company, but I cannot yet.
I commented on a HN post almost a year ago about how hard is to do custom Auth with Supabase. I still haven't find a good solution about it. For example, LDAP Auth is quite crucial in most enterprise settings, yet I have no idea how to do it with Supabase. I can find a workaround for PostgREST by putting a secondary API written in some other language and fiddling with reverse proxies. But how to do with Supabase, such that all other services (realtime,...) works nicely? Is it so hard to provide a function that accept a custom strategy given the HTTP request data?
I created an issue[0] almost a year ago on Supabase, which was transferred to Gotrue. I even provided some code examples from Laravel. Even if it is not specifically for LDAP, make some API available to do so, please.
Re: Supabase Local Dev: migrations, branching, and observability
#15hey hn, supabase ceo here a few months ago one of customers migrated away from supabase and they wrote a blog post about it. That blog post appeared here[0] on hacker news. many of the issues they encountered were related to local development. we made several promises to improve based on that feedback and the various comments in the HN thread today’s launch delivers on many of those promises. We’ve added better suppo…
Thank you so much for taking the initiative to learn and grow from that experience. My team is in the fledging stages of using Supabase to rebuild a mission-critical application for our company. We were initially disappointed with what we found in terms of CI/CD and local development but we liked Supabase enough for other reasons to keep moving forward with it. I'm really glad we did because I think this has the pote…
> I get the impression that you're making really good calls as it relates to your roadmap
we receive feedback from a lot of channels so it's often hard to figure out what to build. In the early days it was about reaching feature-parity with other tools. now we have a bit more breathing-room to focus on "day 2" problems. I think our team is excited about this phase since it means we get an opportunity to build something new/innovative
Re: Supabase Local Dev: migrations, branching, and observability
#16For the Observability tools for Postgres category, are there plans to bring some of this information into things like trace data via OpenTelemetry? Would love to capture this info continuously instead of needing to dig in with a CLI tool when monitoring notes something is awry.
yes otel across all of Supabase in on our radar for sure. we just added ingest support for otel payloads to Logflare (docs coming soon) so when we have that you'll get them on the platform and locally.
if you haven't seen the metrics endpoint we do have an endpoint you can scrape for all your Supabase metrics, and we just improved the example repo quite a bit on how to ship those somewhere: https://github.com/supabase/grafana-agent-fly-example/
Re: Supabase Local Dev: migrations, branching, and observability
#17hey hn, supabase ceo here a few months ago one of customers migrated away from supabase and they wrote a blog post about it. That blog post appeared here[0] on hacker news. many of the issues they encountered were related to local development. we made several promises to improve based on that feedback and the various comments in the HN thread today’s launch delivers on many of those promises. We’ve added better suppo…
Massive congrats on shipping this. Will really improve the DevEx. Are you hiring?
Re: Supabase Local Dev: migrations, branching, and observability
#18Huge congrats for shipping some of these features. I know many of us have been wanting them for a while. In particular, migration squashing will be super helpful. I'm a little iffy on the branching stuff, since I like the solution of having two separate Supabase projects to act as different environments (though that's certainly not as powerful as actual branching, but it's simpler to reason about). Really excited to…
> I like the solution of having two separate Supabase projects to act as different environments
This won't be going away. Branching will just be another option
fwiw, I've also heard from a few enterprise companies that the git-based branching model isn't as suitable for them, because every other tool in their stack works in a prod/stage/dev type model, and there is no simple way to make it work with (for example) ~30 different environments
The branching model is really an "all-in" solution. It works particularly well if you're using something like Vercel/Netlify for your frontend. If you're using a serverside framework (Django, Rails, Phoenix, etc) then it's not as simple. That said, I think it's the way the world is moving, and with the advent of cheap VMs then it makes it very plausible even for these serverside frameworks
Re: Supabase Local Dev: migrations, branching, and observability
#19Wow, these are very useful. Is there an example project that demos the best way to setup these features? edit: I see TFA links to the docs where most things are covered ( https://supabase.com/docs/guides/cli )
Here is an example project: https://github.com/supabase-community/vercel-ai-chatbot
You'll see there is a "supabase" folder inside it so you can clone it and run "supabase start" to get started immediately.
You can also hit the blue deploy button and you'll have a full application deployed in ~1 minute (frontend on Vercel, backend on Supabase)
Re: Supabase Local Dev: migrations, branching, and observability
#20Are you considering releasing an ORM or providing better support for Prisma?
Supabase is basically the anti-ORM. Set everything up and just start using it: