If you are building using Supabase stack (Postgres as DB with pgVector), we just released a built-in embedding generation API yesterday. This works both locally (in CPUs) and you can deploy it without any modifications.
There are no extra costs other than the what we'd normally charge for Edge Function invocations (you get up to 500K in the free plan and 2M in the Pro plan)
neat! one thing i’d really love tooling for: supporting multi user apps where each has their own siloed data and embeddings. i find myself having to set up databases from scratch for all my clients, which results in a lot of repetitive work. i’d love to have the ability one day to easily add users to the same db and let them get to embedding without having to have any knowledge going in
We have a cluster of Edge Runtime instances in each region. We run multiple edge functions within an instance using v8 isolates (Deno's core runtime is a wrapper around v8 isolates). This setup provides a good balance between cost and security. Other edge hosting providers like Cloudflare also follow a similar setup.
Hey, thanks for sharing this on HN! I'm one of the Edge Functions developers at Supabase and co-author of the blog post. We are very excited about releasing npm support and looking forward to seeing how the community build awesome apps with the Supabase stack.
I am happy to answer any questions or receive feedback.
how deep does the support go? i.e. can we safely import from node platform builtins like `os` or are the same bundling gymnastics still required there? (fwiw this is one of the major issues with vercel's edge funcs)
Most builtin modules should work (except for things like `vm` which we cannot safely sandbox in edge runtime). Deno has a good guide on the compatibility of built-in modules https://docs.deno.com/runtime/manual/node/compatibility
You can do:
```
import os from "node:os"
console.log(os.hostname())
```
and it should just work both locally and when deployed. No extra steps needed.
We used to cache the modules locally, I will need to check if we made any configuration change. Can you kindly open an issue for Supabase CLI - https://github.com/supabase/cli/issues
Hey @cjonas, I'm a developer on Supabase Edge Functions team. We do have plans to improve the current database trigger behavior. Will share more updates on this in the coming months.
Can you explain what do you mean by template URLs? Do you mean route params like `/v1/functions/users/:id`? If so, you can use a framework like Oak[1] to handle them. Edge Functions will make the full path including querystring available to the router.
Source maps, is it broken during local dev or when you deploy the function? Also, by broken you mean in a stack trace the file / line numbers aren't accurate?
> We do have plans to improve the current database trigger behavior. Will share more updates on this in the coming months.
Excited to hear more! Being able to trigger functions from DB & cron triggers without having to hardcode a secret (which causes them to end up in migrations files) will be a huge improvement.
> Can you explain what do you mean by template URLs?
Oh, I had no idea that the functions routes were "wild card"! I don't think that's mentioned anywhere in the documentation, btw.
> Source maps, is it broken during local dev or when you deploy the function?
"Source maps" (does deno actually use source maps?) ARE broken as well. EG: The line numbers in runtime don't line up with the function code in the IDE or even that is in the docker volume.
If you use Supabase CLI to serve functions locally, you can use the `--no-verify-jwt` flag, ie. `supabase functions serve --no-verify-jwt` will skip JWT checks locally.
Is that what you're after? if you have any further issues with serving functions locally, can follow up on the support ticket.
Yes, this is something we are exploring for Edge Runtime. One cool development is AsyncLocalStorage now works on Deno via a polyfill [0]. We may enable a single node store on Edge Runtime using this. Also, there are some interesting development in Supabase platform to enable Edge Databases, which could also be an answer to this.
What stands out for me about Deno over Node is its overall architecture.
1. It has a built-in permissions model [0] which gives end-user the control over what resources a script can access within a system.
2. As mentioned in the blog post, Deno runtime is extremely modular you can customize it per use case. This helps with security, performance and overall developer experience.
3. Deno has first-class support for Web Platform APIs, which reduces the need for reliance on third-party modules for simple tasks. A good example here is the native fetch module shipped with Deno. Unlike in Node, you don't end up with multiple modules implementing fetch.
4. Built-in tooling - Deno CLI has built-in tooling for formatting, linting, doc generation, benchmarking, etc. This is great for developer ergonomics, especially for people from Go and Rust backgrounds.
Hi Mark, hosted Supabase Edge Functions would still run on Deno Deploy, so those limitations would still exist. However, we plan to introduce file system access via integration with Supabase Storage. This is still a rough idea stage, maybe we'll have a solid answer in a couple of months :)
For dynamic imports, we haven't looked into it since Supabase users haven't requested it. If you can open an issue on Edge Runtime repo [0] and explain how you intend to use them, we can probably work on a solution.
Check this video on building Semantic Search in Supabase: https://youtu.be/w4Rr_1whU-U
Also, the blog on announcement with links to text versions of the tutorials: https://supabase.com/blog/ai-inference-now-available-in-supa...