This is definitely a weird one. I tried loggin into my supabase account but it doesnt work anymore. Removed all session data, used incognito mode, and different browsers...
I basically cant use supabase right now. Wtf...
Do you guys have the same issue right now?
How are you guys handling infrastructure as code with Supabase? We could use config.toml, but it seems like that file only works for one Supabase instance since the project_id field selects on Supabase project.
We would like to handle both a staging and a production environment of Supabase.
Config as code with config.toml seems to work nicely when using Supabase branching, but does not seem to be so simple when having multiple projects.
We are considering using Pulumi for IaC.
We just saw a massive outage with Railway yesterday and a lot of folk in the thread were talking about off-site backups.
How are you doing backups?
I know that Supabase keep backups but how is everyone handling getting backups saved elsewhere?
Olá pessoal. Espero que estejam bem!
Vim aqui pedir uma pequena ajuda. Tenho um agente no n8n que realiza buscas em um banco de dados vetorial, e esse banco de dados é relativamente grande. Extraio os manuais de todas as empresas e os transformo em vetores 3072.
No entanto, as respostas que a IA me dá não são precisas. Às vezes, a IA inventa informações, às vezes fornece partes corretas, e às vezes diz que não encontrou a informação. Mas se eu informar que a informação está errada, ela retorna ao banco de dados vetorial e retorna a informação correta.
Já configurei os parâmetros:
TOP N (Coerência do Reclassificador) = 5 TOP K = 20,0 TOP P = 0,7 Temperatura de Amostragem = 0,1 Limite (Recuperação da Supabase) = 20
Já tentei várias alterações nessas configurações, mas sem sucesso...
O que vocês devem me dizer?
im seeing for a solution for this problem that i don't know how to fix it since in just 7 days it used 27% of it and im the only one using it while testing,
Im Building an App of chatbots where the messages are in a local database on the user device, when a user create a chatbot it saves it in the supabase database that is PostGreSQL with Prisma ORM, and when someone else want to chat with it, it downloads it that is the only Egress since i have the sync to the database for the messages but i turn it off and i didn't used any other device for import the sync, the sync is in a bucket and the messages are compressed with Brotli at maximum, the Supabase database is connected with the website on Vercel (the sync don't go trough Vercel but directly to the Database), what i have to still optimize it or fix this problem?
I looked at everything and i don't know what it could be the problem since it's my first time using Supabase too.
I have 2 Vercel + Supabase projects. Let's call them Project A and B. Project A already exists and will be used as the IdM. That is, Project B will authenticate against Project A*. I'm currently designing Project B. Project B will also need to access certain tables in Project A. Exact tables are TBD. AFAIK, the 2 primary ways to accomplish this are:
There are, of course, other options like syncing the required Project A tables to Project B, but aside from the latency issues, that doesn't seem very robust.
I'd be interested in any other experiences and/or recommendations on best practices here.
*I'd actually like to use a 3rd-party IdM like Auth0 or Keycloak, but I haven't gotten that past the team yet.
I have two completely separate Supabase accounts, X and Y. I want to move a project from account X to account Y with everything included database, Edge Functions, Row Level Security (RLS) policies, Storage buckets, Auth settings, and any other configuration.
After the migration, I want the project in account Y to be fully independent and no longer linked to account X in any way.
What is the best and safest way to do this?
After spending many hours setting up my project in Supabase, I'm disappointed to find out there's no way to monitor my Supabase.com account's login history unless I pay for a $599/month team plan.
This is essential functionality for security, and by charging a premium for it, they're driving away small businesses and individuals who might grow to be higher paying customers later. Is there a way around this limitation?
I have a groups table with a parent_id column so I can have records like 1. Colors, 2. Red and 3. Blue (Red and Blue have a parent_id of 1 linking to Colors).
Querying the Colors record and joining the same table will return Colors with its children (Red and Blue).
.select(“*, groups!parent_id(*)”)
How do I query Red so it retrieves Red with its parent Colors?
Thanks
I have a trigger that runs after I delete a row in a certain table, the trigger's work is it delete the file related to that deleted row in my Storage but this never worked, what do you suggest ??
Hey everyone,
I’ve been using Supabase a ton lately for our projects, and while I absolutely love the ecosystem, I noticed our team was writing the exact same boilerplate code over and over just to handle simple data fetching, updates, and deletes.
Typing out .from('table').select('*').eq('id', id) across dozens of components started to feel heavily repetitive.
To clean up our codebase and speed up our workflow, we built a lightweight, zero-boilerplate wrapper called @/keylabsdev/superbase. It initializes just like the native client but exposes a super clean, fluent syntax that implicitly handles the structural boilerplate for you.
Here is a quick look at the syntax difference:
// ❌ The Repetitive Way
const { data, error } = await supabase
.from('tasks')
.select('*')
.eq('status', 'done')
.limit(5);
// The Superbase Way
const data = await db.from('tasks').eq('status', 'done').limit(5);
What it does:
.from('table') automatically defaults to selecting all columns (*) so you can jump straight into filtering. You can still pass custom columns as a second argument if needed (db.from('tasks', 'id, title'))..eq(), .gt(), .ilike(), .order(), etc.).await db.update('tasks', { status: 'done' }).eq('id', 5);It’s completely open-source and free to use. If you want to check it out, grab the code, or drop some feedback, you can find it here:
👉 NPM: npm install @/keylabsdev/superbase
👉 GitHub: https://github.com/KeyLab-Git/keylabs-superbase
Would love to know if anyone else runs into this syntax fatigue, and what other shorthand methods you’d want to see added to it!
A couple weeks ago I posted here offering free backend reviews of production Supabase projects. The response was awesome and thanks to everyone who reached out.
I just published the first review: https://youtu.be/2nHjr3hymyw
In this one I go through a real production database and walk through everything I found: missing indexes, RLS gaps, schema issues, query performance, the works. No fluff, just the actual findings and why they matter.
I'm still doing these. If you have a production Supabase project and want a free backend review, DM me. Same deal as before — the review gets filmed for YouTube, but you choose whether I shout out your app or keep everything anonymous. No real user data gets shown either way.
Only thing I ask is that it's a real project with real traffic so that we can have different app sizes in the showcases of the series.
Hi devs. I built a booking platform as a single HTML file (~9700 lines) with Firebase. Works fine solo. Breaks when 2-3 users use it at the same time (data resurrects after deletion, browsers overwrite each other's data, sync is unreliable).🤷
Goal: 30 user A, 30 user B, 100 daily guest signups, with smooth real-time sync.
Tried migrating to Supabase via AI assistance. Got it partially working but broke the login system trying to fix concurrency bugs. Code is now too tangled to debug through chat.
Stack: HTML/CSS/vanilla JS, Firebase RTDB, Netlify, GitHub
Questions:
Worth rescuing the existing code or rebuild?
If rebuild — what stack? (Next.js + Supabase? No-code like Bubble?) i still want to learn this 👍😩🙏 Thanks
migrating off airtable into postgres sounds like it should be a solved problem by now. it really isn't, and the reasons why are more interesting than i expected when i started.
the trap most people fall into:
first instinct is usually csv export. doesn't work. linked records come out as comma-separated record ids text, not relationships. you've moved data, not structure.
second instinct is a python script against the airtable api. this gets you about 60% of the way and then collapses under its own weight. you end up having to:
why sync tools aren't actually a migration
whalesync and sequin both work and i don't want to take anything away from them they're solid at what they do. but the thing that took me a while to internalize is that they sync computed values, not the logic that produced them. so postgres ends up holding a number that airtable calculated. modify a linked record on the postgres side and nothing recalculates. only airtable still knows the formula. the new value syncs back over from airtable.
practical implication: you can't actually cancel airtable. you're locked into paying for it forever, or your "migrated" data goes stale the moment it changes.
the post-migration problem that surprised me
once everything lands in postgres with proper junction tables and foreign keys, the schema is correct but the experience of working with it is much worse than airtable. one airtable row that showed you names, computed totals, and linked record titles becomes a 3-4 table join in sql. correct, but you've lost the at-a-glance view your team has been using for years.
what worked for me: generating a layer of postgres views during the migration that recompose the table back into something readable. linked record names appear inline, rollups show as computed columns, lookups resolve. the underlying schema stays normalized, the views just give you a familiar way to look at it.
formulas were the biggest time sink
airtable's formula language isn't sql and has enough quirks that direct translation isn't always possible. i kept grinding on it and got to roughly 80% coverage on the common patterns text functions, date arithmetic, math, logical operators, most if/switch logic, the typical record-level stuff. these map cleanly to postgres expressions or generated columns. the last 20% is genuinely airtable-specific behavior that needs a human call. but 80% means you're reviewing and editing, not rewriting.
what i'm building
atmigrator handles this end-to-end as a one-shot migration. formulas and rollups become real postgres logic. linked records become proper foreign keys with junction tables where needed. attachments get pulled and rehosted before urls expire. views get generated on top so the destination doesn't feel alien.
anyone who's migrated off airtable into supabase or any postgres host, how did you handle the formula side specifically? rewrite by hand, accept static values from sync, or something else? trying to understand what people actually need.
Anything wrong with putting the OTP code in the subject line, as well as the email body?
This will prevent emails from threading and in general, allow the user to fetch the code faster. By default, it's just in the body.
Am I missing anything?
The RPC validates the visitor ID, upserts last_seen_at, and returns the active count in one call. Table access is fully locked down - anon can only execute the function, nothing else.
Full writeup + live demo: https://edvins.io/live-visitor-counter-nextjs-supabase
Hey r/AppBuilding
Real story, posting because it might save someone else a morning.
Solo on this project. Shipped a feature to staging last week, all green. Pushed to prod the next morning, broken. Turns out I'd added an RLS policy directly in the staging dashboard a week before, "just to test something," and never wrote it into my migration files. Local fine, prod fine, staging silently drifted. Three hours of "but it worked yesterday" before I found my own mess.
Third time this year I've done some version of this to myself. I asked around. Other solo Supabase devs keep running into two close relatives of the same problem:
create or replace from three months ago, so the body of the function has no audit trail.orders table actually look like right now?" Repo has 47 migrations mutating it. To know the current shape you basically have to mentally replay every one of them in order, and nothing in the repo just shows you the truth.Root cause is the same thing every time. Supabase migrations record changes, not current state. That's fine when I'm disciplined. Real life is me clicking around the dashboard at 2am, asking the AI to "fix this function," and forgetting to commit. The change lands in the DB. It never lands in the repo. Past me keeps sabotaging future me.
So I built SchemaLens for it. It's declarative.
schemalens pull introspects a live DB and writes every object (tables, views, functions, triggers, RLS, indexes, enums, extensions) to plain SQL files. One file per object. That's your current state.schemalens status shows drift between repo and any environment.schemalens diff dev prod compares two environments directly.schemalens deploy is dry-run by default, transactional, with a --block-destructive flag for CI.Runs alongside Supabase migrations. Not trying to replace them.
If any of those three pains sound familiar and you're on a real project, I'd love testers. Free tier covers everything you need for testing. I'm mostly hunting introspector bugs right now, especially around custom schemas, heavy RLS, pgvector, and any setup that's a bit weird. CLI feedback also welcome.
Comment or DM. And if you already solve this with something else, please tell me what. Half the reason I'm posting is to find out I built something that already exists.
Hello, I’ve had a Developer for some time now who is making my app with supabase, as I’m not a technical person, but I have a basic or very low level understanding of supabase. How can I audit his work and make sure everything is set up at least decently in the back end. Is there any way for me to know if the work hes done is good quality? He says its a commercial level app but I would love for me to be able to verify that while not being technical. How can I audit the backend and see if it’s done properly?
A while back someone from the Supabase team asked if we'd support custom SQL queries, just like the dashboard snippets. We listened.
You can now run your own SQL queries and see the results as widgets on your home screen. Track user signups, custom metrics, whatever matters to you.
Curious what queries you'd use it for?
every next.js + supabase tutorial on the internet teaches you createServerClient with manual cookie handling — cookies() from next, getAll() / setAll() wrapped in try/catch, the dance about server actions vs route handlers vs middleware.
supabase shipped @supabase/server in may as a universal server sdk. works in edge functions, vercel functions, deno, bun, cloudflare workers, all from one import. handles auth, client creation, cors, context injection. obsoletes most of @supabase/ssr.
deleted 240 lines of code yesterday. here's roughly what it looked like.
before (next.js app router, the canonical pattern)
// lib/supabase/server.ts
import { createServerClient } from '@supabase/ssr'
import { cookies } from 'next/headers'
export async function createClient() {
const cookieStore = await cookies()
return createServerClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
{
cookies: {
getAll() { return cookieStore.getAll() },
setAll(cookies) {
try {
cookies.forEach(({ name, value, options }) =>
cookieStore.set(name, value, options)
)
} catch {}
}
}
}
)
}
then a parallel version for middleware (different request object), a parallel version for route handlers (headers not cookies), and another for edge functions (Deno globals). four near-identical files.
after
import { createClient } from '@supabase/server'
const supabase = createClient()
same import works in middleware, route handlers, server components, server actions, edge functions, cloudflare workers. it figures out the runtime and reaches for the right cookie/header api.
the trade-off
it's new. @supabase/ssr has years of stackoverflow answers. when something breaks at 2am, ssr has more searchable error messages. server's documentation is good but the long tail of community knowledge isn't there yet.
i'd recommend it for new projects unconditionally. for existing projects, wait a month and see what stories come out, then migrate when there's a calm afternoon.
also worth noting
the same package handles supabase auth ssr correctly across all the platforms i tested. specifically: it manages the access token rotation that the various platforms handle differently. previously this was a bug magnet (every project had a slightly different stale-session bug).
anyone migrated a real app to it yet? curious if there are edge cases (heh) i should brace for.