What to Expect in the Supabase System Design Interview

Expect developer platform problems built around Postgres: multi tenant hosting, realtime updates, permissions, and connection limits. Multi tenant means one system serving many isolated customers. Supabase gives every project a real Postgres database, then adds login handling, file storage, and realtime updates on top. Design questions follow the product, so they test whether you can build platform pieces like these. Deep Postgres knowledge counts more here than at most companies.

Quick Overview

Terms You Must Use Correctly

• Postgres: an open source relational database, the foundation of the whole platform.
• Write ahead log (WAL): the ordered record of every change a database makes, written before the change applies.
• Logical replication: the database streaming its changes to another service in a readable format.
• Row level security: rules inside the database that decide which rows each user can read or write.
• Connection pooling: sharing a small set of database connections among many clients, because each Postgres connection is expensive.
• Websocket: a long lived connection that lets a server push messages to a client.

Define each term when you first use it in the interview. That keeps the discussion precise and shows the vocabulary is yours.

A Worked Example: Design a Realtime Change Feed on Postgres

Requirements. Clients subscribe to changes in their tables. Changes must arrive within about one second. Support thousands of subscribers per project, and never show a user rows they cannot read. Confirm these numbers with the interviewer before designing.

Reading changes. Use logical replication: a realtime service subscribes to the WAL and receives every committed change in order. This avoids polling the tables, which would add load and delay.

Fan out. The realtime service delivers each change to every matching subscriber. Fan out means delivering one message to many receivers. Subscribers hold websocket connections to the service, grouped by project.

Authorization. Apply row level security before delivery, not after. Evaluate the subscriber's read rules against each change, and drop rows they cannot read. Security filtering at the edge of delivery is the part interviewers probe hardest.

Scale and recovery. Partition subscribers across realtime servers by project. Track the WAL position as a checkpoint, meaning a saved marker of progress. A restarted server resumes from its checkpoint and loses nothing. For slow clients, set buffer limits and disconnect clients that cannot keep pace, telling them to reconnect and resync.

Ordering. Deliver changes for one table in commit order. Commit order is the order in which the database made the changes final. Ordering across tables costs more, so offer it only per subscription and say why.

What Interviewers Evaluate

Platform thinking comes first: many tenants, strict isolation, and predictable cost. Security comes second, and it must appear in your design before anyone asks. Third comes honesty about trade offs, such as delivery delay against database load. Clear reasoning on a small design beats a large diagram of components. Estimate numbers early: changes per second, subscribers per project, and bytes per message.

How to Prepare

• Learn the building blocks. Replication, partitioning, caching, and queues appear in every question above. Grokking the System Design Interview teaches them with worked problems.
• Study reusable patterns. System Design Patterns covers the pub sub and replication patterns behind realtime systems. Pub sub means publishers send messages that many subscribers receive.
• Rebuild the example yourself. Design the change feed on paper without notes, then compare it against this outline.
• Prepare the rest of the process. The stages are in What is the Supabase interview process like? Behavioral themes are in Top Supabase behavioral interview questions. The motivation question is in How to answer "Why do you want to work at Supabase?"