Where does your data actually live?

The browser's box is tiny.5 MB

About five megabytes in total, for everything. Two AI-generated images and it is full.

It sits on one machine.1 browser

The box belongs to one browser on one computer. Open the app anywhere else and there is simply nothing there. No sync, no copy, no way out.

And it can vanish.0 backups

Clear your browsing data and your chats are swept out along with the cookies. There is nowhere else they exist.

The client

The app in your browser. It draws what you see and holds a temporary working copy of your data, like papers spread out on a desk.

The app server

A small middleman program on the internet. It does the things a browser must never do itself, like holding secret keys.

The database

The permanent record. Organized, searchable, and strict about its rules. Ours is Postgres, a thirty-year-old classic, rented by the month from a service called Supabase along with the shelf next door and a login desk.

The file storage

A shelf next door for big files, like images. A database is great at small structured facts and bad at big blobs, so the files sit on the shelf and the database keeps a note of where they are.

It is just tables and rows.

Each spreadsheet is a table. Each line in it is a row. The chat app has exactly two: one row per conversation, and one row per message.

One column does the joining.

Every message carries the id of the conversation it belongs to. That belongs-to column is the relation, and it is the thing that puts the relational in relational database.

Toss the folder, the pages go too.

Relations can carry rules. This app has one: delete a conversation and its messages are deleted with it, without anybody remembering to clean up. The machine ahead is a real Postgres running inside this page, so press its buttons and watch it happen.

You hit send.

You type a message and press send. Nothing has left your machine yet.

The screen updates first.

The client puts the message on screen immediately. The working copy changes before anything is saved, which is the whole reason the app feels instant.

The row rides over.

A moment later the client sends the new data across the wire: insert this message into the messages table.

The database writes it down.

Postgres checks its rules first. Is this user allowed? Does this conversation exist? Only then does the row go to disk, and once it is on disk it stays there.

You log in somewhere new.

A different laptop, a phone, a machine you have never opened the app on. The screen starts empty, because nothing is stored here.

The client asks for your rows.

All conversations for this user, newest first, with their messages in order. One question, sent to the database.

The database sends them back.

It finds the matching rows and returns them. An index, which is basically a pre-sorted table of contents, keeps this fast even with thousands of rows to look through.

The list rebuilds itself.

The client lays the rows out and you get the exact same chat list you left on the other machine. Nothing was copied between the two. Both are just views of the same rows.

The front door checks your password.

Authentication happens at the login desk. Pass, and you are handed a signed pass card, a token, that quietly rides along with every request you make afterwards.

A second bouncer waits inside.

Row Level Security is its real name, and it stands inside the database itself. Every table can have a rule attached, and this app uses one: a user may only see and touch rows whose owner column matches their own id.

No way around it.

Even something wired straight to the database, skipping the app entirely, meets the same bouncer. That is exactly what the toggle ahead does: a bare select with no filter, and every row is still checked against the rule before it is handed over. Borrow a pass card and look.

The image never enters the database.

The server puts it on the storage shelf, next door rather than inside. A database is bad at big blobs and there is no reason to make it carry one.

Only its address goes in the row.

What goes into the message row is a short line of text: where on the shelf to find the picture. The row stays skinny, and the table stays fast.

A ticket lets you look, for a while.

The shelf is private, so the client asks for a signed URL: a temporary link that works like a coat-check ticket. Anyone holding it can view that one image until it expires, and nobody, ticket or not, gets to browse the shelf. The booth ahead hands out fifteen-second ones so you can watch a ticket lapse; the genuine article usually lasts an hour.