Best Practice for Simple Writes supabase: Client-Side SDK vs. Form Actions (Vercel Cost vs. Architecture)

[d1d4r]

Hello everyone,

I am building a SvelteKit application with Supabase, hosted on Vercel. My app involves standard CRUD operations, and I have implemented strong Row Level Security (RLS) policies on my database.

I am deciding between two architectural patterns for handling data writes (specifically INSERT) and want to understand the consensus on best practices regarding Vercel function usage and cost.

The Scenario
I have a simple form to add data. I see two ways to handle this:

Approach 1: SvelteKit Form Actions (Server-Side)
The request hits a Vercel Serverless Function, which then communicates with Supabase.

src/routes/todos/+page.server.ts

import { fail } from '@sveltejs/kit';

export const actions = {
  create: async ({ request, locals: { supabase } }) => {
    const formData = await request.formData();
    const title = formData.get('title') as string;

    const { error } = await supabase
      .from('todos')
      .insert({ title });

    if (error) {
      return fail(500, { message: 'Database error' });
    }

    return { success: true };
  }
};

• Pros: Progressive enhancement (works without JS), automatic cache invalidation/revalidation by SvelteKit.
• Cons: Incurs Vercel Serverless Function execution costs; adds an extra network hop (Client -> Vercel -> Supabase).

Approach 2: Direct Client-Side SDK
Since my RLS is secure, I bypass the Vercel server and write directly to Supabase from the component.

src/routes/todos/+page.svelte

Svelte
<script lang="ts">
  import { invalidateAll } from '$app/navigation';
  export let data;
  
  let { supabase } = data;
  let title = '';
  let isLoading = false;

  async function addTask() {
    isLoading = true;
    const { error } = await supabase
      .from('todos')
      .insert({ title });

    if (!error) {
      title = '';
      // Manually trigger reload of load functions to refresh UI
      await invalidateAll(); 
    }
    isLoading = false;
  }
</script>

<button on:click={addTask} disabled={isLoading}>
  Add Task
</button>

• Pros: Zero Vercel function invocations (lower cost), lower latency (Client -> Supabase).
• Cons: Requires manual invalidateAll() to refresh data; no progressive enhancement.

My Questions

1. Is Approach 2 (Client-Side) considered a valid "best practice" in the SvelteKit ecosystem specifically to optimize for serverless costs, or is bypassing Form Actions discouraged for other reasons?

2. Does using invalidateAll() in the client-side approach carry any significant performance penalties compared to the automatic revalidation that happens with Form Actions?

3. Are there edge cases (outside of progressive enhancement) where the Client-Side SDK approach fails in production?

Thanks for the help!

[T1xx1]

You should not use invalidateAll because it will re-run everything the page gets including data from +hooks.server.* and +layout.server.*, which can be rough. https://svelte.dev/docs/kit/$app-navigation#invalidateAll
I have never tried measuring the performance impact of it with "normal" data refresh, but it should be used only to wipe all data, like after a login/logout.
If you think about it, if your page gets some data from hooks, layout and server load, calling invalidateAll because you don't want to run 1 function for the Supabase insertion will actually run 3 functions instead, to fetch all the data again.

Calling databases from the server is safer, even if it's Supabase, even if you have strong RLS policies.
It's not something SvelteKit-related, but a general web approach for safety. Clients should not have access to database connections.

You should really use remote functions, run the Supabase insertion on the server side and handle optimistic updates on the client, so it's not necessary to refresh the page.
https://svelte.dev/docs/kit/remote-functions

[d1d4r]

yeah, you're right calling database from server is better, but supabase provide client SDK that give you power to call supabase query from component itself, and they said it's safe

and when i use sdk in form action i add extra hop ( browser -> vercel (function) -> supabase )
while i can do this ( browser -> supabase )

i have not seen anybody call supabse from component everyone use form action even supabase docs

but i think it's extra cost because each function invocation increase cost and add some delays

[david-plugge]

It is safe because you do not open an actual DB connection. Supabase exposes an http API for its SDK and it's made for exactly that use case.

So it just comes down to the actual numbers, which I can't provide myself. Do you expect a lot of traffic? Do you need progressive enhancement? If not, you can reduce development time by not having to create a wrapper around the API calls (server actions are essentially that from a coding perspective).

I'd suggest to do both. Go with the direct API calls in by default and use form actions in very critical places like login. Try to get the numbers yourself.

[d1d4r]

yeah, under the hood the SDK just call API endpoint, the SDK is just provide wrapper for better DX,

and i'm planned use form actions for auth operation, and other CRUD i will use SDK directly in component

the traffic will be small because it's just an internal dashboard

but still i'm not sure because as i said everyone use form action i see many github repo and supabase examples

[david-plugge]

Ah so honestly I would just disable SSR altogether for an internal dashboard. Makes things way simpler and you can even use the static adapter.

[d1d4r]

then what would be the benefit of using createServerClient @supabase/ssr
https://supabase.com/docs/guides/auth/server-side/creating-a-client

and how can i use hooks.server.ts and auth !?

hooks.server.ts will run at runtime.