supabase Software Engineer Interview: Questions, Experience & Prep (2026)

Supabase is an open-source Firebase alternative built entirely on PostgreSQL. As of mid-2026, Supabase has 52 open Software Engineer roles tracked by knok. The company is fully remote, hires globally, and has a meaningful number of Indian engineers on the team.

Candidates report a process that typically spans 3-4 rounds: a recruiter or hiring manager screen, one or two technical rounds covering coding and system design, and a final values conversation with a senior engineer. Some roles include an async take-home task. All rounds happen over video call given the distributed team structure.

The interview bar is high and PostgreSQL is central to almost every technical conversation. Supabase also cares deeply about open-source mindset and async-first communication, since the entire team works across time zones without requiring real-time coordination for most decisions.

These questions come up repeatedly, based on what candidates report and the nature of Supabase's product:

1. How does Row Level Security (RLS) work in PostgreSQL, and when would you use it instead of application-level permission checks?
2. Walk us through how you would design a multi-tenant database schema on PostgreSQL for a B2B SaaS product.
3. Supabase Realtime is built on PostgreSQL logical replication. How would you debug a situation where realtime events are delayed or missing for some users?
4. How would you optimise a slow Postgres query that is causing timeouts in a high-traffic production environment?
5. How do Supabase Edge Functions differ from traditional serverless functions, and when would you choose one over the other?
6. Tell us about an open-source project you have contributed to. What was the most technically complex change you made?
7. How would you handle a breaking schema migration with zero downtime for a product with thousands of active users?
8. Supabase Storage uses S3-compatible object storage. How would you design secure, per-user file access controls on top of it?
9. Describe your approach to writing and maintaining end-to-end tests for a backend system that depends on a live database and third-party APIs.
10. How do you decide what to build versus what to pull in from an existing library when adding a new feature?
11. Walk us through a time you disagreed with a technical decision made by your team. How did you approach the disagreement?
12. Supabase is async-first and fully remote. How do you make your work visible so teammates can continue it without needing a call?

Q: How would you optimise a slow Postgres query that is causing timeouts in a high-traffic production environment?

*Situation:* At a previous company, a dashboard endpoint started timing out during peak hours after the user base grew past a certain size. The query joined three large tables and was running far slower than it had during early testing.

*Task:* I needed to find the root cause and fix it without taking down the service or running risky migrations on live production data.

*Action:* I ran EXPLAIN ANALYZE on the query and found it was doing a sequential scan on a table with millions of rows. The problem was that the WHERE clause applied a function on the indexed column, which prevented index use. I rewrote the query to avoid the function call on the indexed column, added a partial index for the most common filter values, and wrapped the schema change in a transaction so it could be rolled back if anything went wrong. I also enabled pg_stat_statements monitoring to catch similar regressions early.

*Result:* The dashboard endpoint stopped timing out during peak load. The monitoring change caught two similar issues in the following quarter before they reached users.

---

Q: Tell us about an open-source project you have contributed to. What was the most technically complex change you made?

*Situation:* I was using a popular Go HTTP client library in a side project and found it had no built-in support for automatic retry with exponential backoff on transient errors.

*Task:* I wanted to add this feature in a way that matched the library's existing API style and came with proper test coverage, not just a quick hack for my own use.

*Action:* I opened a GitHub issue to align with the maintainers on the approach before writing any code. Once the design was agreed, I implemented the retry logic with configurable jitter, wrote unit tests covering edge cases like context cancellation and non-retryable status codes, and updated the README with examples. I addressed two rounds of review feedback, mostly around making the backoff strategy pluggable rather than hardcoded.

*Result:* The PR was merged within three weeks. The maintainer highlighted it in the release notes, and community comments confirmed it was being actively used by others with the same need.

---

Q: Describe a time you disagreed with a technical decision made by your team.

*Situation:* My team planned to store user session tokens in Redis with no encryption at rest. The reasoning was that it was fast to implement and 'good enough for now.'

*Task:* I believed this was a meaningful security risk, but I also did not want to create friction by raising it in a way that felt like a public challenge to the lead engineer.

*Action:* Instead of objecting in the next standup, I wrote a short internal doc outlining the threat model, the low cost of adding encryption, and two concrete alternatives. I shared it in our engineering channel with the framing: 'here is something I want to make sure we have considered before we ship this.' I asked for feedback rather than demanding a change.

*Result:* The team agreed to add encryption at rest before the feature went live. The lead later thanked me for raising it the way I did, and we added a security checklist to our design doc template to catch similar gaps in future work.

STAR (Situation, Task, Action, Result) works for any behavioural question. Keep Situation and Task brief (two or three sentences each) and spend the most time on Action, because that is where interviewers learn how you actually think. Always close with a concrete Result, even a qualitative one. Stopping at what you did is one of the most common interview mistakes.

Depth-first technical answers work well for Supabase's product-knowledge questions. Start with the simplest correct answer, then layer in complexity. For a question about RLS, begin with what it does in one sentence, then explain the mechanism (policies attached to tables, evaluated per row by the Postgres engine), then discuss trade-offs and failure modes. This shows both breadth and depth without rambling.

Trade-off framing is important for system design. Supabase engineers work on a product with a large surface area and make product-aware decisions, not just implementation decisions. For any design question, use this structure: 'Given constraint X, I would choose Y because Z, though the cost is W.' A list of technologies with no reasoning is a weak answer at Supabase.

Supabase is a product-driven, open-source company and their interview bar for Software Engineers reflects this. Candidates report that interviewers focus on four things most consistently.

Deep PostgreSQL fluency. Supabase is built on Postgres. Interviewers want to see that you understand not just how to write SQL but how Postgres actually works: query planning, indexing strategies, RLS policies, logical replication, and MVCC. Surface-level SQL knowledge will not get you through the technical round.

Open-source mindset. Supabase's entire product is open-source. They look for engineers who read other people's code comfortably, write clear commit messages, and communicate technical decisions in writing through PRs, issues, and docs rather than relying on in-person meetings or real-time calls for every decision.

Async-first communication. The team is fully distributed. Interviewers pay close attention to how you describe past collaboration. If your best work always happened in real-time meetings or at a whiteboard, that is a mismatch signal. Frame your stories around written proposals, async code reviews, and thorough documentation.

Ownership and product sense. Supabase is a small, high-velocity team. They want engineers who think about what users need, not just what the ticket says. Expect questions about trade-offs, prioritisation, and situations where you pushed back on scope or improved the user experience without being explicitly asked.

Week 1: PostgreSQL deep dive. Work through PostgreSQL documentation sections on indexing, RLS, and logical replication. Run EXPLAIN ANALYZE on slow queries in a local Supabase project. Build something small (a notes app, a chat system) using Supabase's JavaScript or Python client so you understand the developer experience from the user's perspective.

Week 2: Supabase internals and open-source reading. Browse Supabase's public GitHub repositories, especially the core supabase/supabase repo and supabase/realtime. Understand how Realtime works: Phoenix channels over WebSockets, driven by Postgres logical replication. Read recent issues and merged PRs to see what kinds of problems the team is actively solving and how they discuss decisions in writing.

Week 3: Behavioural prep and async communication practice. Write out 6-8 STAR stories covering a hard technical problem you solved, a disagreement with a teammate, a time you improved developer experience, and a time you shipped something under pressure. Practice writing these as internal docs rather than bullet points, because Supabase will notice how you communicate in writing.

Week 4: Mock rounds and take-home practice. Candidates report that Supabase sometimes gives an async take-home task. Practice completing small coding tasks with well-written READMEs and tests, as if a stranger needs to review your work without a call. Do at least two mock system design sessions focused on multi-tenant SaaS architecture on Postgres.

If you are applying to multiple companies at the same time, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR on your behalf, so you do not miss Supabase or similar openings while you are deep in interview prep.

Treating SQL as a commodity skill. Many candidates assume that knowing basic SQL is enough for a Postgres-heavy company like Supabase. Interviewers will probe for query plan understanding, index design, and RLS. If you cannot explain why a query is doing a sequential scan, you will likely not pass the technical round.

Ignoring the open-source angle. Candidates who have no open-source contributions and cannot speak to reading and navigating large external codebases are at a disadvantage. Even small contributions (documentation fixes, bug reports with reproductions, minor code changes) signal the right mindset.

Defaulting to sync communication in your stories. Supabase is async-first. Saying things like 'I prefer to just jump on a call' or describing your best work as happening in in-person whiteboard sessions sends the wrong signal. Frame your examples around written proposals, async reviews, and thorough documentation.

Giving vague answers to trade-off questions. If you are asked 'how would you build X,' a list of technologies with no reasoning is a weak answer. Always say what you would NOT do and why. Supabase engineers make product decisions, not just implementation decisions.

Skipping the Result in STAR answers. Many candidates give strong Situation and Action sections but forget to describe the outcome. Even a qualitative result ('the team shipped with no rollbacks' or 'the feature became the most-used that quarter') is far better than stopping at what you did.