Supabase Edge Functions
supabase.com
supabase.com
This one has been a long-time coming. It's one of our most requested features. We spent a long time getting the Developer Experience right - we investigated several approaches (Containers, Isolates, WASM), and eventually landed with Deno.
Big shout-out to the Deno team. Their open source and DX-focused philosophy made it an obvious choice in the end. We've wrapped their open-source runtime to make the Supabase experience as integrated as possible, from the local CLI development, to realtime logs on the Dashboard. Edge Functions are still Experimental, so make sure you send your feedback to make the experience even better.
We'll have a few of the team in the discussion ready to answer any questions.
Did you consider working with CloudFlare? I feel like Supabase is the perfect fill for the "holes" that CloudFlare has in their services, that you guys fill. They don't have two crucial things currently: Persistent Data Store that's accessible outside of its platform, and an Authentication product. They otherwise have everything else and more. Seems like it would have been a very mutual relationship.
Any insights on this one by chance?
I'm loving Supabase, and the only gateway to adoption on my side is the lack of SOC 2 compliance, which I understand is coming. However I don't want to give up best in class services for things like CDN, Storage, Workers etc. I'm kind of an "all in" platform person. I don't want variance in vendors, I want one vendor with variance, if that makes sense.
Don't per se mean I wouldn't use Supabase still, of course! I love the product where I have been able to test it out, and once SOC 2 compliance lands that will clear the final adoption hurdle for me anyway
We did consider Cloudflare Workers - ultimately it came down to the open source philosophy of the Deno runtime. It's incredibly important to us that everything in Supabase has "escape hatches" - you can choose to host wherever you want to. I'm certain that Workers will get there eventually, but it's not there yet. We're still big fans and will be doing other neat things with them in the future (also we'll revisit Workers if the runtime becomes an open source).
> lack of SOC 2 compliance
We've chosen the auditor - I believe SOC2 Type I will be around 4 months away (next Launch Week)
I'm rooting for you guys, not only your tech stack is very solid, but commitment to letting your users self-host if they want to is laudable.
But here's something I don't understand about your offering. Taking a look at the pricing page https://supabase.com/pricing there is only one pricing tier above free but below the scary-looking "contact us for a quote". The idea is that you get a reasonable baseline included and pay for extra storage and bandwidth. Cool.
But it comes with a number of fixed limits that I find puzzling, like 100k monthly active users. On edge functions, they can run 1000 hours (per month?), invoked 2 million times, and there's a limit of 100 functions in total. The customer can't pay a little more to have the limits raised a little further like they could with storage and bandwidth, they need to migrate to the enterprise plan. So I must ask: why is that?
I almost don't care because I'm the kind of person that likes to run their own servers but, I want to support you guys.
Everything in the "Pro tier" has a "usage cost" and you pay only for what you use above the $25 (or you can add a $25 spend cap to avoid an unexpected bill - https://supabase.com/blog/2022/03/30/supabase-enterprise#spe...)
I'll get the team revert the change today so that the Usage pricing is listed
Any timelines for support for Functions over QUIC/HTTP3 and raw UDP/TCP?
Cloudflare Workers, the closest thing to Deno Deploy, announced intention to support raw TCP a few months back (while "HTTP3" has been supported for quite a long time now).
Re: Database Functions:
I really like the dual nature of Cloudflare's database offerings:
Durable Objects (run functions close to data) as an option for apps that need that kind of strong consistency guarantees.
KV (move read-only data close to functions) as an option for apps that can tolerate race but desire speed.
I'll ask the Deno team. I'm curious what your use-case is for these (especially UDP)?
> Cloudflare's database offerings
DO and KV are both incredible products. I think we'll tackle these a little differently since our "base" is Postgres. We are announcing more "edge-like" products tomorrow which will lay the groundwork
Custom network devices like TURN/STUN, L4/L7 load balancers (relays, gateways), authoritative / recursive DNS, Wireguard tunnels, WebRTC etc.
> We are announcing more "edge-like" products tomorrow which will lay the groundwork.
Exciting. Thanks! (:
https://community.cloudflare.com/t/how-truly-slow-is-workers...
The other solution is to use cloudflare durable objects. - which is what I use, but it's very verbose.
KV is a poor experience for me.
[0] https://developers.cloudflare.com/workers/runtime-apis/cache...
1) Do the functions "freeze" once the response body has been sent back? Is it possible to return a response to the user (for a quick API response) and then continue doing some background work? This is has been a source of pain with AWS Lambda based services like Vercel that freeze execution once the response has been sent.[1]
2) How does keeping a connection pool work between function invocations? For example using Prisma for the nice typed DB functions.
[1] https://vercel.com/docs/concepts/limits/overview#streaming-r...
Just checked with the Deno team. These functions should not be used as "background workers" - perhaps that is something we explore in the future. It will work for a short time in theory, but it's not guaranteed.
> How does keeping a connection pool work between function invocations
Supabase offers several options here. You can either use the API (PostgREST)[0] - an autogenerated REST API, or the connection pooler (pgbouncer)[1] which we offer with every project.
> For example using Prisma
Supabase is a popular database hosting service for Prisma users because of the built-in pooling - it's a great product, especially their typed interface.
[0] PostgREST API: https://supabase.com/docs/guides/api
[1] pgbouncer: https://supabase.com/docs/guides/database/connecting-to-post...
Thanks for checking on it. We actually had to create a Cloudflare worker based "fire-and-forget" system to allow our Vercel functions to shoot off background tasks. Was hoping to replace that.
> Supabase is a popular database hosting service for Prisma
Agreed! We actually use Supabase as our backend for Willow[1] and use Prisma when writing backend functionality. It's been a real easy and fast process to use Supabase's JS client on the frontend to access data (with RLS!) and then Prisma+Supabase on the backend to modify data (with types!). We would love to allow user's to directly change data everywhere directly from the browser but we need to do some background tasks (sending notifications or updating related rows).
The dream would be to have a great DX experience around using insert/update triggers to call Supabase functions to run background tasks. Some type of Terraform-esque configuration (in a SCM) to set it up and keep it in sync would be awesome. We have some triggers that make http calls but we're limiting usage as keeping track of them outside of our other code isn't simple.
We have something for this: Function Hooks (soon to be renamed "Async Triggers")[0]. They are still in alpha, but the extension [1] is getting close. It was important to build something which works with PG background workers so that it's non-blocking. We'll make quick progress on this now that we've released Edge Functions.
> sending notifications or updating related rows
Tune in for tomorrow's announcement - it's related.
[0] Function Hooks / Async Triggers: https://supabase.com/blog/2021/07/30/supabase-functions-upda...
> However, Supabase already offers a flexible solution for that - Database Functions! As such, for Supabase [Edge] Functions, we decided to deploy far-and-wide so that they are as close to your end-users as possible.
Does this mean that a choice has to be made between high latency (Edge Functions) and specialised SQL-only functions (Database Functions)? I see that cron-like triggers are still on the roadmap, is there a plan to have TypeScript functions that can run close to the database (or other resources)? Call me new school (as in not old school), but I prefer processing complex queries in a language that I feel comfortable working in, SQL is not that.
I know a lot of folks are huge fans of writing pure SQL, the lack of type safety and lack of good intergration with source control (I dream of a world where database schemas, functions, security access and the rest can be saved to source control for reproducibility) scare me.
We are also exploring running Deno directly inside your database - https://github.com/supabase/postgres-deno
Just to double-up on Inian's comment - there is definitely a world where this happens, perhaps even inside the database itself (like plv8). We were focused on the Edge experience this time, but I'm excited about the future that an open-source TS runtime like Deno enables.
> I dream of a world where database schemas, functions, security access and the rest can be saved to source control for reproducibility
this was one of the main reasons we started supabase. we hope to make database development as easy as application development
Hey there are some migration tools that play nice with source control. For example, Flyway has repeatable migrations https://flywaydb.org/documentation/tutorials/repeatable, here's some links about this
https://stackoverflow.com/questions/25839666/flyway-strategy...
(Disclaimer, I am the author of it)
90% of the projects I work on are built on Firebase, our main worry with that is that we are locked-in, not only to "Firebase", but to Google as well which has a nasty history of just pulling the rug from under your feet without even telling you why.
Having alternatives to try and implement is always a priority for us and Supabase now (w/ edge functions) seems to cover most of our use cases, so we are definitely looking to switch to it.
Auth + Storage + Functions is all we really need, and that triad is now complete on Supabase.
Yes, we could host this all ourselves (since the Deno runtime is open source) on AWS, or more likely we'd work with someone like Fly who have a globally-distributed platform like Deno Deploy.
> is Supabase going to acquire Deno Deploy
There's no chance of that happening. We couldn't afford them. Deno will be a huge company - and rightfully so, their product is best-in-class
> Serverless compute options can be broken down into two broad categories:
> Containers as a Service (e.g. Google Cloud Run, Fly.io)
> Functions as a Service (e.g. Cloudflare Workers, Fastly Compute @ Edge, Suborbital)
For what I'm working on, I've put CF Workers in front of my GCF's. This allows me to terminate the SSL at the CF Worker (along with easy control of DNS) as well as control the URLs (and even content) that ends up being sent to the GCF workers as well as caching of results in CF. It gives me a huge amount of flexibility and very little complexity.
Currently doing 1m hits/day through CF workers and it is ~$6/mo + ~$20 for GCP (including a Postgres db and heavy use of pub/sub).
All the other important things are done... CI/CD for the whole development flow with Github actions doing deployments on push to main, logging and graphs comes standard. The developer experience with both GCP and CF is top notch.
Supabase continues to be an interesting alternative, but I really don't see a reason why I'd go with them.
Connecting to cloud sql postgres and serving a request that hits the database takes under 1s. Hot request/responses are ~20ms.
My hits are all US based, so I plopped myself into Central. No issues there either.
There is no way to avoid cold starts althogether, there will always be tail latencies unless there is a generous amount of idle instances running that GCP charges for.
> under 1s. Hot request/responses are ~20ms.
Those numbers are great, I think Go plays a huge part in this. Google's Node.js firestore SDK is terrible... I've had 15 second cold starts, which is unacceptable for client-facing functions, there's a whole thread about it here [1]. GCP doesn't have a very wide range of language SDK support for those that don't want to use Go or Node.js...
> My hits are all US based
Edge compute, like Fly.io or Cloudflare Workers truly shines when you need to serve traffic close to the user around the world. Otherwise normal region-locked functions are fine. Vercel requires you to choose a single region, and it's locked to US-east for free-tier users. For us Europeans over here, SSR has to effectively cross the Atlantic ocean.
I don't think it is terrible, but I do agree it is a slower startup than golang by a lot. Which is why I went with golang for this project and I stopped using firebase entirely. You really don't want to effectively be parsing all your source code every time a launch happens.
> Edge compute, like Fly.io or Cloudflare Workers truly shines when you need to serve traffic close to the user around the world.
For my app, it is really just about having another layer of control in front of my API calls. I don't care so much about the CDN aspects.
Edge Functions are deployed to 29 regions globally, which means that you can use them for low-cost, low-latency operations.
[0] Postgres Functions: https://supabase.com/docs/guides/database/functions
Free plan: 100k requests per day with up to 10ms CPU time per request.
Pro plan: $5/mo + $0.50/million requests per month with up to 50ms CPU time per request.
[0] Wasm target for Dart - https://github.com/dart-lang/sdk/issues/32894#issuecomment-1...