0 Get started
Nhost's bet is that a GraphQL API generated from your schema removes most of the backend you would otherwise write. It is a good bet and it works. Pithy's bet is that the API you actually want is routes you wrote, against a database you can query — and that the parts worth not writing are payments, games and an audit trail rather than CRUD.
Choose Nhost
When an instant GraphQL API over Postgres is the shape you want.
Define tables, get queries, mutations and subscriptions with no resolvers to write, and permissions enforced in Hasura rather than in application code. Add Postgres itself — extensions, real SQL, a decade of tooling — and for a data-shaped product that is a very strong stack, self-hostable end to end.
Choose Pithy
When the hard parts are not CRUD.
Generating an API was never the expensive part of the backends this kit is for. Cross-rail entitlements, a ledger that cannot double-spend, matchmaking and an audit trail are — and all of them are written, tested and composable here, against a database that is yours.
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.
Both are, and both are self-hostable in their own way.
Sessions, OAuth providers, tokens. Table stakes.
Upload, serve, authorize. Both have it.
Node functions there, Workers here.
Hasura subscriptions there; Durable Objects here. Different shapes, same table stake.
Their CLI runs the stack locally; Pithy runs it on Miniflare.
The difference underneath
Nhost composes open-source parts: PostgreSQL for data, Hasura for an instant GraphQL API over it, plus auth, storage and functions. The API is derived from your schema, which is genuinely less code — and it means your permission model lives in Hasura's metadata rather than in the handler.
Pithy has no generated API. Capabilities contribute routes, your app contributes routes, and authorization is middleware on the route. There is more to write for simple CRUD and less indirection when something is not simple.
The database difference is real and worth stating: Postgres is a more capable database than SQLite, with extensions, richer types and a deeper query planner. D1's argument is not that it is better — it is that it is provisioned per environment inside your account, on a runtime that is already everywhere.
Feature by feature
| Feature | Nhost | Pithy |
|---|---|---|
Runtime & data | ||
| Full relational SQL Nhost: PostgreSQL, with extensions Pithy: D1 is SQLite — no extensions, no stored procedures | Yes | Partial |
| Instant generated API Nhost: Hasura, from your schema Pithy: routes you write; there is no generated CRUD layer | Yes | No |
| GraphQL Nhost: the primary interface Pithy: not offered; the kit is HTTP and JSON | Yes | No |
| Realtime subscriptions Nhost: Hasura subscriptions Pithy: Durable Objects for authoritative state | Yes | Partial |
| Permissions in the data layer Nhost: Hasura's permission system, enforced below your code Pithy: route-level authorization in your Worker, which is weaker and more explicit | Yes | No |
| Runs at the edge Nhost: containers, wherever you run them Pithy: Workers, by construction | No | Yes |
What the kit adds | ||
| Payments on five rails, one entitlement Pithy: Apple, Google, Stripe, Paddle and Lemon Squeezy | No | Yes |
| Per-user balance ledger Pithy: atomic, idempotent, overdraft-safe by CHECK constraint | No | Yes |
| Games infrastructure Pithy: authoritative sessions, matchmaking, rating and leaderboards | No | Yes |
| Audit trail attributed to an actor Pithy: including when a dashboard is the actor | No | Yes |
| Encrypted secrets with rotation Nhost: environment variables Pithy: a registry, per environment, with at-rest rotation | Partial | Yes |
| Support inbox in your own database Pithy: inbound mail, classified on your own AI binding | No | Yes |
Operations & ownership | ||
| Self-hostable Nhost: the whole stack, by container Pithy: nothing of ours to host; the code is MIT | Yes | Yes |
| No servers to run Nhost: Postgres, Hasura, auth, storage and functions, if you self-host Pithy: there is no Pithy server to deploy | No | Yes |
| A preview environment per branch Pithy: a worktree, ports and ephemeral resources, torn down afterwards | Partial | Yes |
| A polished platform console Nhost: one console over users, database, storage and the GraphQL 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 Nhost: users and tables; 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 |
| No charges for egress Nhost: whatever your host charges Pithy: R2 does not | Partial | Yes |
The saffron tick marks where Pithy leads — not that the other column is absent. Every claim about Nhost 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
An instant CRUD API saves real time, and it is not what makes a backend hard. Cross-rail entitlements, an overdraft-safe ledger, matchmaking and a trail attributed to the actor are — and on Nhost every one of them is yours to build on top.
Self-hosting Nhost means Postgres, Hasura, an auth service, a storage service and a functions runtime. Pithy has no instance of its own at any point.
Authoritative turn-based sessions with hidden per-player state, a skill-bucketed queue, leaderboards with closing windows. Hasura can hold the rows; it cannot referee the match.
Hasura's permission model is more powerful and lives in metadata. Route-level middleware is weaker and sits in the file you are already reading, which is a trade some teams will take gladly.
A Worker is already everywhere. Getting Postgres and Hasura near your users means running more of both.
Where Nhost wins
Extensions, richer types, a deeper planner, and every tool ever written for it. D1 is SQLite, and SQLite is not Postgres — the comparison page for Supabase says the same thing.
Queries, mutations and subscriptions with no resolvers, kept in step with the schema automatically. If your product is data-shaped, that is a lot of code you never write.
Row-level rules enforced by Hasura mean a mistake in one handler cannot leak another tenant's data. Route-level authorization is a weaker guarantee, honestly stated.
Postgres, Hasura, Node. If you dislike the platform you keep the pieces, which is a strong ownership story.
Caching, normalization and codegen ecosystems that HTTP and JSON simply do not have.
If your application is mostly data, and what you want is that data exposed safely with as little code as possible, Nhost is a very good answer and Postgres is a better database than D1. Choose the kit when the work is elsewhere — when the thing that will take your quarter is entitlements across three stores, a balance that must never go negative, or a match that has to be refereed by something no client can lie to.