diff --git a/apps/blog/content/blog/app-hosting-platforms-with-managed-postgres-2026/index.mdx b/apps/blog/content/blog/app-hosting-platforms-with-managed-postgres-2026/index.mdx index cdba68c3cd..57005b5aad 100644 --- a/apps/blog/content/blog/app-hosting-platforms-with-managed-postgres-2026/index.mdx +++ b/apps/blog/content/blog/app-hosting-platforms-with-managed-postgres-2026/index.mdx @@ -49,7 +49,7 @@ Rows in alphabetical order; we make Prisma Compute and Prisma Postgres. | **Fly.io** | In one organization: Managed Postgres runs in the organization's private network and is attached to an app | Per pull request via GitHub Actions; no database in the guide | Autostop; no CPU or RAM charge while stopped | Per organization | Included | Automated backups; point-in-time restore with `fly mpg restore --pitr-time` | pgvector; PostGIS if enabled at provisioning | $2.19 Machine + $38 Managed Postgres a month, plus $0.28 per GB of database storage ([Fly.io pricing](https://fly.io/pricing), as of October 2026) | `pg_dump` | | **Neon** | Backend functions next to the database (Neon Functions, four AWS regions); UI on another host | Copy-on-write branch with the parent's data | Scales to zero after 5 minutes; no base fee | Functions in the database's region; UI depends on its host | PgBouncer, `-pooler` string | Instant restore on every plan, window set by plan | pgvector, PostGIS, TimescaleDB (Apache-2 features) and more | Free $0; Launch $0.106 per CU-hour for the database; Functions billed separately on paid plans (on Launch: $0.10 active and $0.025 waiting per Capacity-Hour, $0.60 per million invocations); plus your UI host ([Neon pricing](https://neon.com/pricing) and [plans](https://neon.com/docs/introduction/plans), as of October 2026) | `pg_dump` | | **Prisma Compute + Prisma Postgres** | Yes; TypeScript on Bun, no WebSocket servers | Per pushed branch once deploy on push is set up: its own services and a new database for each one the module declares; production data not copied | App scales to zero; database per operation | One of six regions per service | PgBouncer included | Daily snapshots on paid plans, 7 or 30 days; no PITR | pgvector, pg_search, pg_trgm and other standard extensions; no PostGIS or TimescaleDB | Free: app and database, no usage billing. Starter $10 base, 5M requests and 1M operations included, memory, active vCPU and bandwidth metered ([Prisma pricing](https://www.prisma.io/pricing), as of September 2026) | `pg_dump`; the Composer module is a TypeScript file in your repo, not a runtime | -| **Railway** | Yes, a Postgres template Railway maintains; backups, PITR, HA and pooling opt-in | Per pull request | Sleeps 5 to 10 minutes after last outbound traffic with Serverless enabled; otherwise runs all month | Per environment | PgBouncer add-on you enable on the Postgres service | Volume backups by hand or on a schedule you turn on; opt-in PITR for Postgres, about 4 weeks | None added to the default template; pgvector, PostGIS and TimescaleDB as separate templates | Free $0 with $1 of credit a month after a 30-day trial; Hobby $5 with $5 of usage, then $10 per GB RAM and $20 per vCPU a month ([Railway pricing](https://railway.com/pricing) and [plan reference](https://docs.railway.com/reference/pricing/plans), as of October 2026) | `pg_dump` | +| **Railway** | Yes, a Postgres template Railway maintains; backups, PITR, HA and pooling opt-in | Per pull request, once turned on in project settings | Sleeps 5 to 10 minutes after last outbound traffic with Serverless enabled; otherwise runs all month | Per environment | PgBouncer add-on you enable on the Postgres service | Volume backups by hand or on a schedule you turn on; opt-in PITR for Postgres, about 4 weeks | None added to the default template; pgvector, PostGIS and TimescaleDB as separate templates | Free $0 with $1 of credit a month after a 30-day trial; Hobby $5 with $5 of usage, then $10 per GB RAM and $20 per vCPU a month ([Railway pricing](https://railway.com/pricing) and [plan reference](https://docs.railway.com/reference/pricing/plans), as of October 2026) | `pg_dump` | | **Render** | Yes, managed | Per pull request on the Pro workspace ($25 a month); no data copied | Free spins down after 15 minutes; paid runs all month | Per region | PgBouncer on paid databases | PITR on paid databases, 3 or 7 days | pgvector, PostGIS, TimescaleDB (no Community features) and more | $7 web service + $6 Postgres a month ([Render pricing](https://render.com/pricing), as of September 2026) | `pg_dump` | | **Supabase** | Backend only (Edge Functions) | Per pull request; no production data by default | Free pauses after a week idle; paid runs all month | Depends on your app host | Shared pooler; dedicated on paid plans | Daily, 7 days on Pro; PITR add-on $100 a month | Over 50 preconfigured, including pgvector and PostGIS | Free $0; Pro from $25 a month, plus your app host ([Supabase pricing](https://supabase.com/pricing), as of September 2026) | `pg_dump` | | **Vercel + Marketplace database** | No; Marketplace database | Preview per push; a database per preview depends on the integration | Functions per use; database on its own plan | Depends on the database region | From the provider | From the provider | From the provider | Hobby $0; Pro $20 a month plus the database plan ([Vercel pricing](https://vercel.com/pricing), as of September 2026) | `pg_dump` | @@ -146,7 +146,7 @@ Each entry has the same headings, and each competitor ends with how it compares **Pricing:** Free $0 with 500 MB and no backups; Pro from $25 a month with daily backups kept 7 days; the PITR add-on is $100 a month per 7 days of retention and needs at least Small compute. [Supabase pricing](https://supabase.com/pricing), as of September 2026. -**Trade-offs:** two bills, and the direct connection is IPv6 unless you buy the IPv4 add-on. +**Trade-offs:** a second host for the app, and a second bill unless the app runs on Vercel and you create the Supabase project from the Vercel Marketplace, which bills it through your Vercel account; the direct connection is IPv6 unless you buy the IPv4 add-on. **Compare:** [Switch from Supabase to Prisma Postgres](https://www.prisma.io/docs/guides/switch-to-prisma-postgres/from-supabase). @@ -162,7 +162,7 @@ Each entry has the same headings, and each competitor ends with how it compares **Pricing:** Hobby $0; Pro $20 a month with $20 of usage credit and one developer seat, active CPU from $0.128 per hour, plus the database plan. [Vercel pricing](https://vercel.com/pricing), as of September 2026. -**Trade-offs:** two products, two bills, and a database per preview depends on the integration. +**Trade-offs:** two products, though a database you create from the Marketplace bills through your Vercel account, and a database per preview depends on the integration. **Compare:** [Prisma vs Vercel](/prisma-vs-vercel) and [Prisma Compute vs Vercel pricing](/prisma-compute-vs-vercel-pricing). @@ -172,7 +172,7 @@ Each entry has the same headings, and each competitor ends with how it compares Four of the seven host the app and the database with one vendor: Prisma Compute with Prisma Postgres, Railway and Render in one project, and Fly.io in one organization, where a Managed Postgres cluster runs in the organization's private network and is attached to an app. On Railway, Render and Fly.io the database is a resource next to the app, read from a connection string. On Prisma it is a dependency the service declares in its Composer module: the deploy provisions it and hands the service the connection, typed and migrated before the service starts when declared with `postgres()` and a Prisma ORM contract, a plain URL you migrate yourself when declared with `rawPostgres()`. The cost is a declaration in the repo and a TypeScript-only runtime; the return is that production and every preview branch get the same wiring. -Supabase and Neon run backend code next to the data. Supabase does not host frontends (its Compute private alpha runs backend services), and Neon's full-stack guide keeps the UI on Vercel, Netlify or another frontend host, so a web app on either has two hosts and two bills. Vercel is the app host, with the database from a Marketplace provider. +Supabase and Neon run backend code next to the data. Supabase does not host frontends (its Compute private alpha runs backend services), and Neon's full-stack guide keeps the UI on Vercel, Netlify or another frontend host, so a web app on either has two hosts, and two bills unless the frontend runs on Vercel and you create the database from the Vercel Marketplace, which bills it through your Vercel account. Vercel is the app host, with the database from a Marketplace provider. ### Considering Neon but want app hosting too? @@ -192,7 +192,7 @@ Four things decide whether the database keeps up when traffic grows. - **Your API holds WebSocket connections open.** Fly.io, Railway, Render and Neon Functions run those; Prisma Compute does not. - **You are not writing TypeScript.** Prisma Compute runs TypeScript on Bun; a Python or Go API belongs on Railway, Render, Fly.io or a VPS. - **You need more than one region, or point-in-time recovery today.** Each Prisma Compute service runs in one of six regions, and Prisma Postgres has no PITR yet. -- **You want the repository deployed with no declaration.** Railway, Render and Fly.io build the code as it is; Prisma needs a Composer declaration and two changes to each Node.js or Bun server, three if it talks to Postgres. +- **You want the repository deployed with no declaration.** Railway and Render build the code as it is, and on Fly.io `fly launch` writes a `fly.toml` and, for most languages and frameworks including Node.js, a Dockerfile into the repository for you to keep; Prisma needs a Composer declaration and two changes to each Node.js or Bun server, three if it talks to Postgres. - **Your frontend's main requirement is a global CDN.** Put it on Vercel with Prisma Postgres or another Marketplace database. The full list of limits lives in one place, [Where it has trade-offs](https://www.prisma.io/docs/compute/faq#where-it-has-trade-offs) in the Prisma Compute FAQ. @@ -234,3 +234,4 @@ Neon (every plan), Railway (opt-in), Render (paid databases), Fly Managed Postgr - 2026-10-12: the Fly.io row now says Managed Postgres runs in the organization's private network and is attached to an app, instead of putting app and database in one project; the Fly.io Machine price changed from $1.94 to $2.19 a month after Fly.io's price update of 2026-10-01, and Managed Postgres storage ($0.28 per GB) is listed; Neon Functions charges are listed apart from the database's CU-hour price; porting steps now say the port and `process.env` changes apply to each Node.js or Bun server and the Postgres client change only to a server that talks to Postgres, while a Next.js app uses the `nextjs` build adapter with `output: 'standalone'`, whose server binds the port itself. - 2026-10-14: the Railway price cell now lists Railway's Free plan ($0 with $1 of credit a month after a 30-day trial), and the Railway backups cell says volume backups are taken by hand or on a schedule you turn on; the Neon Functions Free allowance is now stated per project; Railway's pricing page and docs and Neon's pricing and plans pages were checked on 2026-10-14. - 2026-10-19: the Supabase section and the one-vendor paragraph now say Supabase Compute, which runs backend services, is a private alpha (us-west-2 only, not for production), checked against supabase.com/compute on 2026-10-19. +- 2026-10-19: the Railway previews cell now says PR environments must be turned on in project settings; the Fly.io line in "Where Prisma is the wrong choice" says `fly launch` writes a `fly.toml` and, for most languages and frameworks, a Dockerfile into the repository; the Supabase and Vercel trade-offs and the one-vendor paragraph no longer say two bills when the app runs on Vercel and the database is created from the Vercel Marketplace, which bills it through the Vercel account; checked against Railway's, Fly.io's and Vercel's docs on 2026-10-19. diff --git a/apps/blog/content/blog/host-a-test-version-without-replacing-production/index.mdx b/apps/blog/content/blog/host-a-test-version-without-replacing-production/index.mdx index 524341d8cb..37d66e41c9 100644 --- a/apps/blog/content/blog/host-a-test-version-without-replacing-production/index.mdx +++ b/apps/blog/content/blog/host-a-test-version-without-replacing-production/index.mdx @@ -2,7 +2,7 @@ title: "How to host a test version of your app without replacing production (2026)" slug: "host-a-test-version-without-replacing-production" date: "2026-10-15" -updatedAt: "2026-10-16" +updatedAt: "2026-10-19" authors: - "Gregory Boch" metaTitle: "How to host a test version of your app without replacing production (2026)" @@ -133,7 +133,7 @@ A 6.5-minute walkthrough of this workflow on Prisma Compute and Prisma Postgres: - **Test version:** preview environments, on a Pro workspace plan or higher, copy the services, datastores and environment groups defined in your Blueprint (`render.yaml`) for each pull request (in manual mode, only for pull requests whose title includes `[render preview]`), and delete the copy when the pull request is merged or closed. Set a `previewValue` on environment variables that hold production values, such as an API key, so the preview uses a test value, and check which environment groups the preview copies. Service previews instead create a temporary instance of a single service per pull request, at its own `onrender.com` URL; the instance copies the base service's settings, including environment variables such as database connection information, so change those on the preview instance. - **Database:** datastore copies in a preview environment do not include data from the production resource; Render's docs suggest seeding sample data while the preview environment initializes. -- **Staging:** a Render project can hold separate environments such as staging and production, with environment-scoped variables and an option to block private network traffic between environments. Hobby workspaces can have up to two environments per project. +- **Staging:** a Render project can hold separate environments such as staging and production, with environment-scoped variables and, on a Pro workspace or higher, an option to block private network traffic between environments. Hobby workspaces can have up to two environments per project. ### Vercel @@ -188,3 +188,4 @@ Make production deploy only from the main branch, protect that branch in GitHub - 2026-10-15: first published; every vendor detail was checked against the vendor's docs on 2026-10-15. - 2026-10-16: added that GitHub branch protection in a private repository needs a paid plan, and that a pull request GitHub Copilot opens for you needs a second approver, checked against GitHub's docs on 2026-10-16; step 4 now says previews have to be set up on the host first. - 2026-10-16: added a video walkthrough of the workflow on Prisma Compute and Prisma Postgres. +- 2026-10-19: the Render staging line now says blocking private network traffic between environments needs a Pro workspace or higher, checked against Render's pricing page on 2026-10-19. diff --git a/apps/blog/content/blog/neon-vs-prisma-postgres-app-hosting-in-one-place/index.mdx b/apps/blog/content/blog/neon-vs-prisma-postgres-app-hosting-in-one-place/index.mdx index 033e46f8ad..69101dbe47 100644 --- a/apps/blog/content/blog/neon-vs-prisma-postgres-app-hosting-in-one-place/index.mdx +++ b/apps/blog/content/blog/neon-vs-prisma-postgres-app-hosting-in-one-place/index.mdx @@ -2,7 +2,7 @@ title: "Neon alternatives with app hosting and Postgres in one place (2026): Prisma Postgres + Prisma Compute, Railway, Render and Supabase compared" slug: "neon-vs-prisma-postgres-app-hosting-in-one-place" date: "2026-09-24" -updatedAt: "2026-10-14" +updatedAt: "2026-10-19" authors: - "Gregory Boch" metaTitle: "Neon alternatives with app hosting and Postgres in one place (2026): Prisma, Railway, Render, Supabase" @@ -68,7 +68,7 @@ The [comparison table](#how-the-four-compare-with-neon) uses these ten criteria, 2. **Railway** - Best for: deploying the repository you have, in any language, next to a Postgres template Railway maintains. - - What it does: builds your services from GitHub and deploys Postgres from a template into the same project; [Railway maintains the template](https://docs.railway.com/databases/postgresql), and backups, point-in-time recovery, high availability and PgBouncer pooling are [opt-in](https://docs.railway.com/databases#what-railway-manages) (Railway docs, checked 2026-10-08). [PR environments](https://docs.railway.com/guides/environments) open and close with the pull request. + - What it does: builds your services from GitHub and deploys Postgres from a template into the same project; [Railway maintains the template](https://docs.railway.com/databases/postgresql), and backups, point-in-time recovery, high availability and PgBouncer pooling are [opt-in](https://docs.railway.com/databases#what-railway-manages) (Railway docs, checked 2026-10-08). [PR environments](https://docs.railway.com/guides/environments), once turned on in project settings, open and close with the pull request. - Pricing: Free $0 with $1 of monthly usage credit, or a one-time $5 trial credit; Hobby $5 a month with $5 of usage, Pro $20 with $20; then about $10 per GB of memory and $20 per vCPU a month, $0.15 per GB of volume and $0.05 per GB of egress. [Railway pricing](https://railway.com/pricing), as of September 2026. - Trade-offs: [backups](https://docs.railway.com/reference/backups) are volume snapshots you take by hand or schedule yourself in the service's Backups tab, and [point-in-time recovery](https://docs.railway.com/volumes/point-in-time-recovery) is opt-in: it archives WAL with pgBackRest and restores into a new service. [PgBouncer](https://docs.railway.com/databases/postgresql-pgbouncer) is also opt-in, an **Add PgBouncer** control in the database's connection pooling settings rather than on by default. - Compare: [Where to host a TypeScript frontend, a Node API and Postgres](/where-to-host-typescript-frontend-node-api-postgres). @@ -99,8 +99,8 @@ The [comparison table](#how-the-four-compare-with-neon) uses these ten criteria, | | Neon | Prisma Postgres + Compute | Railway | Render | Supabase | | --- | --- | --- | --- | --- | --- | | Who runs the database | Neon: [serverless Postgres](https://neon.com/docs/introduction) with instant restore | Prisma: [managed PostgreSQL 17](https://www.prisma.io/docs/postgres) with PgBouncer pooling, [daily snapshots on paid plans](https://www.prisma.io/docs/postgres/database/backups) and no point-in-time recovery yet | Railway: it [maintains its Postgres template](https://docs.railway.com/databases/postgresql); backups, point-in-time recovery, high availability and PgBouncer pooling are [opt-in](https://docs.railway.com/databases#what-railway-manages) (checked 2026-10-08) | Render: [fully managed Render Postgres](https://render.com/docs/postgresql) | Supabase: a [full Postgres database per project](https://supabase.com/docs/guides/database/overview), with daily backups on paid plans | -| Previews and branching | [Copy-on-write branch](https://neon.com/docs/introduction/branching) with the parent's data; [Functions](https://neon.com/docs/compute/functions/overview) deploy per branch | With [deploy on push](https://www.prisma.io/docs/compute/deploy-on-push) set up, a preview per pushed branch with its own services and, for databases declared in the Composer module, its own new database; production data is not copied, and if the app reads `DATABASE_URL`, the preview is only as separate as that value; [migrations](https://www.prisma.io/docs/composer/databases) run on deploy or by you | [PR environment](https://docs.railway.com/guides/environments) per pull request | [Per-PR preview](https://render.com/docs/preview-environments) on Pro workspaces; datastores start empty | [Branch per pull request](https://supabase.com/docs/guides/deployment/branching) on Pro or higher; no production data by default | -| Idle cost and scale to zero | [Suspends after 5 minutes](https://neon.com/pricing); no base fee on paid plans | [Scales to zero](https://www.prisma.io/docs/compute/pricing); the database bills per operation; $0 on Free | Bills while running; [Serverless](https://docs.railway.com/reference/app-sleeping) sleeps a service between requests | [Free service spins down](https://render.com/docs/free) after 15 minutes; paid instances bill monthly | [Free projects pause](https://supabase.com/pricing) after a week idle; paid compute bills hourly | +| Previews and branching | [Copy-on-write branch](https://neon.com/docs/introduction/branching) with the parent's data; [Functions](https://neon.com/docs/compute/functions/overview) deploy per branch | With [deploy on push](https://www.prisma.io/docs/compute/deploy-on-push) set up, a preview per pushed branch with its own services and, for databases declared in the Composer module, its own new database; production data is not copied, and if the app reads `DATABASE_URL`, the preview is only as separate as that value; [migrations](https://www.prisma.io/docs/composer/databases) run on deploy or by you | [PR environment](https://docs.railway.com/guides/environments) per pull request, once turned on in project settings | [Per-PR preview](https://render.com/docs/preview-environments) on Pro workspaces; datastores start empty | [Branch per pull request](https://supabase.com/docs/guides/deployment/branching) on Pro or higher; no production data by default | +| Idle cost and scale to zero | [Suspends after 5 minutes](https://neon.com/pricing); no base fee on paid plans | [Scales to zero](https://www.prisma.io/docs/compute/pricing); the database bills per operation; $0 on Free | Bills while running; with [Serverless](https://docs.railway.com/reference/app-sleeping) on, a service sleeps 5 to 10 minutes after its last outbound traffic | [Free service spins down](https://render.com/docs/free) after 15 minutes; paid instances bill monthly | [Free projects pause](https://supabase.com/pricing) after a week idle; paid compute bills hourly | | Same-region networking | Functions in [four AWS regions](https://neon.com/docs/compute/functions/overview) next to the branch's data | [Six regions](https://www.prisma.io/docs/compute/limitations) shared with [Prisma Postgres](https://www.prisma.io/docs/postgres/faq) | [Four regions](https://docs.railway.com/reference/regions), chosen per service | [Five regions](https://render.com/docs/regions), a private network in each | Edge Functions run near the user unless you [pin a region](https://supabase.com/docs/guides/functions/regional-invocation) | | Connection pooling | [PgBouncer](https://neon.com/docs/connect/connection-pooling) via the `-pooler` endpoint | [PgBouncer per database](https://www.prisma.io/docs/postgres/database/connection-pooling), pooled and direct strings | [Add PgBouncer](https://docs.railway.com/databases/postgresql-pgbouncer) control in the database's connection pooling settings; off by default | [Built-in PgBouncer](https://render.com/docs/postgresql-connection-pooling) on paid databases, opt in | [Shared pooler](https://supabase.com/docs/guides/database/connecting-to-postgres); dedicated pooler on paid plans | | Backups and PITR | [Instant restore](https://neon.com/pricing) within the plan's history window; history at $0.20 per GB-month on paid plans | [Daily snapshots on paid plans](https://www.prisma.io/docs/postgres/database/backups), kept 7 or 30 days; no PITR yet | [Volume backups](https://docs.railway.com/reference/backups), by hand or on a schedule you set up; [opt-in PITR](https://docs.railway.com/volumes/point-in-time-recovery) archives WAL and restores into a new service | [PITR on paid databases](https://render.com/docs/postgresql-backups): 3 days on Hobby, 7 on Pro; none on Free | [Daily backups](https://supabase.com/docs/guides/platform/backups) kept 7 days on Pro; PITR add-on from $100 a month | @@ -155,6 +155,7 @@ It depends on whether your bill should follow queries or uptime. Neon bills CU-h - Vercel: [pricing](https://vercel.com/pricing) and [Marketplace storage](https://vercel.com/docs/marketplace-storage). Fly.io: [regions](https://docs.fly.io/reference/regions/). ## Update history +- 2026-10-19: the Railway entry and the previews row now say PR environments must be turned on in project settings, and the idle-cost row says Railway's Serverless setting sleeps a service 5 to 10 minutes after its last outbound traffic, not between requests, checked against Railway's docs on 2026-10-19. - 2026-10-14: added a first situation-table row for a frontend, API and Postgres in one project and an FAQ on whether Supabase hosts the app; the idle-cost row now says the Free plan has no usage billing, that on paid plans Prisma Postgres bills per operation on top of the plan fee and any storage beyond the included amount, which still bill while idle, and that Neon's paid plans bill compute by the CU-hour and still bill storage and restore history while compute is suspended. - 2026-10-08: moved Prisma's recovery and preview-data trade-off from the opening to the line under the situation table, rechecked the Railway and Neon entries against their docs, added a checklist of what to compare before leaving Neon with matching extensions and observability rows, put the comparison table's vendors in alphabetical order, and added the compared vendors to the page title. diff --git a/apps/blog/content/blog/prisma-postgres-vs-neon-pricing-2026/index.mdx b/apps/blog/content/blog/prisma-postgres-vs-neon-pricing-2026/index.mdx index d27232c373..31ea6b7f26 100644 --- a/apps/blog/content/blog/prisma-postgres-vs-neon-pricing-2026/index.mdx +++ b/apps/blog/content/blog/prisma-postgres-vs-neon-pricing-2026/index.mdx @@ -2,7 +2,7 @@ title: "Prisma Postgres vs Neon Pricing 2026: Per-Plan Tables and Worked Examples" slug: "prisma-postgres-vs-neon-pricing-2026" date: "2026-06-24" -updatedAt: "2026-10-14" +updatedAt: "2026-10-19" authors: - "Martin Janse van Rensburg" metaTitle: "Prisma Postgres vs Neon Pricing 2026: Tables + Worked Examples" @@ -57,8 +57,8 @@ Neon's Launch and Scale plans have no fixed monthly base fee; you pay for what y | --- | --- | --- | | Instant restore / history window | Backups included (7 to 30 days by plan); no separately billed history | $0.20 / GB-month (Launch and Scale) | | Extra branches | No branching feature (separate databases instead; no per-branch fees) | $1.50 / branch-month (prorated hourly) | -| Egress / public transfer | Free | 500 GB included, then $0.10 / GB | -| Spend controls | Account-level operation quotas + spend limits | Spending limits with 80%/100% alerts; no automatic compute suspension yet | +| Egress / public transfer | Free | 500 GB per project included, then $0.10 / GB | +| Spend controls | Account-level operation quotas + spend limits | Spending notifications (Launch and Scale) at 80% and 100% of a threshold, alerts only; per-project consumption quotas set through the Neon API suspend computes | Neon's history window is the storage used to retain WAL data for instant restore (point-in-time recovery). It's billed separately from your live database storage at $0.20/GB-month, and grows with the size of your data and how long you retain history. This is easy to overlook when estimating Neon costs. @@ -226,7 +226,7 @@ History window = 1 GB × $0.20 = $0.20 (assumed) Monthly cost ≈ $78.27 ``` -This is the workload shape operation-based billing is built for, and the one the previous examples skip. The app has real idle time, but users are waiting on every query, so Neon's autosuspend advantage is off the table: enable it and your users eat cold starts; disable it and you pay for every hour, including the quiet ones. Prisma Postgres charges for the 3.9M queries and nothing else, so the idle hours are free _and_ the database is always ready. At these assumptions it comes out at less than half of Neon's always-on cost. +This is the workload shape operation-based billing is built for, and the one the previous examples skip. The app has real idle time, but users are waiting on every query, so Neon's autosuspend advantage is off the table: enable it and your users eat cold starts; disable it and you pay for every hour, including the quiet ones. Prisma Postgres bills the $10 Starter base plus the 2.9M operations above the 1M included, and nothing for the idle hours. At these assumptions it comes out at less than half of Neon's always-on cost. Two honesty notes. If your app genuinely fits Neon's 0.25 CU minimum around the clock, always-on drops to about $21/month all-in and the comparison inverts in Neon's favor; the $33-vs-$78 result rests on 1 CU being the realistic floor for latency-sensitive production traffic with bursts, so size that against your real load, not the average. And the advantage flips back as query volume grows: past roughly 24M operations a month (against the $49 Pro plan at 1 CU), always-on compute becomes the cheaper option again, as in example 2. @@ -277,7 +277,7 @@ Important caveat: Prisma Postgres has [query timeout limits](https://www.prisma. - **Storage in GB-months** (average GB stored over the month) - **For Neon: expected CU size** (0.25, 0.5, 1, 2, or more) and **active hours/day** (hours the DB is awake vs. suspended) - **For Neon: branches in use** and whether you're using instant restore (history window size) -- **Egress expectations** (Neon meters public network transfer above 500 GB/month) +- **Egress expectations** (Neon meters public network transfer above 500 GB per project per month) ### The math @@ -339,7 +339,7 @@ Don't trust a summary over your own math. Plug your real traffic into the calcul -For most workloads, yes: both are serverless Postgres with generous free tiers, and the choice comes down to billing shape. Prisma Postgres fits user-facing apps with idle periods and latency-sensitive users (no cold starts, operations billing, spend caps) and fleets of many small databases (account-wide metering across up to 1,000 databases). Neon fits mostly-idle and bursty workloads (scale-to-zero) and very high query volumes on always-on compute. Migration between them is standard Postgres; Prisma publishes a [switch-from-Neon guide](https://www.prisma.io/docs/guides/switch-to-prisma-postgres/from-neon), and this page is published by Prisma, so check the math yourself. +For most workloads, yes: both are serverless Postgres with generous free tiers, and the choice comes down to billing shape. Prisma Postgres fits user-facing apps with idle periods where operations billing and spend caps matter, and fleets of many small databases (account-wide metering across up to 1,000 databases). Neon fits mostly-idle and bursty workloads (scale-to-zero) and very high query volumes on always-on compute. Migration between them is standard Postgres; Prisma publishes a [switch-from-Neon guide](https://www.prisma.io/docs/guides/switch-to-prisma-postgres/from-neon), and this page is published by Prisma, so check the math yourself. An operation is a single Prisma ORM query: one call to a method like `prisma.user.findMany()`, `prisma.post.create()`, or `prisma.$queryRaw()`. The count doesn't increase based on how long the query takes or how many SQL statements Prisma generates internally under the hood. If your request handler calls five Prisma client methods, that's five operations, regardless of compute time. You can find the full definition in the [Prisma Postgres FAQ](https://www.prisma.io/docs/postgres/faq). @@ -348,7 +348,7 @@ An operation is a single Prisma ORM query: one call to a method like `prisma.use A CU-hour is one compute unit running for one hour. Neon's compute autosuspends after 5 minutes of inactivity by default (paid plans can disable it). This means idle time genuinely doesn't accumulate CU-hours. For a 1 CU database that's active 6 hours/day and idle 18 hours, you pay for 6 × 30 = 180 CU-hours/month, not 720 (scale by CU size for larger computes). Scale-to-zero is most valuable when your usage is genuinely bursty or business-hours-only; for an always-on production API, it provides no benefit and the full 720 CU-hours/month are billed. -Prisma Postgres includes egress for free on all plans. Neon's Launch and Scale plans include 500 GB of public network transfer per month; beyond that, the rate is $0.10/GB. For most applications, 500 GB is more than enough, but high-volume data export jobs or applications with large payload responses should account for it. +Prisma Postgres includes egress for free on all plans. Neon's Launch and Scale plans include 500 GB of public network transfer per project per month; beyond that, the rate is $0.10/GB. For most applications, 500 GB is more than enough, but high-volume data export jobs or applications with large payload responses should account for it. Neon extra branches are billed at $1.50/branch-month, prorated hourly. If you create a branch for a pull request and delete it after 12 hours (out of a 30-day month), you'd pay approximately $1.50 × (12/720) = $0.025 for that branch. The instant restore history window (PITR) is billed separately from your live data storage at $0.20/GB-month. Both appear as distinct line items on the Neon invoice. If you're running many preview environments or CI branches, the branch cost can add up: 20 active branches at any given time = $30/month in branch fees before compute. diff --git a/apps/blog/content/blog/prisma-vs-netlify/index.mdx b/apps/blog/content/blog/prisma-vs-netlify/index.mdx index 8204d3d9a0..1718631efe 100644 --- a/apps/blog/content/blog/prisma-vs-netlify/index.mdx +++ b/apps/blog/content/blog/prisma-vs-netlify/index.mdx @@ -21,7 +21,7 @@ Five Netlify alternatives host a full-stack TypeScript app's server and its Post You declare each service, its database, and the calls between them in TypeScript, and a root module wires them together. The compiler rejects a service that points at the wrong API or the wrong database schema, and one deploy command creates everything the root module describes. -Netlify builds and publishes your site and its functions together. The connections between separate services, and the database each one uses, are yours to set up and keep correct. +Netlify builds and publishes your site and its functions together, and Netlify Database can provision and migrate their Postgres database for you. The connections between separate services are yours to set up and keep correct. "Prisma" here means more than the ORM: @@ -165,14 +165,14 @@ What you get from one vendor, which is usually the real question behind leaving. | --- | --- | --- | --- | --- | --- | | App hosting | Yes | Yes | Yes | Edge Functions only | Yes | | Runtime | Node.js functions; Deno Edge Functions | Node.js, Bun or Next.js apps, run on Bun; they scale to zero when idle | Node.js, Bun, Python, and others | Deno-compatible Edge Functions | Node.js, Bun, and other native runtimes, or Docker | -| Longest request | 60 seconds; Background Functions up to 15 minutes | 60 seconds to first byte, then a started stream keeps going | 300 seconds by default, up to 800 on Pro and Enterprise; 30 minutes in beta on Pro and Enterprise for Node.js and Python functions | 150 seconds to respond; wall-clock limit 150 seconds on Free, 400 on paid plans | 100 minutes | +| Longest request | 60 seconds; Background Functions up to 15 minutes | 60 seconds to first byte, then a started stream keeps going | 300 seconds by default, up to 800 on Pro and Enterprise; 30 minutes in beta on Pro and Enterprise for Node.js, Bun and Python functions | 150 seconds to respond; wall-clock limit 150 seconds on Free, 400 on paid plans | 100 minutes | | Realtime or WebSocket servers | No | No | WebSockets in Functions (beta); no managed realtime service | Realtime service | WebSockets on web services; no managed realtime service | | Managed Postgres | Netlify Database, built on Neon | Prisma Postgres | No; add one from the Marketplace | Yes | Yes | | Connection pooling included | Not documented; the `@netlify/database` driver picks the connection method | Dedicated PgBouncer per database | Depends on the database | Shared pooler, plus a dedicated pooler on paid plans | Built-in PgBouncer on paid databases, opt-in | | Auth | Netlify Identity | No | No | Yes | No | | Object storage | Blobs | Object Store buckets (pricing not yet published) | Blob | Yes | No | | Edge network and image CDN | Yes | No | Yes | Storage CDN; image transformations on Pro and above | Global CDN for static sites and paid web services; no image CDN | -| Preview per branch | Deploy Preview; database branch with a copy of production data | Branch environment; database created by you or a Composer stage deploy, starts empty | Preview deployment | Branching on Pro and above, empty by default | Preview environment on Pro workspace and above | +| Preview per branch | Deploy Preview per pull request, with a database branch that copies production data; branch deploys once set up | Branch environment; database created by you or a Composer stage deploy, starts empty | Preview deployment | Branching on Pro and above, empty by default | Preview environment on Pro workspace and above | Sources for the table, by column: @@ -404,6 +404,7 @@ Prisma ORM works with Netlify Database, which is PostgreSQL built on Neon, and i ## Update history - 2026-10-19: the Supabase profile now says Supabase Compute, which runs Node, is a private alpha (us-west-2 only, not for production), checked against supabase.com/compute on 2026-10-19. +- 2026-10-19: the third paragraph now says Netlify Database can provision and migrate the site's Postgres database, the feature-parity table says Netlify builds a Deploy Preview per pull request and branch deploys only once they are set up, and Vercel's 30-minute beta maximum is listed for Node.js, Bun and Python functions, checked against Netlify's and Vercel's docs on 2026-10-19. - 2026-10-14: moved the two paragraphs on the Compute runtime and when Netlify is the better fit below the "Pick by app type" table, added a first row to that table for a full-stack TypeScript app leaving Netlify that names all five alternatives and two Compute limits, and updated two cells in the longest-request row of the feature-parity table from each vendor's limits page: Vercel lists a 30-minute maximum in beta on Pro and Enterprise, and a Supabase Edge Function has 150 seconds to respond on every plan; updated Prisma Postgres Free storage from 1.01 GB to 2 GB. - 2026-10-12: reworded the FAQ answer on Netlify alternatives and the first paragraph of the closing section to describe the options side by side. - 2026-10-08: rewrote the description and the opening to name five alternatives side by side, added a "Pick by app type" table and an FAQ on whether Compute runs functions or a server, updated the Railway and Neon profiles from their docs, stated the Starter base fee and metered Compute usage in the Prisma profile and the billing row, made the closing section say that Netlify fits code that depends on the Node.js runtime itself rather than Bun, and moved this history to the end. diff --git a/apps/blog/content/blog/serverless-postgres/index.mdx b/apps/blog/content/blog/serverless-postgres/index.mdx index 3613c53ff3..af592ff074 100644 --- a/apps/blog/content/blog/serverless-postgres/index.mdx +++ b/apps/blog/content/blog/serverless-postgres/index.mdx @@ -117,7 +117,7 @@ The reference implementation of the compute-time model, and the provider that po - **Bills for:** compute in CUs (1 CU = 1 vCPU + 4 GB), $0.106/CU-hour on Launch, $0.222 on Scale, storage $0.35/GB-month. Pay-as-you-go, no monthly minimum. - **Idle behaviour:** suspends after 5 minutes; wakes in "a few hundred milliseconds." Paid plans can disable auto-suspend for zero cold starts. - **Free / entry:** per project: each of up to 100 projects gets 100 CU-hours a month and 1 GB of storage, with storage capped at 20 GB across all projects. -- **Watch out for:** Databricks agreed to acquire Neon in May 2025; Neon's docs say it continues as a standalone platform positioned alongside Databricks Lakebase, which is a stated intention worth weighing for long-horizon bets. +- **Watch out for:** Databricks agreed to acquire Neon in May 2025; Neon's docs now call its database Lakebase Postgres, which also runs on Databricks as Lakebase, and describe Neon as the version built for developers, startups and agent platforms, a positioning worth weighing for long-horizon bets. ### Aurora Serverless v2 @@ -176,7 +176,7 @@ The five above cover the main shapes. Most of the rest of the managed-Postgres m - **Nile** is serverless Postgres for multi-tenant apps: every tenant is a virtual database in one Postgres, billed in query tokens (free tier 50M tokens and 1 GB; Pro from $15/mo). Its bet is multi-tenant compute that never pauses. - **Tembo** pivoted in May 2025 to running AI coding agents and no longer markets a Postgres product. Worth knowing if you shortlisted it from an older comparison. -**Managed instances (not serverless):** DigitalOcean (from $15.15/mo), Render (from $6/mo, billed per second), and Heroku Postgres (from $5/mo) all sell instance sizes you pick and resize yourself: no autoscaling, no scale-to-zero, and none of them calls the product serverless. Railway is the edge case: it bills usage per second and offers opt-in sleep for idle services, though its docs don't say whether volume-backed Postgres can sleep. +**Managed instances (not serverless):** DigitalOcean (from $15.15/mo), Render (from $6/mo, billed per second), and Heroku Postgres (from $5/mo) all sell instance sizes you pick and resize yourself: no compute autoscaling, no scale-to-zero, and none of them calls the product serverless. Railway is the edge case: it bills usage per second and offers opt-in sleep for idle services, though its docs don't say whether volume-backed Postgres can sleep. **Hyperscalers:** Aurora Serverless v2 (above) is the only hyperscaler Postgres that auto-suspends. Amazon RDS for PostgreSQL is provisioned managed Postgres: you pick an instance class and pay by the hour it runs, with automated backups and point-in-time restore inside a 1–35 day retention period (0 days turns automated backups off), read replicas and Multi-AZ standbys (checked 2026-10-12). Google Cloud SQL and AlloyDB, and Azure Database for PostgreSQL Flexible Server (from ~$12/mo), all use fixed compute with manual stop at most, and none is branded serverless by its own vendor. @@ -195,7 +195,7 @@ No. Cold starts only exist where compute suspends: Neon takes a few hundred mill For most side projects, a free tier covers it entirely: Prisma Postgres includes 200,000 operations, 2 GB and 50 databases per month with no credit card, and Neon includes 100 CU-hours and 1 GB of storage per project, for up to 100 projects and 20 GB of storage in total. The first paid dollar differs by model: $5/month buys a single node on PlanetScale, $10/month buys 1M operations on Prisma Postgres, and Neon bills pure usage with no minimum. -Yes. Databricks agreed to acquire Neon on May 14, 2025 (reported at about $1 billion) and committed to continued investment in the platform; Neon's own docs describe it as continuing as a standalone serverless Postgres platform. As of July 2026, Neon operates under its own brand with active pricing and docs, positioned as complementary to Databricks Lakebase. Those are stated intentions rather than guarantees, which is worth weighing for long-horizon platform bets. +Yes. Databricks agreed to acquire Neon on May 14, 2025 (reported at about $1 billion) and committed to continued investment in the platform; Neon's own docs now call its database Lakebase Postgres, the same database Databricks offers as Lakebase. As of October 2026, Neon operates under its own brand with active pricing and docs, built for developers, startups and agent platforms. Those are stated intentions rather than guarantees, which is worth weighing for long-horizon platform bets. Mostly no. DigitalOcean, Render, Heroku, Cloud SQL, and Azure Flexible Server sell instance sizes you pick, with no compute autoscaling and no automatic suspension, and none of their vendors calls these products serverless. Cloud SQL and Azure support stopping an instance manually (Azure restarts stopped servers automatically after 7 days), which saves money but is not scale-to-zero. Railway is the group's exception: it bills actual usage per second and offers an opt-in sleep feature for idle services, though its docs leave unstated whether volume-backed Postgres services can sleep.