Edge Functions are now 2x smaller and boot 3x faster

We’ve rolled out some exciting updates to Edge Functions which bring significant reductions to function size and boot time. If you’re using npm modules in your functions, you should see function sizes being halved and boot time reduced by 300% in most cases.

To take advantage of these performance improvements, you can redeploy your functions using the Supabase CLI v1.192.5 or later.

Let’s compare the bundle size and boot time using some popular examples.

Supabase JavaScript Client:

_24

import { createClient } from 'npm:@supabase/supabase-js@2'

_24

_24

Deno.serve(async (_req) => {

_24

try {

_24

const supabase = createClient(

_24

Deno.env.get('SUPABASE_URL') ?? '',

_24

Deno.env.get('SUPABASE_ANON_KEY') ?? '',

_24

{ global: { headers: { Authorization: req.headers.get('Authorization')! } } }

_24

)

_24

_24

const { data, error } = await supabase.from('countries').select('*')

_24

_24

if (error) {

_24

throw error

_24

}

_24

_24

return new Response(JSON.stringify({ data }), {

_24

headers: { 'Content-Type': 'application/json' },

_24

status: 200,

_24

})

_24

} catch (err) {

_24

return new Response(String(err?.message ?? err), { status: 500 })

_24

}

_24

})

OpenAI:

_16

import OpenAI from 'npm:[email protected]'

_16

_16

const client = new OpenAI({

_16

apiKey: Deno.env.get('OPEN_AI_KEY'),

_16

})

_16

_16

Deno.serve(async (req) => {

_16

const { query } = await req.json()

_16

_16

const chatCompletion = await client.chat.completions.create({

_16

messages: [{ role: 'user', content: 'Say this is a test' }],

_16

model: 'gpt-3.5-turbo',

_16

})

_16

_16

return new Response(chatCompletion)

_16

})

Drizzle / node-postgres:

_25

import { drizzle } from 'npm:[email protected]/node-postgres'

_25

import pg from 'npm:[email protected]'

_25

const { Client } = pg

_25

_25

import { pgTable, serial, text, varchar } from 'npm:[email protected]/pg-core'

_25

_25

export const users = pgTable('users', {

_25

id: serial('id').primaryKey(),

_25

fullName: text('full_name'),

_25

phone: varchar('phone', { length: 256 }),

_25

})

_25

_25

const client = new Client({

_25

connectionString: Deno.env.get('SUPABASE_DB_URL'),

_25

})

_25

_25

await client.connect()

_25

const db = drizzle(client)

_25

_25

Deno.serve(async (req) => {

_25

const allUsers = await db.select().from(users)

_25

console.log(allUsers)

_25

_25

return new Response('ok')

_25

})

Let’s dive into the technical details.

Lazy evaluating dependencies and reducing npm package section size#

We use eszip format to bundle your function code and its dependencies when you deploy a function.

This binary format extracts the dependencies a function references from Deno's module graph and serializes them into a single file. It eliminates network requests at run time and avoids conflicts between dependencies.

This approach worked reasonably well until we added npm support. When functions started using npm modules, bundle sizes and boot times increased.

When a function is invoked, Edge Runtime loads the eszip binary for the function and passes it to a JavaScript worker (ie. isolate). The worker then loads the necessary modules from the eszip.

In the original implementation, before passing an eszip binary to the worker's module loader, we first checked the integrity of its contents. Each entry in it will have a checksum computed with the SHA-256 function immediately following the body bytes. By reading this and comparing it, we ensure that the eszip binary isn’t corrupted.

The problem is that calculating a checksum for every entry using SHA-256 is quite expensive, and we were pre-checking the integrity of all entries at a time when the worker doesn't even need that particular entry.

It is possible that some items that have been checked for integrity will not be referenced even if the worker reaches the end of its lifetime and reaches the end state.

Instead of performing the costly integrity check of all entries before passing it to the module loader, edge runtime lazily performs the integrity check whenever there is a request to load a specific entry from the eszip by the module loader.

This helped to significantly to reduce the boot times.

Another issue was that while serializing npm packages for embedding into eszip binaries, we used the JSON format. The entries in individual npm packages, which were already represented as bytes (Vec<u8>), were encoded as an array representation in JSON format ([255, 216, 255, 224, 0, ...]) instead of passing on as bytes, causing the outputs to bloat by up to 2x or more.

We refactored the serialization using the rkyv crate to encode this to lower to the byte level, which helped reducing the bundle sizes of eszip binaries containing npm packages.

You can find full details of the implementation in this PR https://github.com/supabase/edge-runtime/pull/343

Using a more computationally efficient hashing function#

There was a recent change in the eszip crate, which allowed the configuration of the source checksum.

This allowed us to switch to xxHash-3 over SHA_256 for the source checksums. Given that the checksums are used to ensure the integrity of sources in eszip, we could rely on a non-cryptographic hash algorithm that’s more computationally efficient.

To get the advantage of these optimizations, follow these steps:

• Update Supabase CLI to version is v1.195.2 or later.
• Then, redeploy your functions by running supabase functions deploy [FUNCTION_NAME]

Supabase Edge Runtime is fully open-source, and we value community contributions. If you would like to make any improvements, feel free to dive into the source and create an issue.

If you have any issues with Edge Functions in your hosted project, please request support via superbase.help.