StitchDB vs Appwrite: Postgres Backend or Open Source API?

StitchDB and Appwrite both give you auth, a database, storage, functions and realtime behind one dashboard, but they make opposite bets. Appwrite is open source (BSD 3-Clause), self-hostable, built around its own database API with Appwrite permissions, and runs functions in more than a dozen languages. StitchDB is a managed platform with a dedicated Postgres database per project, SQL and row level security, Deno functions, and app services like push, offline sync and purchase checks built in. If you need to self-host or write functions in Python or Go, Appwrite is the stronger choice; if you want SQL and a capped flat bill, StitchDB is.

#Side by side

#The core difference: SQL-first or API-first

Appwrite's Databases product has TablesDB (tables, typed columns, rows and relationships), DocumentsDB for schemaless JSON and VectorsDB for embeddings, all used through the Appwrite SDKs with Appwrite permissions and realtime. You query with the SDK's query helpers. It is approachable for developers who have not written much SQL, and it maps well to Firebase-style apps.

Appwrite Cloud also offers native PostgreSQL and MySQL databases with direct connections, from $10/month per database on paid plans (as of November 2026). Its docs describe these as the raw engine, separate from the SDK data APIs: Appwrite permissions and SDK queries apply to TablesDB, not to the native database. So on Appwrite you choose between the Appwrite API with its permissions, or plain SQL without them.

StitchDB gives you Postgres. You write tables (in the Studio table editor or SQL), and every table becomes a REST endpoint. Aggregations, joins and transactions are SQL. For a reporting screen like "revenue per plan this month", that is one view:

create view public.revenue_by_plan as
select p.name as plan, sum(i.amount_cents) / 100.0 as revenue
from public.invoices i
join public.plans p on p.id = i.plan_id
where i.paid_at >= date_trunc('month', now())
group by p.name;

const { data } = await stitchdb.from('revenue_by_plan').select('*')

Through an SDK query API you usually compute this in a function or keep running totals. Neither approach is wrong; it depends on how much of your app is reporting, joins and constraints.

#Permissions

Appwrite attaches permissions (read, create, update, delete, or write as shorthand) to tables, rows, buckets and files, for roles such as any, guests, users, a specific user, a team or team role, a member or a label. It is easy to reason about for per-row sharing.

StitchDB uses Postgres policies, which can express rules that look at other tables:

create policy "Team members read projects" on public.projects
  for select to authenticated
  using (exists (
    select 1 from public.team_members m
    where m.team_id = projects.team_id and m.user_id = auth.uid()
  ));

StitchDB also has organizations for your app's users (members, roles and invites, with JWT claims and RLS helpers), which covers the common team-sharing case without writing that table yourself.

#Functions

This is Appwrite's clearest advantage. Its functions run in many runtimes, including Python, Go, Dart, PHP, Ruby, .NET, Java, Kotlin and Rust (not every runtime is available on Appwrite Cloud). StitchDB's Edge Functions run TypeScript or JavaScript on Deno with Deno.serve, npm and JSR imports, streaming responses, and EdgeRuntime.waitUntil for background work:

import Stripe from 'npm:stripe@17'

Deno.serve(async (req) => {
  const stripe = new Stripe(Deno.env.get('STRIPE_SECRET_KEY')!)
  const { priceId } = await req.json()
  const session = await stripe.checkout.sessions.create({
    mode: 'subscription',
    line_items: [{ price: priceId, quantity: 1 }],
    success_url: 'https://example.com/thanks',
  })
  return Response.json({ url: session.url })
})

StitchDB balances this with logic inside the database: SQL functions callable over REST, triggers, pg_cron, pgmq queues and pg_net for HTTP from SQL. If your team writes backend code in Python or Go, Appwrite fits better. Otherwise TypeScript plus SQL covers most needs.

#Pricing (as of November 2026)

Appwrite's numbers are per project from appwrite.io; StitchDB's are on pricing. Appwrite's Pro includes more bandwidth; StitchDB's includes a 10 GB Postgres database and point-in-time recovery (7 days on Pro, 24 hours on Free). Appwrite lists point-in-time recovery for dedicated databases at +20% of the database price.

#Self-hosting and lock-in

Appwrite can run on your own servers with Docker, which is a strong guarantee against vendor risk. StitchDB has no self-hosted edition. Its answer to lock-in is open formats: a full export on every plan (pg_dump, users with bcrypt hashes, files, function source), and APIs compatible with the open-source Supabase stack, so the supabase-js family of client libraries works against it. See compatibility.

#Regions

Appwrite Cloud runs in six regions (Frankfurt, New York, San Francisco, Singapore, Sydney and Toronto), and you can self-host anywhere. StitchDB runs only in the EU: Falkenstein and Nuremberg in Germany and Helsinki in Finland. That suits European users and GDPR requirements and adds latency for users far away.

#Verdict

Choose Appwrite if you want open source and self-hosting, function runtimes beyond TypeScript, an API-first data model with built-in permissions, frontend hosting in the same platform, or regions outside Europe.

Choose StitchDB if you want Postgres and SQL, policies that can join across tables, a flat plan with a spend cap, built-in offline sync, push and in-app purchase verification, and EU-only hosting.

Still deciding? See Appwrite alternatives and Supabase vs Appwrite.

#FAQ

#Is Appwrite or StitchDB better for Flutter?

Both have Flutter SDKs. StitchDB's Flutter client includes offline sync, push, purchases and organizations; Appwrite's covers its services and runs functions in Dart.

#Can I self-host StitchDB like Appwrite?

No. StitchDB is managed only. You can run the whole stack locally for development with stitchdb start, without Docker.

#Does Appwrite support SQL?

Yes, in two ways. TablesDB is relational but used through the Appwrite API. Appwrite Cloud's native PostgreSQL and MySQL databases accept direct SQL connections, but Appwrite's permissions and SDK queries don't apply to them. On StitchDB, SQL, the REST API and RLS policies all work on the same database.

#Which is cheaper?

For small apps both are free. As of November 2026, Appwrite Start is from $10 and Pro from $25; StitchDB Pro is $15.99. Compare against your bandwidth, users and database size.

See how Postgres feels as your app backend: start free on StitchDB.