0 Get started
Both are good, and they are built for different worlds. Supabase gives you a managed Postgres platform with a mature console and someone else on call for your database. Pithy gives you capabilities that compose into your own Worker, on your own Cloudflare account, with no service of ours in the path. The difference that decides it is not a feature. It is where your customers' data lives.
Choose Supabase if
Your application is relational at its core
and you want real Postgres — extensions, stored procedures, point-in-time recovery — behind a polished console, with support you can buy.
Choose Pithy if
You want to own the whole data plane
and run close to your users on Cloudflare — with payments, games, media and support already wired, and nothing of ours between you and your data.
Where they overlap
If a feature is standard for a modern backend, assume both have it. We are not going to dress one up as a differentiator.
Sessions, OAuth providers and API keys. Both cover it, and neither should claim it as a differentiator.
Signed URLs and per-object ownership. Pithy on R2, Supabase on S3-style buckets.
Embeddings and similarity search. Pithy on Vectorize, Supabase on pgvector.
Both can push to a connected client. What they push, and who writes the server, is not the same thing — see the table.
Both store secrets encrypted at rest — Supabase Vault in Postgres, Pithy in a dedicated D1. The difference is custody and rotation, and it is in the table below rather than here.
Read the code, run it yourself. Supabase is Apache-2.0, Pithy is MIT. Neither locks you in at the license level.
The difference underneath
Supabase runs the Postgres your customers' data lives in. That is the product, and it is a good one — someone else is on call for your database at three in the morning, and for most teams that is worth paying for.
It is also a database with an administrator: an instance to size, a pool to manage, upgrades to schedule, and compute billed while it idles. D1 has none of those, because it is not a container — it is a serverless database reached over a binding.
Pithy runs nothing. Every capability executes in your Worker, against your D1, KV and R2, in your Cloudflare account. There is no Pithy-operated service in any request path, because there is no Pithy-operated service. Even the dashboard reaches into your Worker with a key you registered and can revoke, rather than holding a copy of your data.
That is not a feature you can put a tick beside. It is the constraint every capability in the kit was designed under, and it decides what happens to your users on the day either company has a bad week.
Feature by feature
| Feature | Supabase | Pithy |
|---|---|---|
Runtime & data | ||
| Runtime Supabase: managed Postgres, regional Pithy: Cloudflare Workers, global | Yes | Yes |
| Pick a region Supabase: you choose, and latency follows from it Pithy: there is no region to pick | Yes | No |
| Full relational SQL Supabase: full Postgres Pithy: D1 is SQLite — lighter, and not Postgres | Yes | Partial |
| Analytical / event tables Coming soon Supabase: Postgres will do it until it will not | Partial | No |
| Durable multi-step workflows Pithy: Cloudflare Workflows are a first-class primitive | No | Yes |
| Subscribe to table changes, declaratively Supabase: Postgres logical replication streams row changes to clients with no server code Pithy: you would write the publish yourself | Yes | No |
| Authoritative server-held session state Pithy: a Durable Object holds what no client can be trusted with, and resolves it | No | Yes |
Database operations | ||
| No instance to size Supabase: compute tier per project, and you pick it Pithy: there is no instance | No | Yes |
| No connection pool to manage Supabase: a real constraint from serverless functions; Supavisor exists for this Pithy: D1 is reached over a binding, not a connection | No | Yes |
| No idle cost Supabase: compute is billed while the project is up, busy or not Pithy: nothing is billed for a database nobody queried | No | Yes |
| No upgrades or maintenance windows Supabase: Postgres major versions and restarts are yours to schedule Pithy: Cloudflare's to run | No | Yes |
| No vacuum, bloat or index maintenance Supabase: routine Postgres operations at scale Pithy: SQLite has none of it | No | Yes |
| Point-in-time recovery Supabase: an add-on at $100 a month per seven days of retention, billed outside the spend cap Pithy: D1 Time Travel: always on, no configuration, no extra charge — any minute in the last 30 days | Yes | Yes |
| Managed daily backups included Supabase: 7 days on Pro, 14 on Team, 30 on Enterprise Pithy: Time Travel is the mechanism; there is no separate backup product | Yes | Partial |
Identity | ||
| Sessions and OAuth | Yes | Yes |
| Passwordless by default Supabase: supported, but passwords are the default path Pithy: magic link and email OTP only; no passwords, ever | Partial | Yes |
| Mobile-first bearer tokens Pithy: rotated refresh tokens in secure device storage, PKCE and deep-link redirects | Partial | Yes |
| Device registration | No | Yes |
Language | ||
| Per-request locale negotiation Supabase: you write it, on both the server and the client Pithy: URL, the signed-in reader's account, a cookie and Accept-Language, in an order you configure | No | Yes |
| Translated catalogs shipped with the framework Pithy: Spanish today, updated with the package rather than copied into your repository | No | Yes |
| Override one sentence without forking a catalog Pithy: lookup walks layers per key, so everything you did not mention keeps arriving | No | Yes |
| Dates, numbers and currency from the same seam Pithy: the formatting locale does not fall back, so an es-AR reader gets Argentine numbers | No | Yes |
| Missing translations fail the build Pithy: a pithy doctor finding that names the locale and the keys | No | Yes |
| Errors carry a code a client can translate Supabase: Postgres and GoTrue errors arrive as English strings Pithy: the payload's message stays English and the code is the catalog key | No | Yes |
Money | ||
| Stripe | No | Yes |
| Paddle Pithy: merchant of record — they own the tax registration | No | Yes |
| Lemon Squeezy | No | Yes |
| Apple In-App Purchase | No | Yes |
| Google Play Billing | No | Yes |
| One entitlement across every rail Pithy: buy on iOS, be entitled on the web | No | Yes |
| Per-user balance ledger | No | Yes |
Content & media | ||
| Object storage with quotas | Yes | Yes |
| Resumable upload | Yes | Yes |
| Direct-to-bucket upload Pithy: bytes never proxy through your Worker | Yes | Yes |
| Image and video pipeline Supabase: image transformation; video is yours to solve Pithy: Cloudflare Images and Stream, chosen per media type in config | Partial | Yes |
| AI enrichment of uploads Pithy: on your own Workers AI binding | No | Yes |
| Vector search | Yes | Yes |
hyi187 | ||
| Authoritative sessions Pithy: Durable Objects hold what no client can be trusted with | No | Yes |
| Matchmaking Pithy: room codes, invites, friends and skill queues | No | Yes |
| Skill rating Pithy: Elo, Glicko-2 and TrueSkill built in | No | Yes |
| Leaderboards with closing windows | No | Yes |
| Play closed-test roster and its fourteen-day clock Pithy: the step between a finished Android build and production, which nothing else tracks | No | Yes |
Trust & compliance | ||
| Row-level security Supabase: enforced in the database Pithy: authorization is per route in your Worker, not per row in the database | Yes | Partial |
| Audit trail Supabase: Postgres logs and extensions, assembled by you Pithy: a queryable trail attributed to the right actor, including the dashboard | Partial | Yes |
| Encrypted secret storage | Yes | Yes |
| Key custody Supabase: a per-project root key they create and manage, retrievable through their API Pithy: a worker-only master key, in a store separate from the app database | Partial | Yes |
| Automatic key rotation at rest Supabase: manual secret rotation is the documented practice Pithy: append, prove, then expire — a failed rotation leaves the old key working | Partial | Yes |
| Humanity check as middleware | No | Yes |
| Privacy classification of fields Coming soon | No | No |
| Field encryption at rest Coming soon | No | No |
Observability | ||
| Structured logging built into the framework Supabase: Postgres and function logs, in their own formats Pithy: one Logger seam; a log call is a record with queryable fields, not a line — and those fields are exactly what the query builder groups by | No | Yes |
| Context carried through background work Pithy: a Workflow's records carry the run, instance and environment without being passed by hand | No | Yes |
| A log explorer, with a query builder Supabase: queryable, and genuinely good Pithy: Cloudflare's Observability dashboard, writing to your own account — and its query builder groups and filters on any field you logged | Yes | Yes |
| Ship logs to your own sink Supabase: available on higher plans Pithy: Cloudflare Logpush, on your own account | Partial | Yes |
| An audit trail separate from logs Supabase: you would build it Pithy: durable, queryable rows attributed to an actor — including the dashboard | No | Yes |
| Invocation traces Pithy: Cloudflare groups every log from one trigger into a single invocation | No | Yes |
Development & environments | ||
| A local stack you can run Supabase: the full Supabase stack, locally Pithy: Miniflare, the same runtime your Worker deploys to | Yes | Yes |
| Local development without Docker Supabase: a Docker-compatible runtime is required Pithy: no containers; pithy dev is the whole dependency | No | Yes |
| Migrations and seed data Supabase: seed.sql runs on start and on db reset Pithy: pithy migrate and pithy seed, per environment | Yes | Yes |
| A preview environment per branch Supabase: Branching, on Pro and above Pithy: pithy feature create, then pithy provision --feature | Yes | Yes |
| Included rather than a paid add-on Supabase: Branching needs Pro or above, and a preview branch bills by the hour on top of the plan Pithy: the CLI is free; you pay Cloudflare for the resources the branch actually uses, at the same rates as anything else | No | Yes |
| Every resource cloned, not only the database Supabase: a preview branch is a Supabase project — the database and its configuration Pithy: its own D1, KV, R2 and its own secrets master key, named from the branch | Partial | Yes |
| An isolated worktree with pinned ports Pithy: several features run at once; each gets its own port block, assigned once and never probed | No | Yes |
| Teardown that cannot strand a resource Supabase: branches are deleted through the platform Pithy: names are recomputed from the branch, so a half-finished run still cleans up | Partial | Yes |
Operations & DX | ||
| CLI scaffolding and migrations | Yes | Yes |
| Front end scaffolded into the backend Pithy: one command, one origin, one deploy — with sign-in and paywall screens | No | Yes |
| Support inbox | No | Yes |
| Play closed-test tracking | No | Yes |
| Management dashboard Supabase: their console, holding your data Pithy: reaches into your Worker with a key you can revoke | Yes | Yes |
| A polished platform console Supabase: years of polish, a table editor, a SQL editor and a good log explorer Pithy: Cloudflare's own, and it is very good — the console the account already uses for Workers, D1, R2 and the logs | Yes | Yes |
| Panes for users, money and the trail Supabase: an auth user list and a table editor over the rows; entitlements, purchases and a trail are yours to model Pithy: users, entitlements, purchases, subscriptions, support and the trail — and a user can be comped, revoked or signed out everywhere | Partial | Yes |
Ownership | ||
| No charges for egress Supabase: bandwidth is metered and billed above the plan's allowance Pithy: Cloudflare charges nothing for egress, on Workers or on R2 | No | Yes |
| Your data stays in your account Supabase: self-host, or their cloud holds it Pithy: there is no other option; we operate nothing | Partial | Yes |
| Self-hostable | Yes | Yes |
| Open-source license Supabase: Apache-2.0 Pithy: MIT | Yes | Yes |
| No vendor in the request path Supabase: their platform, unless you self-host Pithy: nothing of ours sits between your app and its data | Partial | Yes |
The saffron tick marks where Pithy leads — not that the other column is absent. Every claim about Supabase was checked against their own documentation on 2026-08-25; both products change, and this page is a snapshot rather than a maintained contract.
Where Pithy pulls ahead
Apple, Google, Stripe, Paddle and Lemon Squeezy resolve to one cross-rail entitlement, with every purchase row in a database you own. Supabase has no payments story at all — you bring Stripe and wire it, and the cross-rail case is yours to build.
Authoritative sessions on Durable Objects, matchmaking, skill rating and leaderboards ship as composable capabilities. On Supabase this is a project, not a dependency.
Point-in-time recovery is $100 a month per seven days of retention on Supabase, billed outside their spend cap. On D1 it is called Time Travel, it is always on, it reaches back thirty days, and it costs nothing. Preview environments are the same shape: theirs need a Pro plan and bill by the hour, ours are the CLI. The pattern is worth naming, because it is where a platform bill actually comes from.
Cloudflare meters requests, CPU time, storage and reads. There is no tier that steps from $25 to $599 because you added a second project or a third teammate, and no seat to buy. The number moves with what your application actually did, which means a quiet month costs almost nothing and a busy one costs proportionally — and you can work out which before you commit.
Cloudflare does not bill for bandwidth out — not from Workers, and not from R2. For anything serving files, media or a busy API, egress is the line that quietly decides the bill everywhere else, and here it is zero. It is also why moving off is cheap, which is the honest version of the same fact: nothing is holding your data in by making it expensive to leave.
One command cuts a worktree, reserves ports and seeds a local backend; a second gives that branch its own D1, KV, R2 and master key on your Cloudflare account. Every name derives from the branch, so provisioning is idempotent, resumable and safe to run from CI — and teardown deletes by recomputed name, so an abandoned run still cleans up. Supabase does this too, on Pro and above, billed by the hour per branch.
Workers execute in hundreds of cities. There is no primary region to be far from, and no read replica to reason about — which also means no region to pick when you do not know where your users will be.
No service to be down, no plan to be throttled by, no dashboard holding your customers' data. The management plane reaches in with a key you registered and can delete.
Every capability contributes its English, one seam renders it, and the reader's locale is negotiated per request from the URL, their account, a cookie and Accept-Language. Supabase has no position on language at all — you choose a library, wire it twice for the server and the browser, and own the catalogs forever. Here the translations ship with the package, an override is one entry rather than a fork, and a missing one fails `pithy doctor` instead of surfacing to a reader.
Where Supabase wins
Decades of SQL maturity, window functions, CTEs and query planning that D1 does not attempt. If your data model is genuinely relational, this is not close.
PostGIS, pg_cron, pgvector and the rest of the ecosystem, installable. D1 has no equivalent.
Daily backups are included on paid plans and the restore path is well trodden, with a decade of Postgres operational practice behind it. D1's Time Travel is younger, even though it costs nothing and reaches back further.
Subscribe a client to a table and changes arrive, with no server code at all. Pithy's realtime is a Durable Object you design — more control, and more of your afternoon.
You can spin a preview branch straight from their dashboard, schema changes and all, with no repository configuration. Pithy's equivalent starts at a terminal in your project.
Authorization enforced in the database, so a mistake in one handler cannot leak another tenant's rows. Pithy authorizes per route, which is a weaker guarantee.
A table editor, a SQL editor, a genuinely good log explorer, and years of polish — all in one place. With Pithy, your data is in the Pithy dashboard and your logs are in Cloudflare's, which is two places to look.
More tutorials, more integrations, more answers already written down. Pithy is new and that shows.
A contract, an SLA and a person to escalate to. Pithy has GitHub issues.
Sizing, pooling, upgrades and backups are theirs to worry about, and for a team without an operations person that is worth real money.
Cost
Supabase sells plans; Cloudflare sells usage. That is the whole difference, and which one is cheaper depends entirely on your shape. What is worth understanding is how each behaves as you grow: a plan is predictable until the day it steps, and usage is proportional the whole way.
| Supabase | Pithy | |
|---|---|---|
| Entry | Free plan, $0 | Cloudflare free tier, $0 |
| First paid step | Pro, from $25 per month | Workers Paid, from $5 per month |
| Compute | $10 per month per project, less $10 of included credits | metered per request and per CPU millisecond |
| Second step | Team, from $599 per month | none — the same rates keep applying |
| Egress | metered and billed above the plan allowance | nothing. Cloudflare does not charge for egress |
| A quiet month | the plan price, in full | close to nothing |
| Point-in-time recovery | $100 a month per 7 days of retention, outside the spend cap | included, 30 days, at no charge |
| A preview environment per pull request | Pro or above, then roughly a cent an hour per branch | no fee; you pay Cloudflare for what the branch uses |
| Ten projects | compute billed per project on top of the plan | the same rates, and no per-project floor |
| Who you pay | Supabase, for the platform — plus Cloudflare or anyone else you also run | Cloudflare, directly, at their published rates. Pithy bills nothing |
Both vendors set and change their own prices, and these figures were read on 2026-08-18. Supabase's pricing page and Cloudflare's are the authority — not this page. Note that a Supabase plan price is a floor rather than a total: compute is billed per project on top of it.
It is a real conversion, and it is worth saying so plainly. D1 is SQLite. Moving from Postgres means giving up extensions, stored procedures and any query that leans on Postgres-specific behavior, and rewriting row-level security as route-level authorization.
If your schema is straightforward and your authorization already lives in application code, that is a few days. If you have PostGIS, materialized views and thirty policies, it is not a migration — it is a rewrite, and Supabase is the better answer.
Add one capability to a Worker and deploy it to your own Cloudflare account. If the shape is wrong you have lost an afternoon; if it is right you have skipped the part of this decision that is guesswork.