Tissue vs Supabase
Supabase is the back of the house. Tissue is the back of the house and the front. That is most of the difference; the rest is Postgres against SQLite.
If your application is fundamentally a Postgres application — extensions, row-level security, realtime subscriptions, a table editor your colleagues actually open — Supabase is built around exactly that and we are not.
Two things bring people across. Supabase does not host your website, so there is a second deploy and a second bill somewhere else; and a free project is paused after a week of inactivity, with a limit of two active ones. On tissue the site, the code and the data are one deploy, and a quiet project stays up.
What each one is
Two sentences each, before any numbers.
- Supabase
- A hosted Postgres database with a generated REST and realtime API over it, plus authentication, file storage and edge functions. You get a project, a dashboard and a connection string; the website that uses them lives on another host.
- Tissue
- One Cell — a JavaScript or WebAssembly function answering on a URL — with a SQL database, object storage, scheduled runs, sign-in and secrets attached to it by name in
ribo.toml.ribo deployputs the code, the static files and every attachment live in one step.
Side by side
Every figure below came off the other company’s own pages, on one day, and is dated underneath.
| Supabase | Tissue | |
|---|---|---|
| Free plan | $0. 500 MB of database on shared CPU, 1 GB of file storage, 5 GB of egress, 50,000 monthly active users, 500,000 function invocations. Projects are paused after a week of inactivity, and you may have two active at once. | $0, no card. 5 Cells, 1 GiB of database, 5 GiB of file storage, 2,000,000 CPU-milliseconds a month. Nothing pauses, and there is no active-project limit. |
| Entry paid plan | Pro, $25 a month, including $10 of compute credit — enough for one Micro instance. The next size up is $15 a month on top of the plan. | Strand, $5 a month. There is no instance under it. |
| What is metered | Database size, file storage, egress, monthly active users, function invocations, realtime messages, and the compute instance the project runs on. | CPU-milliseconds and gigabytes stored. |
| Database | Postgres. 8 GB of disk included on Pro, then $0.125 per GB. | c3, SQL over SQLite. 5 GiB on Strand, then $0.50 per GiB-month. |
| Vector search | pgvector, an extension you enable on the project. | Built into c3: an F32_BLOB column, cosine or L2 distance, and an approximate-nearest-neighbour index. |
| File storage | 100 GB on Pro, then $0.0213 per GB. | g7. 20 GiB on Strand, then $0.015 per GiB-month. |
| Egress | 250 GB on Pro, then $0.09 per GB. | Free and not metered. |
| Sign-in for your users | A full authentication product: many providers, 100,000 monthly active users on Pro, then $0.00325 each. | gate: an email domain or a list of addresses. Nobody is counted. |
| Hosting the website | Not included. The site goes on another host, with its own deploy and its own bill. | Included. Everything under public/ is served at the root of the same deploy. |
| Scheduled jobs | Through a Postgres extension, inside the database. | pulse, a cron line in the config. 3 schedules free, 10 on Strand. |
Checked 16 September 2026 against Supabase's own pricing page. Both of us move; if a figure here has gone stale, tell us and we will correct it.
Where Supabase is the better choice
This section is not decorative.
Postgres is the reason. Extensions, JSON that behaves, row-level security as a policy language, listen/notify, and a planner that has seen everything. c3 is SQLite: small, fast, enough for most sites, and not Postgres.
Their authentication is a product; ours is a door. Supabase does social providers, magic links, multi-factor and per-row authorization tied to the signed-in user. gate decides whether somebody gets in at all. If you need accounts with profiles and permissions, you would be writing that yourself here.
Realtime. Subscribing a browser to a table's changes is one line there. Cells hold no long-lived connections, so that pattern has no equivalent here.
The dashboard. A table editor, a SQL editor, logs and a schema view that somebody who does not deploy can be pointed at.
Where tissue is the better choice
The site and the database in one deploy. No second host, no CORS between your front end and your data, no second renewal date.
A quiet project stays up. Nothing is paused after a week, and there is no ceiling of two.
No instance underneath. Supabase's paid price starts with a machine you rent whether or not anybody visits; ours starts at the CPU you actually spent.
Egress is free. 250 GB is plenty until the week it is not, and after that it is nine cents a gigabyte.
What moving looks like
The front end and the queries move into the same Cell: the pages come across as static files, and the calls that went over the network to a project somewhere else become env.DB.
[cell] name = "app" js = "./cell.js" [[bindings]] type = "files" binding = "FILES" dir = "public" [[bindings]] type = "c3" binding = "DB" database = "app"
$ ribo deploy uploading cell.js publishing ./public attaching c3 live https://app.quartz-4b.tissue.dev
The database and the bucket are created on that first deploy if they are not there yet. ribo deploy is the whole pipeline: there is no build step to configure and no second place to put the static files.
Spore is $0, takes no card, and allows commercial use. If tissue turns out to be the wrong shape for what you are building, you will know inside an afternoon.