# Best hosting and managed Postgres for a startup's first 100 paying users (2026) URL: https://www.prisma.io/blog/choosing-hosting-and-postgres-after-your-first-100-users Published: 2026-09-24 Updated: 2026-11-12 Authors: Gregory Boch Tags: platform, prisma-postgres Description: Managed PaaS (Prisma Compute, Render or Railway) and Postgres (Prisma Postgres, Neon or Supabase) for a startup's first 100 paying users, and when to scale. > Blog posts describe Prisma as it was on the date shown and are not kept current. Before implementing from a post, check the documentation index at https://www.prisma.io/docs/llms.txt and the changelog at https://www.prisma.io/changelog.md. > For an index of every published post, fetch https://www.prisma.io/blog/llms.txt. For your first 100 paying users, put the database on [Prisma Postgres](https://www.prisma.io/docs/postgres) and the app on a managed platform-as-a-service: [Prisma Compute](https://www.prisma.io/docs/compute) for a TypeScript app, Render or Railway for an app in any other language. Prisma Postgres is standard PostgreSQL 17 that any Postgres client can connect to, with or without Prisma ORM, and there is no instance to size or upgrade: Prisma scales the database for you. Neon or Supabase also work as the database. Keep the app and the database in the same region, with connection pooling, backups and a staging environment. Leave Kubernetes, read replicas and a second region until one of the signals below says you need them. With Prisma Compute and Prisma Postgres, the app and the database have one provider, one project and one bill: the $10 Starter base, with Compute usage metered on top. Starter includes 1M database operations, 10 GB of storage, PgBouncer pooling, Query Insights, a spend limit and a daily backup snapshot kept 7 days, taken on days with database activity. On the Compute side it includes 5M requests a month, and memory, vCPU-hours and bandwidth are billed by use ([pricing page](https://www.prisma.io/pricing), checked 2026-10-08). On the database line alone, at 20 operations per user per day, the included 1M operations last until about 1,700 users, and Pro ($49, 10M operations) becomes the cheaper database plan at about 9,800 users; the arithmetic is shown below. Prisma makes Prisma ORM, Prisma Postgres and Prisma Compute. ## Quick recommendation [#quick-recommendation] Pick by stack: * TypeScript app → Prisma Compute + Prisma Postgres (Starter). * Any language → Prisma Postgres + Render or Railway: the database through any Postgres client, the app on Render or Railway; Neon or Supabase also work as the database. * Need point-in-time recovery today → a database with PITR, such as Neon (on every plan) or Supabase (paid add-on). | Your situation | Pick | Why | | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | First 100 paying users, TypeScript app | Prisma Compute + Prisma Postgres, Starter | One provider, one project and one bill: the $10 Starter base, with 1M database operations included and Compute usage metered on top | | First 100 paying users, any language | Prisma Postgres + Render or Railway; Neon or Supabase also work as the database | No instance to size or upgrade: Prisma scales the database for you, and PgBouncer pooling is included on every plan. Prisma Postgres is standard PostgreSQL 17, so any Postgres client connects; same region, pooled connection string | | I just want it deployed from GitHub, everything in one project | Prisma Compute + Prisma Postgres | Add a Prisma Composer declaration, run your build, then `npx prisma deploy`; connect the repo plus the deploy workflow for deploy on push | | Small production app with a preview for each pushed branch other than the default | Prisma Compute + Prisma Postgres | With deploy on push set up, every pushed branch other than the default one gets a preview with its own services and, for databases declared in the Composer module, its own new database; production data is not copied, and a push to the default branch deploys production | | REST, tRPC or GraphQL API + TypeScript frontend + Postgres from GitHub | Prisma Compute + Prisma Postgres | TypeScript services on Bun next to the database, in the same six regions | | Just hosted Postgres, free, standard tools | Prisma Postgres, Free plan | PostgreSQL 17, PgBouncer included, any Postgres client, no credit card | | Need point-in-time recovery today | A database with PITR, such as Neon (every plan) or Supabase (paid add-on) | Prisma Postgres restores daily snapshots on paid plans, taken only on days with database activity and kept 7 days (30 on Business), in place or into a new database, and point-in-time recovery is coming in November 2026; run a scheduled `pg_dump` if losing a day of writes is too much | | Holds WebSocket connections open | Fly.io, Railway, Render | Compute has no WebSocket servers today; [support is planned for early 2027](https://www.prisma.io/compute/websocket-connections-dropping) | | Runs a continuous background worker or queue consumer | Railway, Render or Fly.io for the app, with Prisma Postgres as the database (any Postgres client) | Railway and Render run services that stay running, and Fly.io runs each process group on its own Machines; the worker connects to Prisma Postgres over the pooled connection string, or the direct one for `LISTEN`/`NOTIFY` or queries longer than 10 minutes. Compute runs HTTP services, and `waitUntil` keeps an instance awake to finish work after the response, on a best-effort basis | | Python or Go API | Railway, Render or Fly.io for the app, with Prisma Postgres as the database (any Postgres client) | Compute hosts TypeScript services; Prisma Postgres works from any language | | Frontend needs a global CDN above all | Vercel + Prisma Postgres | Compute serves from one region, not an edge network | | More than one region | Fly.io | Each Compute service runs in one of six regions | | Lowest bill, run servers yourself | A VPS | You take on backups and upgrades | If the app generates work customers keep editing, see [storing editable AI drafts](https://www.prisma.io/postgres/editable-ai-generated-drafts) for account ownership, saved versions and conflicting browser-tab updates. ## Buy time, not architecture [#buy-time-not-architecture] The decisions that are expensive to reverse later are whether your database connections go through a pooler, and where the app runs relative to its data. A bigger plan, a read replica, a queue or a second region can wait until a signal you can name says otherwise, because infrastructure work now is paid for out of feature work. What to buy now depends on your app's language: for TypeScript, Prisma Compute and Prisma Postgres; for any other language, Render or Railway with Prisma Postgres, or with Neon or Supabase. The alternatives follow with dated prices, and the [comparison of seven app hosting platforms with managed Postgres](https://www.prisma.io/blog/app-hosting-platforms-with-managed-postgres-2026) sets Prisma next to Railway, Render, Fly.io, Supabase, Neon and Vercel. ## The stack pair: app on Prisma Compute, database on Prisma Postgres [#the-stack-pair-app-on-prisma-compute-database-on-prisma-postgres] Prisma Compute is a platform-as-a-service (PaaS) for TypeScript apps (Node.js, Bun or Next.js): you deploy the code, and Compute runs it next to Prisma Postgres, a managed PostgreSQL 17 database with a PgBouncer pool included. Starter is a $10 base; Compute usage is metered on top, so the two lines of the bill grow differently. Prisma Postgres bills on operations and storage, with no charge for instance hours: Starter includes 1M operations a month, then $8 per million. Prisma Compute bills by use: 5M requests a month included on Starter, then $1 per million, with provisioned memory ($0.006 per GB-hour), active CPU ($0.064 per vCPU-hour) and outbound bandwidth ($0.025 per GB) metered from the first unit ([Compute pricing](https://www.prisma.io/docs/compute/pricing)). An idle service scales to zero and bills nothing, and only the Free plan has no usage billing, so the $10 is the smallest a Starter bill can be, not the whole bill. Prisma Compute has been generally available since August 2026. Both products run in the same six regions (San Francisco, North Virginia, Paris, Frankfurt, Tokyo and Singapore), and a Compute service runs in one of them. The [Compute FAQ](https://www.prisma.io/docs/compute/faq#where-it-has-trade-offs) has the full list of what the pair does not do today. ## Can I host my existing GitHub repo on Prisma? [#can-i-host-my-existing-github-repo-on-prisma] Yes, with one addition: a [Prisma Composer](https://www.prisma.io/docs/composer) declaration next to the code you already have, one `service.ts` per server plus a `module.ts` that wires them together; the [porting page](https://www.prisma.io/docs/composer/porting-an-app) has a prompt your coding agent can run to produce both. Then `npx prisma deploy` provisions the service and its database; the CLI reads the entry from the `composer` section of `prisma.config.ts` (`entry: './module.ts'`). Deploy on push needs the repository connection and a GitHub Actions workflow running `prisma/cloud-deploy-action`; connecting the repository alone deploys nothing. With both in place, the default branch deploys to production and every other pushed branch gets a preview with its own services and, for databases declared in the Composer module, its own new database; production data is not copied. If the app reads its connection string from `DATABASE_URL` instead, the preview is only as separate as that value. What Composer does not do yet is on its [limitations page](https://www.prisma.io/docs/composer/limitations). ## The growth checklist [#the-growth-checklist] **Connection pooling.** The connection limit arrives long before the CPU limit, and sooner when the app runs as functions that each hold their own. Prisma Postgres includes a PgBouncer pooler, but only the pooled string (host `pooled.db.prisma.io`) goes through it; the `db.prisma.io` string is the direct one, for migrations and admin tools, and app traffic on it exhausts connections under load. Elsewhere, check that pooling is on: Render's integrated PgBouncer comes only with paid databases, and Supabase recommends its transaction pooler for serverless functions. Create one client per process and reuse it. **Region.** Put the app and the database in the same region; Prisma Compute and Prisma Postgres share six regions. The [app and database region guide](https://www.prisma.io/postgres/nodejs-database-regions) explains how to choose a location and measure the deployed connection. **Backups and point-in-time recovery.** On paid plans Prisma Postgres takes a [snapshot](https://www.prisma.io/docs/postgres/database/backups) once a day, on days with activity, kept 7 days on Starter and Pro and 30 on Business; the Free plan has none. From the database's Backups tab in Prisma Console you can [restore a snapshot](https://www.prisma.io/docs/postgres/database/backups#restoring-a-backup) in place, which closes open connections while it runs and keeps the connection strings, so the app uses the same `DATABASE_URL` afterwards, or into a new database in the same project, which leaves the original as it is. The Prisma CLI and the REST API's restore endpoint restore in place, and the REST API and the MCP server can also restore a snapshot into a new database. Point-in-time recovery is coming in November 2026; until then you restore to a snapshot, so writes after the latest snapshot can be lost; if a day of writes is too much to lose, run `pg_dump` on a schedule over the direct connection as well. Restore a snapshot into a throwaway database once, and time it; the [guide to recovering deleted records](https://www.prisma.io/postgres/recover-deleted-records) shows how to copy rows back from such a copy. **Migrations.** Commit them and run them over the direct string, never the pooled one. With Composer's `postgres()` dependency and a data contract, the deploy applies your `migrations/` folder before the service starts, in production and in every preview; with `rawPostgres()` you get a connection string and the migrations stay yours to run. **Spend limits.** Every paid plan includes one you set in the Console, and none applies until you do: under **Workspace Settings** > **Billing**, enter an amount, click **Set Limit** and type the workspace name to confirm. The limit counts usage charges in a billing cycle, not the plan fee. Pick the amount knowing what happens when it is reached: queries to the workspace's databases stop, and a cap that stops a production database trades an invoice for downtime. Loops are what make operations climb: a job that polls the database once a second makes about 2.6M operations a month, more than twice what Starter includes. On Compute, a job like that runs only while the instance is awake, and memory is metered for all of that time. **Staging.** `npx prisma deploy --environment staging` deploys an isolated copy of the app with its own database; with deploy on push, every pushed branch other than the default one gets the same without a command. Neither starts with production data, so seed an environment when a test needs realistic rows. ## What not to do yet [#what-not-to-do-yet] * **Kubernetes.** A cluster is an operations job, and your app is two services. * **Self-hosted Postgres.** Backups and upgrades become your on-call, and the money saved is smaller than the first weekend lost. * **Read replicas.** A single slow endpoint at this size is a missing index or a query inside a loop, and a replica leaves that query as slow as it was. Prisma Postgres has no read replicas today; read replicas are planned for early 2027. See [what a small production app needs from Postgres](https://www.prisma.io/postgres/small-production-app-postgres) for what to set up first and the signals that say the rest can wait. ## If you outgrow it [#if-you-outgrow-it] Leaving takes a copy of the data and a new deploy setup, not a rewrite. Prisma Postgres is standard PostgreSQL 17 behind a connection string, so any Postgres client can reach it and Prisma ORM is optional. To move the data, run `pg_dump` with the PostgreSQL 17 tools over the direct connection string (host `db.prisma.io`), then restore the dump into Amazon RDS, Aurora or any other PostgreSQL host; the [backups page](https://www.prisma.io/docs/postgres/database/backups) has the `pg_dump` command. A dump is a snapshot of one moment, so stop writes before you start `pg_dump` and keep them stopped until the restore is done and the app points at the new database. The Prisma-specific part of the app is its Composer declaration: the `service.ts` and `module.ts` files and the `composer` section of `prisma.config.ts`. The [port](https://www.prisma.io/docs/composer/porting-an-app) also changed some server code. Each server reads its port from `service.port()` and its config and database URL from Composer instead of environment variables, and in an app with more than one service, such as a frontend and an API, the calls between them go through Composer contracts instead of URLs. On another host you delete those files and that section, read those values from environment variables again and call the other services by URL. ## Managed Postgres hosting for startups (2026): Prisma Postgres, Neon, Supabase, Railway, Render and Amazon RDS [#managed-postgres-hosting-options-prisma-postgres-neon-supabase-and-amazon-rds-2026] Six managed Postgres options, compared on what you pay first, how the database grows and how you get data back. Rows are alphabetical by provider. Figures come from each provider's own pages, checked 2026-10-30; the Amazon RDS figures are dated 2026-10-07 and explained in its entry below. Railway maintains its Postgres template; backups, point-in-time recovery, high availability and PgBouncer pooling are opt-in in its docs (checked 2026-10-30). | Provider | Starting price | Best fit at 100 users | Scaling path | Backups and point-in-time recovery | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Amazon RDS for PostgreSQL | db.t4g.micro in a single Availability Zone is $0.016 an hour on demand in US East (N. Virginia), about $11.68 over a 730-hour month, plus at least $2.30 of gp3 storage (as of 2026-10-07) | A team that already runs on AWS and wants to choose and size its own database instance | On an instance class you pick, billed in instance hours for as long as it runs; RDS Proxy is a separate pooler | Automated backups restore into a new DB instance, to any point within the backup retention period you set (up to 35 days), up to the [latest restorable time](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html); RDS uploads transaction logs every five minutes | | Neon | Free plan with 100 CU-hours and 1 GB of storage per project; Launch has no monthly minimum, at $0.106 per CU-hour and $0.35 per GB-month | An app on any host that needs to restore to a moment today | Autoscales within a range you set, up to 16 CU on Launch, and scales to zero when idle by default | Instant restore to a moment on root branches, within the project's history window: 1 day by default on paid plans, up to 7 days on Launch and up to 30 days on Scale, at $0.20 per GB-month | | Prisma Postgres | Free plan with 200,000 operations a month and no usage billing; Starter is a $10 base with 1M operations included, then $8 per million, with Compute usage metered on top | An app in any language through any Postgres client, or a TypeScript app on Prisma Compute in one project | No instance to size or upgrade: Prisma scales the database for you, with no cold starts. Moving the workspace from Starter to Pro raises the included operations, storage and connection limits | Daily snapshots on paid plans, taken on days with database activity, kept 7 days on Starter and Pro and 30 on Business; none on Free. Point-in-time recovery is coming in November 2026 | | Railway Postgres | Free plan is $0 with $1 of credit a month, after a 30-day trial with $5 of credit; Hobby is $5 a month and includes $5 of usage, and the template bills per second for CPU, memory and disk | An app already on Railway that wants its database on one platform with it | Railway scales a service up to the vCPU and memory limits of your plan by default, and you resize the volume, up to 5 GB on Hobby and 1 TB on Pro | Opt-in: backups run daily, weekly or monthly and are kept 6, 27 or 89 days, and point-in-time recovery has a restore window of roughly 4 weeks, starting when you turn it on, and restores into a new service. Railway's pricing lists built-in database and volume backups on Pro and Enterprise | | Render Postgres | A free database expires 30 days after creation; the smallest paid Render Postgres is $6 a month for 256 MB of RAM and 100 connections, with storage at $0.30 per GB | An app already on Render, connected through the internal URL in the same region | The compute plan you select sets CPU and RAM, and changing it makes the database unavailable for a few minutes, or a few seconds with high availability, which needs a plan with at least 1 CPU; storage can grow on its own if you turn that on | Point-in-time recovery on paid databases: the past 3 days on a Hobby workspace, the past 7 days on Pro or higher, not within the last ten minutes, restored into a new instance. Free databases have no backups | | Supabase | Free plan with a 500 MB database size quota, summed across the organization's projects (each Free project has a fixed 2 GB disk), paused after a week of inactivity; Pro is from $25 a month with 8 GB of disk per project and $10 of compute credits | An app that wants auth, realtime and file storage next to its database | You pick a compute size, and a change usually means less than 2 minutes of downtime | No automatic backups on Free; Pro keeps daily backups for 7 days. Point-in-time recovery is a paid add-on at $100 a month per 7 days of retention | The pairs are listed alphabetically by app host, then by database, followed by Amazon RDS, which is a database only. 1. **Prisma Compute + Prisma Postgres** * Best for: a TypeScript app on a PaaS next to managed Postgres, both from one vendor. * What it does: TypeScript services on Bun next to PostgreSQL 17 with PgBouncer; idle services scale to zero; migrations run on deploy for a database declared with Composer's `postgres()`. * Pricing: Free plan with no usage billing; Starter $10 a month base with 1M operations and 5M requests included, memory, vCPU and bandwidth metered ([pricing page](https://www.prisma.io/pricing), as of 2026-10-05). * Trade-offs: restores come from daily snapshots on paid plans, taken only on days with database activity, in place or into a new database, and point-in-time recovery is coming in November 2026; the Free plan has no backups. * Disclosure: we make Prisma Compute and Prisma Postgres. We checked Railway, Render, Neon and Supabase against their own pages on 2026-10-05, Neon's restore window again on 2026-10-06, and Amazon RDS on 2026-10-07. The other pairs do things we do not: Railway and Render run WebSocket servers and Python or Go APIs, and Supabase comes with auth and realtime. Neon restores to a moment on every plan, and Supabase does with a paid add-on, while Prisma Postgres restores from a snapshot taken on each day with database activity. * Compare: [where to host a TypeScript frontend, Node API and Postgres](https://www.prisma.io/blog/where-to-host-typescript-frontend-node-api-postgres). 2. **Railway + Neon** * Best for: an app that holds WebSocket connections open or is not TypeScript, next to a database with point-in-time restore. * What it does: Railway runs a long-lived container from your repository and bills CPU and memory while it runs (a Serverless setting sleeps idle services); Neon is serverless Postgres billed by compute hours awake and storage. * Pricing: Railway Hobby is $5 a month with $5 of usage included, then about $10 per GB of memory and $20 per vCPU a month, plus $0.05 per GB of egress ([Railway pricing](https://railway.com/pricing), as of 2026-10-05). Neon's Free plan has 100 compute-unit hours and 1 GB of storage per project; Launch has no monthly minimum, at $0.106 per compute-unit hour and $0.35 per GB-month, with instant restore up to 7 days at $0.20 per GB-month ([Neon pricing](https://neon.com/pricing), as of 2026-10-05). * Trade-offs: two vendors and two bills. * Compare: [Neon vs Prisma Postgres](https://www.prisma.io/blog/neon-vs-prisma-postgres-app-hosting-in-one-place) and the [pricing comparison](https://www.prisma.io/blog/prisma-postgres-vs-neon-pricing-2026). 3. **Render + Prisma Postgres** * Best for: an app in any language that runs as a long-lived server or worker, next to a database with no instance to size or upgrade. * What it does: Render runs web services and background workers on a compute plan you pick; Prisma Postgres is standard PostgreSQL 17 that any Postgres client can reach, with or without Prisma ORM, with PgBouncer pooling included. The app connects over the pooled connection string, and migrations use the direct one, as does any worker that needs `LISTEN`/`NOTIFY` or queries longer than 10 minutes, within the limit of 10 direct connections on Starter, 5 of them reserved for platform operations. Pooling runs in transaction mode, so [session state such as prepared statements](https://www.prisma.io/docs/postgres/database/connection-pooling) doesn't carry across transactions. Render and Prisma Postgres both have regions in Virginia, Frankfurt and Singapore, so put the app and the database in the same one. * Pricing: Render's smallest paid web service is $7 a month on its $0 Hobby workspace ([Render pricing](https://render.com/pricing), checked 2026-10-30). Prisma Postgres Starter is a $10 base with 1M operations included, then $8 per million ([pricing page](https://www.prisma.io/pricing), checked 2026-10-30), and with the app on Render there is no Compute usage on that bill. The pair starts at $17 a month for one person, before any usage past those allowances; [inviting team members](https://render.com/docs/team-members) takes a Render Pro workspace, at $25 a month plus compute, so a team starts at $42. * Trade-offs: two vendors and two bills. Restores come from daily snapshots on paid plans, taken only on days with database activity, and point-in-time recovery is coming in November 2026; if you need that today, use Neon in the database slot, as in the pair above. * Compare: [seven app hosting platforms with managed Postgres](https://www.prisma.io/blog/app-hosting-platforms-with-managed-postgres-2026). 4. **Render + Supabase** * Best for: a long-lived server next to a database that comes with auth, realtime and file storage. * What it does: Render runs web services and workers by instance type; Supabase is Postgres behind the Supavisor pooler plus auth, realtime and storage. * Pricing: Render's Hobby workspace is $0 plus compute and Pro is $25 a month plus compute, and the smallest paid web service is $7 a month for 0.5 CPU and 512 MB ([Render pricing](https://render.com/pricing), as of 2026-10-05). The smallest paid Render Postgres is $6 a month for 256 MB of RAM and 100 connections, with storage at $0.30 per GB (checked 2026-10-24). Supabase Pro is from $25 a month with $10 of compute credits, 8 GB of disk, daily backups kept 7 days and a spend cap on by default; point-in-time recovery costs $100 a month per 7 days of retention ([Supabase pricing](https://supabase.com/pricing), as of 2026-10-05). * Trade-offs: Supabase's Free plan pauses a project after a week of inactivity and has no backups, and a free Render Postgres expires 30 days after creation. * Compare: [Netlify alternatives for a full-stack TypeScript app](https://www.prisma.io/blog/prisma-vs-netlify). 5. **Amazon RDS for PostgreSQL** (the database only, with the app on a host of its own) * Best for: a team that already runs on AWS and wants to choose and size its own database instance. * What it does: RDS runs PostgreSQL on an instance class you pick and bills it in instance hours for as long as it runs; RDS Proxy is a separate pooler, and automated backups restore to any point within the backup retention period. * Pricing: the cheapest instance, db.t4g.micro (2 vCPUs, 1 GiB of memory) in a single Availability Zone, is $0.016 an hour on demand in US East (N. Virginia), about $11.68 over a 730-hour month, plus $0.115 per GB-month of gp3 storage with a 20 GiB minimum, so at least $2.30 ([RDS for PostgreSQL pricing](https://aws.amazon.com/rds/postgresql/pricing/), as of 2026-10-07). RDS Proxy is $0.015 per vCPU-hour of the database instance with a 2-vCPU minimum, so pooling for that instance adds about $21.90 over the same month ([RDS Proxy pricing](https://aws.amazon.com/rds/proxy/pricing/), as of 2026-10-07). T4g instances run in Unlimited mode, so if average CPU over a rolling 24 hours stays above the instance's baseline, AWS adds CPU credits at $0.075 per vCPU-hour on top of those figures. * Trade-offs: the instance bills while it runs whether or not the app is busy, the pooler is a second line on the bill, and the app needs a host of its own. ### App and database on one platform: Prisma, Railway and Render [#app-and-database-on-one-platform-prisma-railway-and-render] Railway and Render also run the app and its Postgres database on one platform, as Railway + Railway Postgres and Render + Render Postgres. Rows are alphabetical by app host; Railway's and Render's cells were checked against their own pages on 2026-10-28, and the database scaling column on 2026-11-06. | Pair | What the app can be | How the database is billed | How the database scales | Preview with its own database | Point-in-time recovery | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Prisma Compute + Prisma Postgres | TypeScript apps built for Node.js, Bun or Next.js; deployed apps run on Bun | By operations and storage: Starter is a $10 base with 1M operations, then $8 per million, with Compute usage metered on top | No instance to size or upgrade: Prisma scales the database for you, and PgBouncer pooling is included on every plan | Once deploy on push is set up, every pushed branch other than the default one gets a preview with its own services and, for databases declared in the Composer module, its own new database, and production data is not copied. A push to the default branch deploys production. If the app reads `DATABASE_URL` rather than a declared database, the preview is only as separate as that value | Paid plans restore a snapshot taken on each day with database activity, in place or into a new database; point-in-time recovery is coming in November 2026 | | Railway + Railway Postgres | Any language Railpack builds with zero configuration, or a Dockerfile; services run continuously by default, WebSocket servers included; with Serverless turned on, a service sleeps 5 to 10 minutes after its last outbound traffic | The Postgres template, which Railway maintains, runs as a service billed per second for the CPU, memory and disk it uses; Hobby is $5 a month and includes $5 of usage | The database service scales up to your plan's vCPU and memory limits by default; you resize its volume, and PgBouncer pooling is opt-in | PR environments, once turned on in project settings, replicate the base environment's services, a database service included, and are deleted when the pull request is merged or closed. With Focused PR Environments (beta) also turned on, only the services whose files changed, and the services they reference, are deployed; in Railway's example, a frontend-only preview reuses the production backend | Opt-in: you turn it on, and the restore window starts from the first base backup after that, not earlier, and grows to roughly 4 weeks. Railway's pricing lists built-in database and volume backups on Pro and Enterprise | | Render + Render Postgres | Node.js, Bun, Python, Ruby, Go, Rust or Elixir, or a Dockerfile; web services on a paid compute plan, private services and background workers run continuously, and web services accept WebSocket connections; a Free web service spins down after 15 minutes without inbound traffic and takes about a minute to spin back up | By compute plan and storage: the smallest paid Render Postgres is $6 a month for 256 MB of RAM and 100 connections, with storage at $0.30 per GB | The compute plan you pick sets CPU and RAM, and changing it makes the database temporarily unavailable; storage can grow on its own if you turn that on, and PgBouncer pooling is opt-in for each paid database, at no extra cost | Preview environments, on a Pro workspace or higher and once `previews.generation` is set to manual or automatic in the `render.yaml` Blueprint, copy the Blueprint's services and datastores for a pull request, without the base datastores' data; in manual mode only pull requests with `[render preview]` in the title get one | On paid databases: the past 3 days on a Hobby workspace, the past 7 days on Pro or higher | ## Growing from 100 to 10,000 users without an infrastructure project [#growth-path-100-1000-and-10000-users] On the database side, the step from 100 to 10,000 users is a plan change: at 20 operations per user per day, Starter covers the database line until Pro ($49, 10M operations) becomes the cheaper plan at about 9,800 users. Plan limits apply to the whole workspace and are shared by its databases, so moving the workspace from Starter to Pro raises the limits for the databases you already have, with no data to migrate, and PgBouncer pooling is included on every plan, so there is no pooler to add. Prisma Postgres autoscales, with no instance to size or upgrade: Prisma scales the database for you as traffic grows. Prisma Postgres has no cold starts, and the plan sets the included operations, storage, connection limits and price. The database line and the metered Compute line are shown separately; add them only with your own numbers. **The database line.** Prisma Postgres counts one operation per query, and the [pricing FAQ](https://www.prisma.io/docs/postgres/faq) estimates a month as `users x operations_per_user_per_day x 30`. Assume 20 operations per user per day, for example four page views that run five queries each, with storage inside each plan's allowance. | Users | Operations a month | Database plan | Database line | | ------ | ------------------ | ------------- | ------------- | | 100 | 60,000 | Starter | $10 | | 1,000 | 600,000 | Starter | $10 | | 5,000 | 3,000,000 | Starter | $26 | | 10,000 | 6,000,000 | Pro | $49 | Starter's 1M included operations divided by 600 a user a month is about 1,700 users, so the line is the base fee until then; past it, each extra million costs $8, so 3M operations are $26. Starter reaches Pro's flat $49 at 5.875M operations a month, about 9,800 users, and Pro's 10M allowance covers the 10,000-user row. Your own queries per page move these thresholds a long way, so rerun the formula with your numbers. **The Compute line, as an example.** Requests and operations are different counts: one page view can be several requests, each running several queries. Suppose those 1,000 users make four page views a day of three requests each, about 360,000 requests a month, inside Starter's 5M. A service awake 12 hours a day at 1 GB uses 360 GB-hours of memory ($2.16); add 20 active vCPU-hours ($1.28) and 20 GB of outbound bandwidth ($0.50), and the meters come to about $4. At 10,000 users, 3.6M requests fit inside Pro's 20M, and a service awake around the clock at 1 GB with 100 vCPU-hours and 200 GB out meters about $16. The signals that you have outgrown a setup are not user counts. Each row pairs what you will see with what it usually means and what to do first. | Signal | What it usually means | Response | | -------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Connection errors under normal load | A client created per request, or app traffic on the direct string | Create one client per process and send app traffic through the pooled string; count every process's pool against Prisma Postgres's limit of 100 pooled connections on Starter or 500 on Pro | | Operations growing faster than users | A loop, or a job that polls the database | Find the query in [Query Insights](https://www.prisma.io/docs/query-insights) on Prisma Postgres, then fix the loop or poll less often | | One slow endpoint | A missing index or a query inside a loop | Find the query with `pg_stat_statements`, or Query Insights on Prisma Postgres; add the index or fix the loop before you spend on anything else | | Queries slow across the whole app as traffic grows | On an instance-based database, the instance is at capacity | On Prisma Postgres there is no instance to size or upgrade, so check Query Insights for the query; on Neon, widen the range it scales within; on Render or Supabase, pick a larger size | | The database line nears Pro's $49 | About 5.9M operations a month at Starter's rates | Move the workspace to Pro, with no data to migrate | | Losing a day of writes would be too much | Prisma Postgres snapshots are too far apart for your data | Run `pg_dump` more often than daily over the direct connection; point-in-time recovery is coming in November 2026, and a database such as Neon, or Supabase with a paid add-on, has it today | | Users far from your region are slow | Distance, which no plan fixes | Measure it with the [region guide](https://www.prisma.io/postgres/nodejs-database-regions), then move the app and the database together; on Prisma Postgres that means a new database in the target region and a `pg_dump -Fc` and `pg_restore` with writes stopped, following the [import guide](https://www.prisma.io/docs/postgres/import-from-existing-database) and checking the restored data before you switch | ## How we compared [#how-we-compared] The criteria are what a small production app needs from a plan: pooling, backups and point-in-time recovery, a spend limit, staging or previews, the starting price, and what the bill does when the app is idle. Prisma figures come from the [pricing page](https://www.prisma.io/pricing) and the docs linked above; the other vendors' figures come from the pages under Sources, checked 2026-10-05, Neon's restore windows again on 2026-10-06, Amazon RDS on 2026-10-07, and the table's any-language and point-in-time recovery rows on 2026-10-08. The provider table that opens the managed Postgres section was checked on 2026-10-30, apart from its Amazon RDS figures, dated 2026-10-07. ## Frequently asked questions [#frequently-asked-questions] ### Can this setup grow without hiring a DevOps person? [#can-this-setup-grow-without-hiring-a-devops-person] Yes. On Prisma Postgres, the step from 100 to 10,000 users is a plan change: there is no instance to size or upgrade, Prisma scales the database for you, and there is no data to migrate. For the app, a managed platform such as Prisma Compute (for TypeScript apps), Render or Railway runs it from your code, so the first 100 paying users need a checklist, not a hire. Someone on the team still owns the growth checklist above, and the setups that do create an operations job include Kubernetes and self-hosted Postgres. ### When should I move off the Starter plan? [#when-should-i-move-off-the-starter-plan] When the database line alone passes about 5.9M operations a month, where Starter's $10 plus $8 per million beyond the first exceeds Pro's flat $49: about 9,800 monthly active users at 20 operations per user per day. Pro also allows five times as many pooled and direct connections as Starter. ### Can I keep paying users on the Free plan? [#can-i-keep-paying-users-on-the-free-plan] The docs describe the Free plan as for evaluation, not production: 200,000 operations a month, no backups and no spend limit to set. The first paying user is the point to move to Starter, where the $10 base buys backups (a snapshot on each day with database activity) and a spend limit before the extra operations matter. ### Does Prisma Postgres have point-in-time recovery? [#does-prisma-postgres-have-point-in-time-recovery] On paid plans, Prisma Postgres restores from daily snapshots today, and point-in-time recovery is coming in November 2026. A snapshot is taken on each day with database activity, kept 7 days on Starter and Pro and 30 on Business, and you restore one from the database's Backups tab in Prisma Console, in place, keeping the same connection strings, or into a new database in the same project; changes made after that snapshot are not in the restored database. Neon restores to a moment on every plan, and Supabase does with a paid add-on. ### Does caching reduce my database bill? [#does-caching-reduce-my-database-bill] It can, because Prisma Postgres counts an operation each time your app reaches the database, so a read served from your app's own cache never counts. Prisma Postgres has no query cache of its own; cached reads can be out of date, so leave permission checks and balances uncached. ## Sources [#sources] * [Railway pricing](https://railway.com/pricing) and the [Serverless setting](https://docs.railway.com/deployments/serverless), checked 2026-10-05. * [Render pricing](https://render.com/pricing), [free instance limits](https://render.com/docs/free) and [connection pooling](https://render.com/docs/postgresql-connection-pooling), checked 2026-10-05. * [Neon pricing](https://neon.com/pricing), checked 2026-10-05, and Neon's [plans page](https://neon.com/docs/introduction/plans) for the instant restore window on each plan, checked 2026-10-06. Neon's [connection guide](https://neon.com/docs/get-started/connect-neon) for connecting from any language or framework, checked 2026-11-02. * [Supabase pricing](https://supabase.com/pricing) and [connecting to Postgres](https://supabase.com/docs/guides/database/connecting-to-postgres), checked 2026-10-05. * [Amazon RDS for PostgreSQL pricing](https://aws.amazon.com/rds/postgresql/pricing/), [RDS Proxy pricing](https://aws.amazon.com/rds/proxy/pricing/) and [restoring to a point in time](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html), checked 2026-10-07. Prices are on-demand in US East (N. Virginia). * The table's WebSocket, language and region rows: Railway's [specs and limits](https://docs.railway.com/networking/public-networking/specs-and-limits) and [Railpack](https://docs.railway.com/builds/railpack), Render's [WebSockets](https://render.com/docs/websocket) and [native runtimes](https://render.com/docs/native-runtimes), and Fly.io's [WebSockets with Next.js](https://fly.io/javascript-journal/websockets-with-nextjs/), [language guides](https://docs.fly.io/languages-and-frameworks/) and [regions](https://docs.fly.io/reference/regions/), checked 2026-10-05. * The table's any-language and point-in-time recovery rows: Railway's [Railpack](https://docs.railway.com/builds/railpack), Render's [native runtimes](https://render.com/docs/native-runtimes), Neon's [instant restore](https://neon.com/docs/postgres/backup-restore/branch-restore) and Supabase's [backups](https://supabase.com/docs/guides/platform/backups), checked 2026-10-08. Prisma Postgres [backups](https://www.prisma.io/docs/postgres/database/backups), the [pricing page](https://www.prisma.io/pricing) and [deploy on push](https://www.prisma.io/docs/compute/deploy-on-push), checked 2026-10-08. * The table's background-worker row: Railway's [services](https://docs.railway.com/services), Render's [background workers](https://render.com/docs/background-workers), Fly.io's [process groups](https://docs.fly.io/launch/processes), and Prisma Compute's [limitations](https://www.prisma.io/docs/compute/limitations) and [keeping instances awake](https://www.prisma.io/docs/compute/keeping-instances-awake), checked 2026-10-24. Render's Postgres price is from [Render pricing](https://render.com/pricing), checked 2026-10-24. The one-bill line in the opening and the TypeScript row is from the Prisma Compute [FAQ](https://www.prisma.io/docs/compute/faq) and the [pricing page](https://www.prisma.io/pricing), checked 2026-10-24. Which Prisma Postgres connection string a worker uses is from [connection pooling](https://www.prisma.io/docs/postgres/database/connection-pooling) and [connecting to your database](https://www.prisma.io/docs/postgres/database/connecting-to-your-database), checked 2026-10-26. * The table of app and database pairs on one platform: Railway's [Railpack](https://docs.railway.com/builds/railpack), [Dockerfiles](https://docs.railway.com/builds/dockerfiles), [services](https://docs.railway.com/services), [WebSockets](https://railway.com/guides/sse-vs-websockets), [PostgreSQL](https://docs.railway.com/databases/postgresql), [pricing](https://railway.com/pricing), [plans](https://docs.railway.com/pricing/plans), [databases](https://docs.railway.com/databases), [point-in-time recovery](https://docs.railway.com/volumes/point-in-time-recovery), [PR environments](https://railway.com/guides/preview-deployments-with-pr-environments) and [environments](https://docs.railway.com/environments); Render's [pricing](https://render.com/pricing), [native runtimes](https://render.com/docs/native-runtimes), [WebSockets](https://render.com/docs/websocket), [background workers](https://render.com/docs/background-workers), [free instances](https://render.com/docs/free), [Postgres backups](https://render.com/docs/postgresql-backups) and [preview environments](https://render.com/docs/preview-environments); and Prisma's [pricing page](https://www.prisma.io/pricing), [Compute FAQ](https://www.prisma.io/docs/compute/faq), [deploy on push](https://www.prisma.io/docs/compute/deploy-on-push) and [backups](https://www.prisma.io/docs/postgres/database/backups), checked 2026-10-28. The plan change at the start of the growth section: the [pricing page](https://www.prisma.io/pricing), the [Prisma Postgres docs](https://www.prisma.io/docs/postgres) and [FAQ](https://www.prisma.io/docs/postgres/faq), the plan limits in the [full-stack tutorial](https://www.prisma.io/docs/full-stack-tutorial) and workspace billing in the [Console concepts](https://www.prisma.io/docs/console/concepts), checked 2026-10-28. The autoscaling line in the growth section: the [operations-based billing post](https://www.prisma.io/blog/operations-based-billing) and the operations, storage, connection limits and price per plan on the [pricing page](https://www.prisma.io/pricing), checked 2026-10-29. The table's database scaling column: Railway's [databases](https://docs.railway.com/databases) and [scaling](https://docs.railway.com/deployments/scaling) pages, Render's [creating and connecting](https://render.com/docs/postgresql-creating-connecting) and [connection pooling](https://render.com/docs/postgresql-connection-pooling) pages, and the [Prisma Postgres docs](https://www.prisma.io/docs/postgres), checked 2026-11-06. * The provider table: Neon's [pricing](https://neon.com/pricing), [autoscaling](https://neon.com/docs/introduction/autoscaling) and [scale to zero](https://neon.com/docs/introduction/scale-to-zero) and [history window](https://neon.com/docs/postgres/backup-restore/history-window) pages; Prisma's [pricing page](https://www.prisma.io/pricing), [Prisma Postgres docs](https://www.prisma.io/docs/postgres) and [backups](https://www.prisma.io/docs/postgres/database/backups); Railway's [databases](https://docs.railway.com/databases), [backups](https://docs.railway.com/volumes/backups), [point-in-time recovery](https://docs.railway.com/volumes/point-in-time-recovery), [plans](https://docs.railway.com/pricing/plans), [pricing](https://railway.com/pricing) and [scaling](https://docs.railway.com/deployments/scaling); Render's [pricing](https://render.com/pricing), [free instances](https://render.com/docs/free), [Postgres backups](https://render.com/docs/postgresql-backups) and [creating and connecting](https://render.com/docs/postgresql-creating-connecting) and [high availability](https://render.com/docs/postgresql-high-availability); and Supabase's [pricing](https://supabase.com/pricing), [backups](https://supabase.com/docs/guides/platform/backups) and [compute and disk](https://supabase.com/docs/guides/platform/compute-and-disk), checked 2026-10-30. The Amazon RDS figures are from the RDS pricing pages listed above, checked 2026-10-07; its [restore](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) and [retention](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.BackupRetention.html) details were checked 2026-10-30. Supabase's recovery add-on in that table was rechecked against its [backups](https://supabase.com/docs/guides/platform/backups) page and [pricing](https://supabase.com/pricing) on 2026-11-06, and the Supabase Free database size and disk against the [database size](https://supabase.com/docs/guides/platform/database-size) docs and [pricing](https://supabase.com/pricing) on 2026-11-12. The Render + Prisma Postgres pair adds Render's [regions](https://render.com/docs/regions) and Prisma's [connection pooling](https://www.prisma.io/docs/postgres/database/connection-pooling), checked 2026-10-30. * The deploy commands: the Prisma CLI's [deploy reference](https://www.prisma.io/docs/cli/deploy) for `--environment` and the `entry` in `prisma.config.ts`, and its [error reference](https://www.prisma.io/docs/cli/error-reference#CONFIG.ENTRY_MISSING), checked 2026-11-09. ## Related guides [#related-guides] If you are still deciding how to persist the prototype's records, start with [hosted Postgres for customer data](https://www.prisma.io/postgres/prototype-customer-data). For records that mix stable fields and changing attributes, see the [customer records and JSONB example](https://www.prisma.io/postgres/customer-records-json). For the person who will operate the app after launch, the [business app operations guide](https://www.prisma.io/compute/business-app-operations) covers account ownership, live-version checks and rehearsed recovery. If data volume is the immediate constraint, the [Postgres storage-growth guide](https://www.prisma.io/postgres/database-storage-growth) shows how to inspect table and index sizes, read storage allowances and prepare the next capacity step. If customer records arrive in spreadsheets, [hosting a spreadsheet import app](https://www.prisma.io/postgres/spreadsheet-import-hosting) covers the import job, retained source files and checks that saved data survives a release. ## Update history [#update-history] * 2026-11-12: the Supabase row of the provider table now says the Free plan's database size is a billing quota and adds that the Free disk is 2 GB. Sources: Supabase's database size docs and pricing page, checked 2026-11-12. * 2026-11-12: the opening, the any-language bullet and row of the quick recommendation, and the FAQ on growing without a DevOps hire now start with the database: Prisma Postgres, with no instance to size or upgrade, and the app on Prisma Compute for TypeScript or on Render or Railway otherwise. The managed Postgres section title adds Railway and Render, and links to it still work. The deploy commands no longer pass `module.ts`, because the CLI reads the entry from `prisma.config.ts`, and staging uses `--environment`, the flag's current name. Sources: the Prisma CLI deploy and error references, checked 2026-11-09. * 2026-11-09: "Spend limits" now says the limit counts usage charges in a billing cycle, not the plan fee. Source: Prisma's [billing docs](https://www.prisma.io/docs/console/more/billing#cap-usage-charges-with-a-spending-limit), checked 2026-11-09. * 2026-11-06: the table of app and database pairs on one platform adds how each database scales: no instance to size or upgrade on Prisma Postgres, the compute plan you pick on Render Postgres, and on Railway a service that scales up to the plan's limits by default, with a volume you resize, plus how each one pools connections. The Supabase row of the provider table no longer says its recovery add-on needs a compute add-on. Sources: Railway's, Render's, Supabase's and Prisma's docs and Supabase's pricing page, checked 2026-11-06. * 2026-11-03: "Buy time, not architecture" now says what to buy by language: Prisma Compute and Prisma Postgres for TypeScript, and Render or Railway with Prisma Postgres, Neon or Supabase for any other language. No facts changed; the Sources list adds Neon's connection guide, checked 2026-11-02. * 2026-10-31: the WebSocket row of the situation table now says support on Prisma Compute is planned for early 2027 and links the guide to running a WebSocket server. Source: that guide, checked 2026-10-31. * 2026-10-31: the managed Postgres section opens with a provider table (starting price, fit at 100 users, scaling path, backups and recovery), and the pairs add Render + Prisma Postgres for an app in any language. The growth section has a table of signals and responses in place of its closing sentence, and says Prisma scales the database for you, with no cold starts. "What not to do yet" gives the early 2027 plan for replicas and links the guide to what a small production app needs from Postgres. The FAQ now covers growing without a DevOps hire, the situation table row for previews names each pushed branch other than the default, and two Railway source links moved to railway.com/guides. Sources: each provider's pricing and docs pages, checked 2026-10-30. * 2026-10-30: the backups check, the recovery row in the first table, Prisma's recovery cell in the app and database pairs table, the recovery FAQ and the Prisma Postgres trade-offs now start with how a snapshot is restored: from Prisma Console in place, which closes open connections while it runs and keeps the connection strings, or into a new database; the Prisma CLI and the REST API can restore in place, and the REST API and the MCP server into a new database. Each then says point-in-time recovery is coming in November 2026, and the recovery row and the trade-offs say snapshots are taken only on days with database activity. Source: the Prisma Postgres backups docs, checked 2026-10-30. * 2026-10-30: "Spend limits" now says a paid plan's spend limit is one you set in the Console, and lists the steps: enter an amount, click Set Limit and confirm with the workspace name. It also says the limit caps usage charges but not the plan fee, and that the workspace's databases stop taking queries when it is reached. Source: Prisma's [billing docs](https://www.prisma.io/docs/console/more/billing#cap-usage-charges-with-a-spending-limit), checked 2026-10-30. * 2026-10-29: the growth section adds that Prisma Postgres autoscales, with no instance to size or upgrade as traffic grows, and what the plan sets. Sources: Prisma's operations-based billing post and pricing page, checked 2026-10-29. * 2026-10-28: the growth section is now titled "Growing from 100 to 10,000 users without an infrastructure project", and links to it still work; it opens with the database step, a plan change from Starter to Pro at about 9,800 users at 20 operations a day, with PgBouncer included and no data to migrate. The managed Postgres section adds a table comparing Prisma Compute + Prisma Postgres with Railway + Railway Postgres and Render + Render Postgres. Sources: Prisma's pricing page and docs, and Railway's and Render's docs and pricing, checked 2026-10-28. * 2026-10-27: the situation table row for a preview per branch and the staging paragraph now say a preview is for each pushed branch other than the default one, and the table row adds that a push to the default branch deploys production. Source: Prisma's deploy-on-push docs, checked 2026-10-27. * 2026-10-27: the section listing the hosting pairs and Amazon RDS is now titled "Managed Postgres hosting for startups (2026): Prisma Postgres, Neon, Supabase and Amazon RDS", and links to it still work. The meta description is shorter and names the app hosts and databases first. No facts changed. * 2026-10-26: the background-worker and Python or Go rows name Prisma Postgres as the database next to Railway, Render or Fly.io for the app, and the worker row says which connection string a worker uses: pooled, or direct for `LISTEN`/`NOTIFY` and queries longer than 10 minutes. Source: the Prisma Postgres connection docs, checked 2026-10-26. * 2026-10-24: the opening and the TypeScript row name one provider, one project and one bill (the $10 Starter base, with Compute usage metered on top); the table has a row for a continuous background worker or queue consumer; the Render entry gives its $6 smallest paid Postgres; the meta title matches the title; the spreadsheet import link moved to Related guides. Sources for the new lines checked 2026-10-24. * 2026-10-22: point-in-time recovery for Prisma Postgres now has a date, November 2026, wherever this post says it is not available yet; until then, paid plans keep daily snapshots. No other facts changed. * 2026-10-22: the backups check links to the guide to recovering deleted records, which shows how to copy rows back from a restored snapshot. * 2026-10-21: the links to the guides on customer data, customer records and business app operations, added on 2026-10-17 and 2026-10-20, moved from below this history to a Related guides section. * 2026-10-14: the opening and the any-language recommendation say that Prisma Postgres works from any language through any Postgres client, and the quick recommendation and the point-in-time recovery row say that Supabase's point-in-time recovery is a paid add-on. * 2026-10-12: the title now reads "Hosting and managed Postgres options for your startup's first 100 paying users (2026)", and the meta description ends on what to add as you scale. * 2026-10-08: the opening names Prisma Compute, Render and Railway for the app and Prisma Postgres, Neon and Supabase for the database, and the note that Prisma Postgres has no point-in-time recovery moved to the backups check. The quick recommendation is now by stack, with a row for apps in any language, and the point-in-time recovery row, the FAQ and this history no longer list Neon's restore windows. Renamed the alternatives section and stated its order, added a same-region check, and described Composer's config as the `composer` section of `prisma.config.ts`. The summary under the title names the same app hosts and databases. * 2026-10-07: the opening now gives the answer first: run the app on a managed platform-as-a-service (PaaS) and the database on managed Postgres with pooling, backups and staging, and Prisma Compute is described as a PaaS for TypeScript apps. Removed the opening sentence that pointed readers who need point-in-time recovery to Neon or Supabase, and the same pointer in the backups check, because the table and the FAQ cover that case. Starter is described as a $10 base with Compute usage metered on top, in place of the earlier plan wording. Added "If you outgrow it" and an Amazon RDS for PostgreSQL entry with RDS Proxy pricing. Removed the Free plan storage figure. * 2026-10-06: Neon's instant restore is on every plan, so the post no longer says it needs a paid plan. Prisma Postgres backups are described as a snapshot on each day with database activity, on paid plans. Added that Prisma Compute has been generally available since August 2026, cut the caching answer to two sentences and shortened the meta title. Removed the line that almost nothing needs to change at 100 paying users, and the failover mentions for a VPS and self-hosted Postgres. * 2026-10-05: rechecked every vendor price against its own page; Neon's Free plan now includes 1 GB of storage per project, up from 0.5 GB, and Supabase's point-in-time recovery is named as a paid add-on. The disclosure now lists what the runners-up do that we do not, with their pages under Sources. Removed the per-plan query timeout and response size figures. Linked the seven-platform comparison and the Compute FAQ's list of trade-offs. * 2026-09-30: retitled around the Starter plan and scoped the user-count arithmetic to the database line; added the situation table, the migrations and staging checks, the alternative pairs with dated Railway, Render, Neon and Supabase prices, the Compute line example, a FAQ, "How we compared", Sources and this history. * 2026-09-24: first published.