A Supabase alternative that bills Postgres by the active hour

The moment that hurts on Supabase is the fourth project. Pro starts at $25 a month and covers the first project's instance, then every further project adds $10 a month for its own Micro instance — whether or not a single person used it that month.

Here there is no per-project fee. $10 a month buys 1,000 credits shared by every project. The 512 MiB database costs 20.00 credits per active hour, with its disk and seven-day backups included. After five idle minutes its RAM stops charging. Customer files and retained Worker resources keep their separate rates.

What Supabase charges

Supabase prices the organization first, then each project's compute. Pro starts at $25 a month and covers the first project's Micro instance through $10 of compute credits, 8 GB disk per project, 250 GB egress a month, 100,000 monthly active users. That first Micro instance is the only compute the plan pays for.

Every further project needs its own instance. A Micro is $10 a month; a Small is $15 a month. Supabase Pro with five projects come to $65 a month before disk or egress. That is Supabase pricing per project in one line: the plan, then an instance for every project after the first.

Above the allowances, disk is $0.125 per GB of disk per month beyond 8 GB per project. Egress is $0.09 per GB of egress per month beyond 250 GB, or $0.03 per GB of cached egress per month beyond 250 GB. The instance runs all month whether anyone queries it or not. That is the trade Supabase makes, and it is a good one for a database that is never idle.

Hosting the app itself is not on this bill. A Supabase project still needs a separate hosting account in front of it, which is why the figure above stacks three receipts.

List prices checked on 2026-09-28 — Supabase pricing.

Postgres on ohmyho.st: profiles and credits

ohmyho.st runs your Astro, Next.js, Vite/React or TanStack Start app on Workers and provisions a managed Postgres next to it when the app declares one. Nothing carries a base price. Free gets 200 credits per UTC month. Paid is $10 a month for 1,000 credits per period. Monthly credits expire at period end. Paid-only top-ups carry over until downgrade to Free and grant 100 credits per dollar, rising to 125 per dollar on the part of one checkout above the first hundred dollars.

The database meters RAM while it is awake. Allocated disk and seven-day backups are included in the selected size.

Five database sizes

The fixed RAM tariff is 10 credits per 256 MiB for one awake hour, prorated over active time. The selected size includes total disk and seven-day backups; CPU, network and connections have no separate database charge. A burst of queries wakes the database; five minutes without work allows sleep. Use database_compute_get to observe the actual size and state without waking it, and memory_mib with database_compute_set for an authorized increase. In-place disk shrink is refused. Read the database docs for the local psql helper and migration boundaries.

Included disk is the whole PostgreSQL volume, including WAL and filesystem overhead. It is not all available for application rows. A deployed script uses 6.571429 credits per 1 deployed script for a 744-hour month, so the idle project example costs about 6.57 credits a month even though sleeping database RAM, allocated disk and backups add no charge.

Five quiet projects for a month

About $0.99 of credit value at the standard rate.

That fleet fits inside one Paid month with credits to spare, and it is the same five projects that need five instances on Supabase. Every project draws from the organization's one balance. A project may carry a monthly budget that continues with warnings or stops new work; a zero balance starts a seven-day grace period in which funded services keep running. Automatic recharge stays off unless the Owner turns it on, so you top up on purpose. US is the default region; EU is a per-project choice made once at creation, at identical prices.

Keep Supabase or import a dump

Review keeping the external backend and importing its database as separate paths. Each needs verification against the actual application.

Path 1: host on ohmyho.st, keep the Supabase project

A Lovable export usually arrives as a Vite/React repository with a Supabase project behind it. Before retaining that backend, the agent inventories the real export and declares its exact browser connection origins in runtime.browser in ohmyhost.yaml; external scripts, images and other resource types have separate declarations. Server-side HTTPS calls use runtime.egress.allow instead, with at most 13 exact HTTPS origins and restrictive defaults for undeclared services. Public keys can stay in the browser bundle; private keys belong in the private runtime and use local stdin from secret_set_command or the supported remote portal input. A direct Postgres socket from the Worker to Supabase is not available, so server code uses the HTTPS API. Verify login, protected reads and writes, and any used files or backend functions on Dev before moving production traffic.

You keep paying Supabase for the database and ohmyho.st meters only the hosting: requests, CPU time, build seconds and the deployed script. The migration Skill's first step, an inventory of what the app actually calls, tells you whether this path is enough. A package name alone is not a reason to move anything.

Path 2: import the database

Ask for the migration Skill. The agent runs ohmyhost init --dry-run --json, inventories real database queries, RPCs, RLS assumptions, Auth sessions, Storage calls, Edge Functions and Realtime subscriptions, and tells you what moves, what needs source changes and what has no equivalent.

The schema comes from a PostgreSQL schema-only dump of your public schema (plus an app-owned private one) and becomes reviewed, additive migration files named YYYYMMDDHHMMSS_name.sql in your repository. Supabase's auth and storage schemas never enter that output. RLS policies are omitted and counted for review, because data access on ohmyho.st is server-side through the OHMYHOST_DATABASE binding rather than browser PostgREST calls, and every use case re-proves its authorization in code. Rows go in through a time-bound credential from database_access_create or ohmyhost database psql, which can write rows but never change schema and is revoked when it expires. The agent verifies reads and writes on Dev, then promotion_plan and promotion_execute apply the migrations to Prod without copying Dev records.

Be clear about what a dump does not carry: Auth users, Storage objects, Edge Functions and Realtime. Each is a separate decision, and the Skill states the gap instead of faking success.

Leaving has the same shape

Exports on ohmyho.st are on-demand, asynchronous and free. project_export_create returns a password-encrypted ZIP with a portable SQL dump, at most one accepted request per project per rolling 24 hours, downloaded through a signed link valid 24 hours, even at zero credits. Files, source and secrets are not in the archive, and there is no schedule. Restore it on any Postgres, Supabase among them. See ohmyhost-export-database and the backup docs.

Auth stays yours

ohmyho.st is not a Supabase Auth replacement. It has no user pool, no social provider catalog and no MFA service of its own. Application users belong to whichever provider you choose, and two integrations are verified:

• Better Auth, with the managed bridge selected explicitly in your project configuration. The bridge owns its own auth schema and database sessions and requires the managed database. Managed mail is optional for verified-user sign-in and sessions; the bridge’s verification/reset sends need its configured platform sender, Paid access and a verified sender domain. Set that sender up through mail_setup and check mail_status when you use these email actions. A customer-owned Better Auth implementation with its own sender is an ordinary application dependency; merely installing Better Auth does not select the managed bridge.
• WorkOS AuthKit, customer-owned. You bring your WorkOS account; the agent configures callback URLs per environment and installs the client secret through secret_set_command.

If you keep the Supabase project, keep Supabase Auth with it; the hosted app still calls it. If you import the dump and want off Supabase Auth, the migration Skill's opt-in mode rewrites auth.users into Better Auth's UUID auth."user" table and auth.uid() into a server-controlled helper. Test login, protected routes, session refresh and logout on Dev before you promote.

Your own login to ohmyho.st, and your agent's, runs through WorkOS and is a separate boundary: identity_get answers who is deploying, never who is signed in to your app. Read application auth before choosing.

Side by side

One busy app reads differently from five quiet ones. A small app for one month costs about 567.10 credits on ohmyho.st with hosting, mail and database in that figure; a database that never suspends is where Supabase pulls ahead, as the next section shows.

List prices checked on 2026-09-28 — Supabase pricing.

When Supabase is the better choice

• Realtime. Supabase pushes Postgres changes and presence to the browser. ohmyho.st has no managed Realtime contract. Keeping an external Realtime service requires its declared browser connection origins and a verified hosted subscription; moving to managed Postgres does not replace that capability with polling.
• Vector search. Supabase documents pgvector as a product path with examples. ohmyho.st makes no claim there.
• Auth breadth. Social providers, phone sign-in and MFA out of one hosted user pool. ohmyho.st offers two integrations, and you run them.
• Edge Functions ecosystem. A catalog of function templates and integrations next to the database. ohmyho.st runs functions and crons inside your framework's own routes, which is smaller.
• A database that never sleeps. A database that never suspends for one month costs about 119,040.00 credits on ohmyho.st, about $1,190.40 of credit value. Supabase Pro covers that same always-on Micro instance in its base price. Constant traffic belongs on Supabase.
• A dashboard. Supabase has a table editor, SQL editor and logs in a browser. On ohmyho.st your agent reads a hundred rows at a time through database_query, and the portal shows projects, credits, budgets and tokens, not your tables.

List prices checked on 2026-09-28 — Supabase pricing.

When ohmyho.st is

• Several small projects. The five quiet projects above cost about 99.01 credits together; on Supabase each one needs its own instance. Nine side projects and two live ones is the normal shape of a builder's account, and no base fee punishes it.
• Databases that idle. A portfolio site, internal tool or client demo can have hours of activity rather than hundreds. After five idle minutes database RAM stops charging; included disk and backups remain available.
• One balance for hosting, Postgres, mail and a domain. The app, its database, its transactional mail (Paid, metered at 0.18 credits per 1 sent recipient per sent recipient) and a linked custom hostname (32.857143 credits per 1 paid custom hostname for a 744-hour month) all draw from the same 1,000 credits a month. The hostname needs Paid or, on Free, a project that shows the “Powered by ohmyho.st” flag; the flag waives domain credits on either plan. No second and third account.
• You deploy from Claude Code, Cursor or Codex. There is no deploy dashboard. The agent plans, you confirm, it executes: deployment_plan then deployment_create, promotion_plan then promotion_execute, rollback_plan then rollback_execute.
• Choose the location you need. A new EU project places its database, new files and builds in the EU. Existing projects moved to US with their owner's authorization use US databases; existing R2 locations stay recorded. Transactional mail is processed in the US.
• A ceiling per project. project_budget_set gives a project a monthly budget that warns or stops. A zero balance starts a seven-day grace period; funded services keep running.

How to move with your agent

1. Reuse the app's current project and source, or choose managed versions or GitHub for a new app. A selected Lovable GitHub export can keep its sync; accessible current files can be saved as a managed version.
2. Paste the prompt below into Claude Code, Cursor or Codex. The agent reads llms.txt and the get-started Skill, sends you one sign-in link, then continues the current source, saving managed files or linking the selected GitHub repository with source_link.
3. Tell it which path: keep Supabase (it adds the origin to runtime.egress.allow and delivers private keys through local stdin or the supported remote private portal input) or import (it follows the migration Skill: inventory, schema dump to migration files, rows through a time-bound credential).
4. Review the plan. deployment_plan quotes the build and lists requirements; deployment_create runs it. The agent verifies the Dev URL through the share link from project_dev_share_link_get with a real login and a real read and write.
5. Promote with promotion_plan, then promotion_execute. Set a ceiling with project_budget_set if you want one.
6. Take a Supabase backup first, cancel Supabase Pro only after Prod checks pass, and keep your ohmyho.st export password somewhere private.

Read https://ohmyho.st/llms.txt and https://ohmyho.st/skills/ohmyhost-get-started/SKILL.md. Connect this agent to ohmyho.st and develop and deploy this application using only the capabilities it needs. Read the existing project source first and follow the get-started Skill to reuse GitHub or managed versions for this workspace. After signing in, use the user and organization that whoami reports; never guess an account, organization or project ID. Follow the deployment Skill, keep my existing project decisions and verify the app.

FAQ

Does ohmyho.st replace Supabase Auth?

No. ohmyho.st hosts your app and its Postgres; application users stay with a provider you own. The managed Better Auth bridge needs its database; managed mail is optional. Its verification/reset sends use the configured platform sender and require Paid access and a verified sender domain. Your own Better Auth implementation and sender remain ordinary dependencies, and customer-owned WorkOS AuthKit is another documented path. If you keep your Supabase project, keep Supabase Auth with it and verify the hosted login. Your own ohmyho.st login is a separate WorkOS boundary.

Can I host on ohmyho.st and keep my Supabase database?

It is an option to verify against your actual application. Declare browser connections and resource origins separately in runtime.browser in ohmyhost.yaml; declare server-side HTTPS calls in runtime.egress.allow, which allows at most 13 exact origins. Keep private keys in server code through secret_set_command. A direct Postgres socket from the Worker is not available. Before moving traffic, test the actual export's login, protected reads and writes, and any used files or backend functions on Dev. If those checks pass and Supabase stays, its database bill remains separate from ohmyho.st's metered hosting.

What does an idle project cost on ohmyho.st?

The deployed script. One project with a sleeping database and nothing happening costs about 6.57 credits a month, because database RAM stops charging after five idle minutes, allocated disk and seven-day backups are included, and Workers bandwidth is not charged. Customer files keep their own rates. Five quiet projects that each wake for an hour cost about 99.01 credits together, inside the 1,000 credits a Paid month grants.

How do I get my data out again?

Ask your agent for an export. project_export_create returns an asynchronous, password-encrypted ZIP with a portable SQL dump, and the owner chooses the password. One accepted request per project per rolling 24 hours, a signed download link valid 24 hours, retained seven days, free, and available even at zero credits. Files, source and secrets are not in it. Restore it on any Postgres host.

Is there a per-project fee?

No. Every project draws from the organization's one balance, so a second or fifth project adds only what it uses: build seconds, requests, CPU time, active database hours, customer files and one deployed script. A project may carry a monthly budget that continues with warnings or stops new work, and the portal at app.ohmyho.st shows credits and budgets per project.

Can I choose the EU for my database?

Yes, per project and once. Pass region: eu to project_create and the project's Postgres, files, build sandbox and build objects live in the EU, with the app running next to its database. US is the default, prices are identical in both regions, and the region cannot change after creation. Transactional mail is sent and processed in the US regardless.

Sources

• List prices checked on 2026-09-28 — Supabase pricing.
• List prices checked on 2026-09-28 — Vercel pricing.
• List prices checked on 2026-09-28 — Resend pricing.

Compare Vercel · Move from Vercel and Supabase · Where your credits go · Supabase vs Vercel: do you need both? · Free Vercel and Supabase alternatives · Vercel and Supabase in one platform

ohmyho.st is an independent service, not affiliated with or endorsed by Vercel, Supabase or Resend. All trademarks belong to their respective owners.