Skip to content

How it compares

Ramose is small and pre-release. Here is the honest trade against what you’d use otherwise — no feature matrix, just what’s the same, what’s different and what you give up. For a two-minute decision, read the table; the sections below add what you give up.

Instead ofSame ideaWhat’s different with Ramose
Convexqueries that re-run themselves, typed from your schemaruns in your Cloudflare account, not their cloud; a database per customer is a function call
Supabaserules enforced by the databaserules per field, deny by default, checked against your screens at deploy; your Cloudflare account, not their cloud
Instantread and write from the browser, live, with per-user permissionsyou own the deploy end to end; nothing is hosted for you
Firebaserealtime listeners and security rulesa typed schema in TypeScript; one database per customer by name; your Cloudflare account, not Google’s
D1 + Drizzle, or a Durable Object + SQLitethe same Cloudflare primitives, your account and deployalready assembled: live fan-out, per-customer routing, permissions, history
Postgres + an ORMtyped accessno migration ever rewrites old data; live queries and history come standard

Two words recur. The schema is your data model as one TypeScript value (glossary); a database is a named, isolated set of facts (glossary). One customer, one database — naming one is a line of code, not a project in a console.

examples/reef/src/app/ramose.ts:42
// A new customer is a name, not a deployment.
const db = ramose.db(slug, Reef);

What you give up: a hosted dashboard, scheduled functions and file storage.

What you give up: SQL and the Postgres tool belt, built-in sign-in and file storage. Rules also work differently: per field and deny by default, checked at deploy against the shapes your screens read.

What you give up: the hosted service and its admin console — you own the deploy end to end.

What you give up: Google’s console, hosted auth and the offline-first mobile SDKs.

Why not just D1 + Drizzle, or a Durable Object + SQLite?

Section titled “Why not just D1 + Drizzle, or a Durable Object + SQLite?”

What you give up: SQL and a hand-tuned storage layout. What you stop writing: the fan-out behind live queries (glossary), the migration runner, and the authorization middleware.

What you give up: SQL, a planner to tune, psql, and joins across databases.

  • SQL, or joins across databases
  • A hosted dashboard
  • Sign-in of its own — it verifies tokens from Better Auth, Clerk, Auth0 or any provider that publishes signing keys, and never issues them
  • File storage
  • Scheduled jobs
  • Aggregates (count, sum) — count rows on the client for now
  • Full-text search

In our benchmark (bench/RESULTS.md in the repo) one database sustained a few hundred writes per second on Cloudflare — 166–879 per second depending on client count. Past that you split across databases: a function call, not a deployment.

Each query has a memory limit on the server (about 48 MB by default). A query that exceeds it fails with a 413 instead of slowing everyone else down — narrow the query and retry.