blog, answers: a paid plan's spend limit is one you set in the Console, none until you do

apps/blog/content/blog/choosing-hosting-and-postgres-after-your-first-100-users/index.mdx

@@ -2,7 +2,7 @@
 title: "Best hosting and managed Postgres for a startup's first 100 paying users (2026)"
 slug: "choosing-hosting-and-postgres-after-your-first-100-users"
 date: "2026-09-24"
-updatedAt: "2026-10-29"
+updatedAt: "2026-10-30"
 authors:
   - "Gregory Boch"
 metaTitle: "Best hosting and managed Postgres for a startup's first 100 paying users (2026)"
@@ -131,9 +131,12 @@ Composer's `postgres()` dependency and a data contract, the deploy applies your
 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 has one, on by default, capping what you are charged in a billing
-cycle. Check where yours is set and what happens when it is reached, because a cap that stops a
-production database trades an invoice for downtime. Loops are what make operations climb: a job
+**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 caps 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.
@@ -418,6 +421,12 @@ If customer records arrive in spreadsheets, [hosting a spreadsheet import app](h
 
 ## Update history
 
+- 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.

apps/blog/content/blog/prisma-compute-generally-available/index.mdx

@@ -2,7 +2,7 @@
 title: "Prisma Compute is now GA"
 slug: "prisma-compute-generally-available"
 date: "2026-08-26"
-updatedAt: "2026-10-27"
+updatedAt: "2026-10-30"
 authors:
   - "Søren Bramer Schmidt"
 metaTitle: "Prisma Compute is now generally available"
@@ -135,7 +135,7 @@ The [Bun SQL hosting guide](https://www.prisma.io/postgres/bun-sql-hosting) expl
 
 Three things changed since the beta that may need something from you, and the rest you get without doing anything.
 
-**Usage is now billed.** The rates are unchanged from the ones we published with the beta, and the next section walks through them. Every paid plan has a hard spend limit, on by default, which you can change in the Console, and the Free plan has no usage billing.
+**Usage is now billed.** The rates are the same as the ones we published with the beta, and the next section walks through them. Every paid plan includes a hard spend limit you set in the Console, with none until you set one, and the Free plan has no usage billing.
 
 **Builds moved into your GitHub Actions.** During the beta, Prisma built your app on its own servers when you pushed. Those builds are deprecated, and a beta project still using them shows a notice in the Console with its cutoff date and a button that opens the setup pull request, which you need to *merge before the cutoff*. For a new project, the Console opens that pull request as part of connecting the repository.
 
@@ -170,7 +170,7 @@ Compute meters four things: requests beyond your plan's allowance at $1 per mill
 
 **The Free plan needs no credit card and is never billed.** When a Free workspace passes one of its limits, its apps pause until the next month or until you upgrade, so on the Free plan the cost of a traffic spike is downtime rather than a charge.
 
-**Paid plans bill instead of pausing.** Requests beyond the allowance cost $1 per million, and the spend limit caps what you can be charged in a billing cycle. Moving to a paid plan also drops the included memory, CPU, and bandwidth: those three meters are billed from the first unit.
+**Paid plans bill instead of pausing.** Requests beyond the allowance cost $1 per million, and a [spend limit](https://www.prisma.io/docs/console/more/billing#cap-usage-charges-with-a-spending-limit), once you set one, caps the usage charges in a billing cycle. Moving to a paid plan also drops the included memory, CPU, and bandwidth: those three meters are billed from the first unit.
 
 The fee pays for the larger request and database-operation allowances and for daily backups, and on Pro and Business, the SLA. Enterprise plans are priced on request, and the [pricing page](https://www.prisma.io/pricing) lists Prisma Postgres storage and overage rates.
 
@@ -231,3 +231,7 @@ Compute is open to everyone on the Free plan.
 </Button>
 
 Tell us what you build, and what gets in the way, in the `prisma-compute` channel on the [Prisma Discord](https://pris.ly/discord).
+
+## Update history
+
+- 2026-10-30: "What changed since the public beta" and "You pay for what your app runs" now say a paid plan's hard spend limit is one you set in the Console, with none until you set one, and that it caps usage charges in a billing cycle. Source: Prisma's [billing docs](https://www.prisma.io/docs/console/more/billing#cap-usage-charges-with-a-spending-limit), checked 2026-10-30.

apps/blog/content/blog/prisma-vs-netlify/index.mdx

@@ -2,7 +2,7 @@
 title: "Netlify alternatives for a full-stack TypeScript app with Postgres (2026)"
 slug: "prisma-vs-netlify"
 date: "2026-09-16"
-updatedAt: "2026-10-28"
+updatedAt: "2026-10-30"
 authors:
   - "Shane Neubauer"
 metaTitle: "Netlify alternatives for a full-stack TypeScript app with Postgres (2026)"
@@ -45,7 +45,7 @@ better, and the last column says why.
 | Next.js SaaS with Postgres | Prisma Compute + Prisma Postgres; or Vercel + a Marketplace Postgres (Prisma Postgres, Neon or Supabase) when a global CDN matters | Compute runs the Next.js server next to the database; Vercel serves from its CDN and runs functions |
 | Express, Hono or NestJS API with a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server | Prisma Compute + Prisma Postgres; Railway; Render | Compute runs the whole HTTP server as an instance next to the database; Railway and Render run any long-lived process |
 | MVP on a free plan | Prisma Free (app and database, no usage billing, no credit card); Neon Free or Supabase Free when you need only the database | Prisma Free includes Compute plus 200,000 database operations a month, 2 GB of storage and 50 databases; Neon Free has 1 GB of storage per project; Supabase Free has a 500 MB database and pauses projects after a week of inactivity; Railway's Free plan gives $1 of credit a month after a 30-day trial with $5 of credit, with up to 1 vCPU and 0.5 GB RAM per service and 0.5 GB of volume storage; Render's free Postgres expires 30 days after creation; Fly.io has no free tier for new organizations, and new accounts get a trial of up to 2 hours of Machine runtime or 7 days, whichever comes first |
-| Usage-based bill you need to cap | Prisma Compute + Prisma Postgres; or Railway with a hard usage limit set | Every paid Prisma plan has a hard spend limit, on by default, and Starter is a $10 base with Compute usage metered on top; Prisma Free has no usage billing; Railway bills CPU, memory and disk per second and takes workloads offline once usage passes a hard limit you set; Vercel's Spend Management, on Pro, limits only part of the bill: it does not stop usage unless Pause Production Deployments is turned on, it does not cover Marketplace integrations such as a Marketplace Postgres, pausing stops only production deployments while storage charges continue, and it checks usage every few minutes |
+| Usage-based bill you need to cap | Prisma Compute + Prisma Postgres with a spend limit set; or Railway with a hard usage limit set | Every paid Prisma plan includes a hard spend limit you set in the Console, with none until you set one; it covers usage charges, not the plan fee, and Starter is a $10 base with Compute usage metered on top; Prisma Free has no usage billing; Railway bills CPU, memory and disk per second and takes workloads offline once usage passes a hard limit you set; Vercel's Spend Management, on Pro, limits only part of the bill: it does not stop usage unless Pause Production Deployments is turned on, it does not cover Marketplace integrations such as a Marketplace Postgres, pausing stops only production deployments while storage charges continue, and it checks usage every few minutes |
 | Realtime app holding WebSocket connections, or background workers | Render, Railway or Fly.io | All three run WebSocket servers and always-on workers; Vercel Functions accept WebSocket connections (generally available since 2026-10-20), which close when the function reaches its maximum duration, and Vercel Daemons (public beta on all plans since 2026-10-15) run background workers from a container image, only in production during the beta; Compute does not run WebSocket servers, and its background work runs after a request under `waitUntil` |
 | Several regions | Fly.io | One Fly.io app can run in several regions at once; each Compute service runs in one region |
 | Mostly static pages and assets, with functions on the side | Stay on Netlify | Its edge network serves them |
@@ -78,10 +78,11 @@ app changes shape, and the reasons repeat:
   extension sets it. Netlify Database, billed from the same credits as the site, removes that split.
 - **The bill stopped being predictable.** Credit-based metering is hard to forecast before you have
   traffic, and easy to misread after. Usage-metered hosts differ in how they cap the bill: every paid
-  Prisma plan has a hard spend limit, on by default; Railway takes workloads offline once usage passes
-  a hard limit you set; and Vercel's Spend Management does not stop usage unless Pause Production
-  Deployments is turned on, does not cover Marketplace integrations such as a Marketplace Postgres,
-  and pauses only production deployments. Price your own traffic on each one before you move.
+  Prisma plan includes a hard spend limit you set in the Console, which covers usage charges, not the
+  plan fee; Railway takes workloads offline once usage passes a hard limit you set; and Vercel's Spend
+  Management does not stop usage unless Pause Production Deployments is turned on, does not cover
+  Marketplace integrations such as a Marketplace Postgres, and pauses only production deployments.
+  Price your own traffic on each one before you move.
 - **Node.js was assumed.** If your stack moved to Bun, or you want to, the runtime is fixed: Netlify
   Functions run on Node.js, and Edge Functions run on Deno.
 
@@ -462,6 +463,7 @@ Prisma ORM works with Netlify Database, which is PostgreSQL built on Neon, and i
 
 ## Update history
 
+- 2026-10-30: the "Usage-based bill you need to cap" row and "Why teams leave Netlify" now say a paid Prisma plan's hard spend limit is one you set in the Console, with none until you set one, and that it covers usage charges, not the plan fee, checked against Prisma's [billing docs](https://www.prisma.io/docs/console/more/billing#cap-usage-charges-with-a-spending-limit) on 2026-10-30.
 - 2026-10-28: the first row of "Pick by app type" now leads with what Prisma Compute and Prisma Postgres give together (one project, one provider, one bill; a Free plan with no credit card; a hard spend limit included in every paid plan; once deploy on push is set up, a preview for each pushed branch other than the default one, with its own services and, for databases declared in the Composer module, its own new database; production data is not copied), and the Compute WebSocket limit moved out of that row, staying in the realtime row, the feature-parity table, "Runtime limits" and the FAQ; the realtime row adds WebSockets in Vercel Functions (generally available since 2026-10-20) and Vercel Daemons (public beta since 2026-10-15, production only during the beta); the Prisma profile is best for an app and its database from one provider, in one project, on one bill, with any Postgres client; the Railway profile is best for an app with a Dockerfile or in a language Railpack builds with zero configuration, WebSocket servers included, next to the Postgres template Railway maintains. Checked against Prisma's [pricing](https://www.prisma.io/pricing), [deploy-on-push docs](https://www.prisma.io/docs/compute/deploy-on-push) and [Compute FAQ](https://www.prisma.io/docs/compute/faq), Railway's [Railpack](https://docs.railway.com/builds/railpack), [Dockerfiles](https://docs.railway.com/builds/dockerfiles), [SSE vs WebSockets](https://docs.railway.com/guides/sse-vs-websockets) and [PostgreSQL](https://docs.railway.com/databases/postgresql) docs, and Vercel's [WebSockets](https://vercel.com/docs/functions/websockets) and [Daemons](https://vercel.com/docs/daemons) docs and changelogs on 2026-10-28.
 - 2026-10-27: "Previews and their databases" now opens by saying both platforms can give a running preview to every branch other than the production branch, and says that with Composer the deploy action deploys each pushed branch other than the default one as a stage, checked against Prisma's [deploy-on-push docs](https://www.prisma.io/docs/compute/deploy-on-push) and Netlify's [branch deploys docs](https://docs.netlify.com/deploy/deploy-types/branch-deploys/) on 2026-10-27.
 - 2026-10-26: the Prisma profile says Prisma Compute has been generally available since 2026-08-28, checked against the [Prisma changelog](https://www.prisma.io/changelog) on 2026-10-26; the Vercel profile and the Vercel runtime cell of the feature-parity table add Vercel Daemons (public beta since 2026-10-15, all plans), which run long-running background workers from a container image, only in production during the beta and with no inbound HTTP, checked against Vercel's [Daemons docs](https://vercel.com/docs/daemons), [changelog](https://vercel.com/changelog/vercel-daemons-is-now-in-public-beta) and [Functions, containers and Daemons guide](https://vercel.com/kb/guide/vercel-functions-containers-daemons) on 2026-10-26.