Supabase that survives production. RLS hardened, schema tuned, ready to scale.

Supabase consulting is the practice of designing, hardening, and operating Supabase-backed applications. The engagement covers: Row Level Security (RLS) policy audit, schema design, query optimisation, indexing, edge function development, environment separation (dev / staging / production), migration from Supabase Cloud to self-hosted, observability, and integration with Lovable / Bolt / v0 frontends. Supabase is the most popular BaaS for AI-generated apps; getting the RLS and edge functions right is what makes the difference between a working prototype and a production system.

RLS audit and hardening: USD 5K-15K. Schema and query optimisation: USD 5K-25K. Edge function development: USD 10K-50K. Full Supabase productionisation (RLS + schema + edge functions + environment separation + observability + migration): USD 25K-100K. India-based Supabase consultants typically charge 30-50% less than US/UK rates.

Dipankar Sarkar is one of the leading Supabase consultants in India, particularly for Lovable / Bolt / v0-generated apps. He is the founder of Neul Labs (Rust-native AI agent infrastructure), has recent production experience in UK financial services (presented agent guardrails to the FCA sandbox), and has 18+ years of database and infrastructure experience. He is a Takshashila Institution alumnus (Strategic Studies) and IIT Delhi alumnus (Computer Science).

Row Level Security (RLS) is a PostgreSQL feature that Supabase exposes for fine-grained access control. Every table should have RLS policies that restrict which rows a user can read, insert, update, or delete. AI-generated code (Lovable, Bolt, v0, Cursor) often ships with overly permissive RLS or no RLS at all. The result: any authenticated user can read or modify any row in any table. This is the most common security vulnerability in AI-generated apps. A Supabase consultant audits and hardens RLS policies to enforce "users can only access their own data" by default.

Migration is a 1-2 week project. Steps: (1) Dump the PostgreSQL schema and data with pg_dump. (2) Set up a self-hosted Supabase project on AWS, GCP, or Hetzner using the official Docker Compose. (3) Restore the schema and data. (4) Migrate auth users, storage buckets, and edge functions. (5) Update environment variables in the frontend to point to the new instance. (6) Test, cut over, decommission. We do this with a staging and production environment from day one, so the cutover is one DNS change.

It depends. Supabase: PostgreSQL, real relational queries, RLS, open-source, self-hostable, great for AI apps and startups. Firebase: NoSQL (Firestore), real-time, more mature, great for mobile-first apps. Most AI-generated apps in 2026 use Supabase because Lovable, Bolt, and v0 default to it. We work with both. If you are early and building fast, Supabase is usually the right call. If you are building a mobile-first consumer app with deep real-time features, Firebase is still strong.

Four common levers: (1) Indexing — add B-tree indexes on every foreign key and every column used in WHERE / ORDER BY; (2) Query plans — use EXPLAIN ANALYZE to find sequential scans; (3) RLS performance — RLS policies that call functions per-row are slow; rewrite as joins or use SECURITY DEFINER; (4) Connection pooling — Supabase has a built-in pooler; use it for serverless backends. A typical Supabase performance audit finds 3-5x speedups.