# Neon alternatives with app hosting and Postgres in one place (2026): Prisma Postgres + Prisma Compute, Railway, Render and Supabase compared URL: https://www.prisma.io/blog/neon-vs-prisma-postgres-app-hosting-in-one-place Published: 2026-09-24 Updated: 2026-11-12 Authors: Gregory Boch Tags: platform, prisma-postgres Description: Neon alternatives compared on app hosting and Postgres in one place: Prisma Postgres + Prisma Compute, Railway, Render and Supabase, with 2026 prices. > 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. If you are looking at Neon and want the app hosted in the same place as its database, Prisma Postgres + Prisma Compute, Railway and Render put app hosting and Postgres in one place, and Supabase adds backend functions to its Postgres but hosts no frontend (its Compute private alpha runs backend services); the table below says when each fits. Prisma Postgres + Prisma Compute host a TypeScript frontend, a Node API and their managed Postgres database from one provider, in one project, on one bill, deployed from one GitHub repository. Prisma ORM is optional; any Postgres client works. We make Prisma Postgres and Prisma Compute. The service and the database run in the same region, chosen from six. 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 Prisma Composer module, its own new database; production data is not copied, and a push to the default branch deploys production. The app scales to zero while the database bills per operation, so an idle project costs $0 on the Free plan. ## Quick recommendation [#quick-recommendation] Pick Prisma Postgres + Prisma Compute when you want a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server, the API and Postgres from one provider, in one project, on one bill, deployed from one repository, with a preview for each pushed branch other than the default one once deploy on push is set up (each preview gets its own new database when the database is declared in the Composer module). The database is a dependency the service that uses it declares, and the Composer module provisions it, so the deploy creates it and hands the service its connection; on a preview branch that is the branch's own new database, not production's. Prisma Compute has been generally available since August 2026. Pick Neon when a pull request needs a copy of production data or you need point-in-time recovery today. Pick Railway or Render when the API holds WebSocket connections open or is not written in TypeScript, and Supabase when you want auth, storage and realtime from the database vendor and can host the frontend elsewhere. | Your situation | Pick | Why | | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Frontend, API and Postgres in one project | Prisma Postgres + Prisma Compute | Prisma Compute runs the API and a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server next to Prisma Postgres. Railway and Render also put app hosting and Postgres in one place. Neon Functions run backend code next to Neon's Postgres, and Neon's full-stack guide keeps the UI on Vercel, Netlify or another frontend host. Supabase hosts no frontend (its Compute private alpha runs backend services). | | A new app whose stack is not chosen yet | Prisma Postgres + Prisma Compute, with a TypeScript stack | A TypeScript API (Hono, NestJS or Elysia, for example) with a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server: Prisma Compute runs TypeScript apps built for Node.js, Bun or Next.js (deployed apps run on Bun) next to Prisma Postgres. Prisma Composer describes each service and the database it depends on in TypeScript; `npx prisma dev` runs the app on your laptop, and `npx prisma deploy` provisions it in one project, on one bill. The Free plan costs $0 and needs no credit card. For an API that runs a WebSocket server, runs background workers or is written in Python or Go, the rows below point to Railway, Render or Fly.io. | | App and database in one place, deployed from GitHub | Prisma Postgres + Prisma Compute | In one project and region (six to choose from); Free has no usage billing. Add a Composer declaration, run your build, deploy with `npx prisma deploy`, then connect the repository plus the `prisma/cloud-deploy-action` workflow for deploy on push. | | REST, tRPC or GraphQL API + TypeScript frontend + Postgres from GitHub | Prisma Postgres + Prisma Compute | The API declares the database as a dependency and receives the connection at runtime; the frontend runs in the same project. | | An existing TypeScript API server (Hono, NestJS or another Node.js or Bun server) with a frontend and Postgres | Prisma Postgres + Prisma Compute | Add a `service.ts` per server and one `module.ts`, then make three changes to the server: read the port from `service.port()` and bind `0.0.0.0`, turn its other `process.env` reads into service inputs or dependencies, and build the Postgres client from the injected `db.url` ([porting guide](https://www.prisma.io/docs/composer/porting-an-app)). The frontend, served by Next.js, Astro, TanStack Start or your own Node.js or Bun server, runs as its own service in the same project. The [Hono](https://www.prisma.io/docs/guides/frameworks/hono), [NestJS](https://www.prisma.io/docs/guides/frameworks/nestjs), [Elysia](https://www.prisma.io/docs/guides/frameworks/elysia) and [Bun](https://www.prisma.io/docs/guides/runtimes/bun) guides each end with a deploy to Prisma Compute; [hosting an existing repository](#can-i-host-my-existing-github-repository-next-to-prisma-postgres) lists the steps. Railway and Render also deploy an existing Node.js server from GitHub next to their Postgres. | | Small production app in one project, a preview for each pushed branch other than the default | Prisma Postgres + Prisma Compute | Starter is $10 base plus metered compute (memory, CPU and bandwidth): 1M operations, 10 GB, daily backups kept 7 days, a spend limit; a preview for each pushed branch other than the default one once deploy on push is set up. | | Just managed Postgres, free, standard tools | Prisma Postgres | Managed PostgreSQL 17 with PgBouncer pooling included; any Postgres client works; Free has 200,000 operations a month, 2 GB of storage and 50 databases and needs no credit card. | | An idle project that costs nothing | Prisma Postgres + Prisma Compute, or Neon | Prisma's Free plan costs $0 and has no usage billing; on every plan Compute scales to zero when idle, and on paid plans Prisma Postgres bills per operation on top of the plan fee (from $10 a month) and any storage beyond the included amount, both of which still bill while the project is idle. Neon suspends after five minutes idle; its paid plans have no base fee and bill compute by the CU-hour, and storage and instant-restore history still bill by the GB-month while compute is suspended. | | No database instance to size or upgrade | Prisma Postgres, or Neon | [Prisma Postgres autoscales](https://www.prisma.io/docs/postgres): there is no instance to size or upgrade. Neon [autoscales within a range you set](https://neon.com/docs/introduction/autoscaling). Prisma Postgres has no cold starts; Neon by default [scales to zero](https://neon.com/docs/introduction/scale-to-zero) after five idle minutes and reactivates on the next query, generally within a few hundred milliseconds. Railway [scales a service up to your plan's limits](https://docs.railway.com/deployments/scaling) and [you resize the Postgres volume](https://docs.railway.com/databases); on [Render](https://render.com/docs/postgresql-creating-connecting) and [Supabase](https://supabase.com/docs/guides/platform/compute-and-disk) you pick a plan or instance size. | | Point-in-time recovery today | Neon, Railway (opt-in), Render (paid) or Supabase (paid) | Neon restores to any moment in its history window, Railway archives WAL once you turn PITR on and restores into a new service, Render keeps 3 or 7 days on paid databases, Supabase sells PITR as an add-on; Prisma Postgres has daily snapshots on paid plans only, and point-in-time recovery is coming in November 2026. | | Every pull request needs a copy of production data | Neon | A Neon branch is a copy-on-write clone with its parent's data; Prisma, Render and Supabase previews start without production data by default. | | Holds WebSocket connections open | Railway, Render, Fly.io or Neon Functions | Prisma Compute [does not run WebSocket servers today](https://www.prisma.io/docs/compute/limitations); [support is planned for early 2027](https://www.prisma.io/compute/websocket-connections-dropping). Neon Functions can host WebSocket servers and SSE endpoints, with the frontend on another host. | | Background workers or scheduled jobs | Railway or Render | [Railway](https://docs.railway.com/services) and [Render](https://render.com/docs/background-workers) run always-on services and [cron jobs](https://render.com/docs/cronjobs). Prisma Compute does not run background workers ([`waitUntil`](https://www.prisma.io/docs/compute/keeping-instances-awake) keeps an instance awake for bounded, best-effort work after a response) and has [no built-in cron scheduler](https://www.prisma.io/docs/compute/limitations) today: Prisma Composer's [`cron` building block](https://www.prisma.io/docs/composer/building-blocks#cron) adds a scheduler service, and [native cron is planned for early 2027](https://www.prisma.io/compute/scheduled-jobs-not-running). [Neon Functions](https://neon.com/docs/compute/functions/overview) run on a cron schedule but are not a job queue, and [Supabase Cron](https://supabase.com/docs/guides/cron) schedules jobs inside Postgres. | | Python or Go API next to Postgres | Railway, Render or Fly.io | Prisma Compute runs TypeScript apps built for Node.js, Bun or Next.js; deployed apps run on Bun. | | Frontend needs a global CDN above all | Vercel + a Marketplace Postgres | Compute is not a CDN; Vercel adds Neon, Supabase or Prisma Postgres from its Marketplace. | | The app must run in more than one region | Fly.io | Each Prisma Compute service runs in one region. | | Lowest bill, run the servers yourself | A VPS | You run Postgres, the pooler and the backups yourself. | ## What to compare before you leave Neon [#what-to-compare-before-you-leave-neon] 1. **Where the frontend, the API and the database run**: in one project, or on separate hosts. 2. **Who runs the database**, and which features, such as backups and pooling, are opt-in. 3. **A preview for each pushed branch other than the default**, or for each pull request, and whether a preview copies production data or starts with a new database. 4. **Idle cost**: what a project costs when nobody uses it, and how long it takes to wake. 5. **Same-region networking** between the app and the database. 6. **Connection pooling**: included, opt-in or a separate endpoint. 7. **Backups and point-in-time recovery**: how far back you can restore, and on which plans. 8. **Postgres extensions**: check every extension your schema uses. Prisma Postgres [lists its supported extensions](https://www.prisma.io/docs/postgres/database/postgres-extensions), including `vector` (pgvector), `pg_search`, `pg_trgm`, `pgcrypto` and `pg_stat_statements`; PostGIS is not on that list. 9. **Observability**: how you find slow queries. Prisma Postgres includes [Query Insights](https://www.prisma.io/docs/postgres/database/query-insights) at no extra cost: average latency and queries per second over time, queries grouped by statement shape and, for Prisma ORM, the SQL each call generates. 10. **Pricing shape**: a plan fee, usage meters or both, and which meter your workload drives. 11. **Exit path**: whether `pg_dump` over a direct connection gets your data out. 12. **Work outside a request**: background workers and scheduled jobs, or only bounded work after a response. Prisma Compute does not run background workers and has no built-in cron scheduler today: Prisma Composer's [`cron` building block](https://www.prisma.io/docs/composer/building-blocks#cron) adds a scheduler service, and [native cron is planned for early 2027](https://www.prisma.io/compute/scheduled-jobs-not-running). > [!NOTE] > **How we compared** > > The [comparison table](#how-the-four-compare-with-neon) uses criteria 2 to 11, in this order; the situation table and the entries cover criterion 1, where the app and the database run, and the situation table covers criterion 12, work outside a request. The table and the numbered entries below list the vendors in alphabetical order. Every table cell links to the vendor page it rests on; Prisma's figures come from the [pricing page](https://www.prisma.io/pricing) and the Compute and Prisma Postgres docs. We checked every vendor page on 2026-09-30, the "Who runs the database" row on 2026-10-07, the Railway facts and the extensions and observability rows on 2026-10-08, the database sizing row and the pages behind criterion 12 on 2026-10-30, Supabase Compute and custom domains on 2026-11-02, Supabase's CLI v3 migration guide, backup and restore guide, self-hosted restore guide and connection docs on 2026-11-08, and, on 2026-11-12, the Neon facts, the Neon, Railway, Render and Supabase prices, Railway's PostgreSQL guide, what Railway manages and PR environments, and Render's preview environments. We make Prisma Compute and Prisma Postgres. ## Neon alternatives that include app hosting [#neon-alternatives-that-include-app-hosting] 1. **Prisma Postgres + Prisma Compute** * Best for: a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server, the API and Postgres from one provider, in one project, on one bill. * What it does: Prisma ORM is optional for both products; any Postgres client works. [Prisma Postgres](https://www.prisma.io/docs/postgres) is managed Postgres, run by Prisma: PostgreSQL 17 with PgBouncer pooling included, reached through a connection string. [Prisma Compute](https://www.prisma.io/docs/compute) runs TypeScript services (Node.js, Bun or Next.js) next to it in the same region, chosen from six, generally available since August 2026. With [Prisma Composer](https://www.prisma.io/docs/composer) you describe your whole app in TypeScript, each service and the database it depends on; `npx prisma dev` runs it on your laptop, and `npx prisma deploy` provisions the services on Prisma Compute and the database on Prisma Postgres. * Pricing: Free $0, no credit card, no usage billing: 1M Compute requests and 200,000 database operations a month, 2 GB of storage and 50 databases. Starter $10 base plus metered compute: 5M requests and 1M operations included, 10 GB of storage, daily backups kept 7 days and a spend limit; memory, active vCPU and bandwidth metered from the first unit, then $1 per million requests and $8 per million operations beyond the included amounts. [Prisma pricing](https://www.prisma.io/pricing), as of October 2026. * Trade-offs: point-in-time recovery is coming in November 2026; until then, paid plans keep daily snapshots. No database branching feature, no preview that copies production data, one region per service. We make Prisma Compute and Prisma Postgres, and we checked Neon, Railway, Render, Supabase and Vercel against their own docs on 2026-09-30. * Compare: [Prisma Postgres vs Neon](https://www.prisma.io/compare/neon) and [Prisma Postgres vs Neon pricing](https://www.prisma.io/blog/prisma-postgres-vs-neon-pricing-2026). 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-11-12). PR environments are opt-in: once you [turn them on in project settings](https://docs.railway.com/environments), each pull request gets one, deleted when the pull request is merged or closed. * Pricing: Free $0 with $1 of monthly usage credit, after a one-time $5 trial credit; Hobby $5 a month with $5 of usage, Pro $20 with $20; usage beyond the credit is billed per second for memory, CPU and volume, about $10 per GB of memory, $20 per vCPU and $0.15 per GB of volume a month, plus $0.05 per GB of egress. [Railway pricing](https://railway.com/pricing), checked 2026-11-12. * 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](https://www.prisma.io/blog/where-to-host-typescript-frontend-node-api-postgres). 3. **Render** * Best for: a long-running web service, WebSockets included, next to a managed Postgres with point-in-time recovery. * What it does: runs web services from GitHub next to Render Postgres in one of five regions. Paid databases get [point-in-time recovery](https://render.com/docs/postgresql-backups), 3 days back on a Hobby workspace and 7 on Pro or higher. [Preview environments](https://render.com/docs/preview-environments) need a Pro workspace and a `previews.generation` setting in the `render.yaml` Blueprint; once set, they copy the Blueprint for a pull request, with an empty database. * Pricing: Hobby workspace free, with a [free web service](https://render.com/docs/free) that spins down after 15 minutes idle and one free Postgres that expires after 30 days; paid web services from $7 a month and Postgres from $6 a month on [Render's pricing page](https://render.com/pricing), checked 2026-11-12. * Trade-offs: free databases get no backups, full-stack preview environments need a Pro workspace, and a free service takes about a minute to wake. * Compare: [App hosting platforms with managed Postgres compared](https://www.prisma.io/blog/app-hosting-platforms-with-managed-postgres-2026), which adds Fly.io. 4. **Supabase + a frontend host** * Best for: Postgres with auth, storage, realtime and Edge Functions from one vendor, with the frontend hosted elsewhere. * What it does: hosts Postgres behind a shared pooler and adds auth, object storage, realtime and [Edge Functions](https://supabase.com/docs/guides/functions) on a Deno-compatible runtime. It hosts no frontend: Supabase says its [custom domains](https://supabase.com/docs/guides/platform/custom-domains) are not intended for hosting frontend applications through Edge Functions. [Supabase Compute](https://supabase.com/compute), which runs backend services, is a private alpha (us-west-2 only, not for production). [Branching](https://supabase.com/docs/guides/deployment/branching), on Pro or higher, creates a preview database per pull request, without production data unless you seed it or opt in. * Pricing: Free $0 with a 500 MB database size quota, summed across the organization's projects (each Free project has a fixed [2 GB](https://supabase.com/docs/guides/platform/database-size) disk); Free projects pause after a week idle; Pro from $25 a month with $10 of compute credits, 8 GB of disk and daily backups kept 7 days; point-in-time recovery is a paid add-on from $100 a month per 7 days of retention; branches from $0.01344 per branch-hour. [Supabase pricing](https://supabase.com/pricing), checked 2026-11-12. * Trade-offs: the frontend needs a separate host, Edge Functions are not Node.js or Bun, and Supabase Compute, which runs Node, is a private alpha (us-west-2 only, not for production), so a Node.js server that serves production needs another host too, and Free has no automatic backups. * Compare: [Prisma vs Netlify](https://www.prisma.io/blog/prisma-vs-netlify), which profiles Supabase. 5. **Vercel + a Marketplace Postgres** * Best for: a Next.js frontend that needs a global CDN, with the database billed through the same account. * What it does: hosts the frontend and its functions; you add Neon, Supabase, Prisma Postgres or AWS Aurora from the [Vercel Marketplace](https://vercel.com/docs/marketplace-storage), which injects the connection string as environment variables and bills through your Vercel account. * Pricing: Hobby $0; Pro $20 a month per seat with $20 of included credit, plus the database at the provider's rates. [Vercel pricing](https://vercel.com/pricing), as of September 2026. * Trade-offs: two products from two companies, so branching, backups and pooling are whatever the database provider offers. * Compare: [Prisma Compute vs Vercel pricing](https://www.prisma.io/blog/prisma-compute-vs-vercel-pricing). DigitalOcean App Platform, Heroku and Northflank also host the app and Postgres in one place, and they are not in the table below. DigitalOcean App Platform [deploys apps from a Git repository or a container image](https://docs.digitalocean.com/products/app-platform/) and [adds a database to the app](https://docs.digitalocean.com/products/app-platform/how-to/manage-databases/): a PostgreSQL dev database, or a Managed Database, which DigitalOcean recommends for production. On [DigitalOcean's pricing page](https://www.digitalocean.com/pricing/app-platform), the free tier covers static sites only, a service container starts at $5 a month, and a 512 MiB dev database is $7 a month, not backed up by default and destroyed with the app. [Managed PostgreSQL](https://www.digitalocean.com/pricing/managed-databases) starts at $15.15 a month for a single node and [restores to any point in the previous seven days](https://docs.digitalocean.com/products/databases/postgresql/details/features/). Previews take [GitHub Actions workflows](https://docs.digitalocean.com/products/app-platform/how-to/deploy-from-github-actions/) you add: DigitalOcean's example deploys a separate app for each pull request against `main` and deletes it when the pull request is merged or closed (digitalocean.com, checked 2026-11-09). Heroku [deploys and runs Node.js apps](https://devcenter.heroku.com/articles/how-heroku-works) next to [Heroku Postgres](https://devcenter.heroku.com/articles/heroku-postgresql), a managed database you [add to the app](https://devcenter.heroku.com/articles/provisioning-heroku-postgres) as an add-on. On [Heroku's pricing page](https://www.heroku.com/pricing), an always-on Basic dyno on the Cedar generation is $7 a month, Heroku Postgres starts at $5 with 1 GB and no rollback, and Standard-0, the cheapest plan with rollback, is $50 and reaches back up to 4 days. [Review apps](https://devcenter.heroku.com/articles/github-integration-review-apps) are opt-in, one per pull request, with no copy of production data (heroku.com, checked 2026-10-30). Northflank [builds and deploys code in any language from GitHub, GitLab or Bitbucket](https://northflank.com/docs/v1/application/getting-started/introduction-to-northflank) and runs [PostgreSQL as an addon](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-databases-on-northflank/deploy-postgresql-on-northflank) in the same project, with hourly, daily or weekly [backup schedules](https://northflank.com/docs/v1/application/databases-and-persistence/backup-restore-and-import-data) you set up. On [Northflank's pricing page](https://northflank.com/pricing), the free Sandbox includes 2 services, 2 jobs and 1 database, with up to $20 a month of resources on Northflank Cloud, and paid usage is billed by the second: on Northflank Cloud by resource, and in your own cloud account by the vCPU on the nodes Northflank manages, while your cloud provider bills the infrastructure. Northflank's [pricing docs](https://northflank.com/docs/v1/application/billing/pricing-on-northflank) say the free tier should not be used for production. [Preview environments](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) come from a preview blueprint you set up: a pull request or a push to a matching branch creates one, and the blueprint gives it a new database, forks one from a snapshot or [shares an existing one](https://northflank.com/docs/v1/application/use-cases/create-preview-environments) (northflank.com, checked 2026-11-09). ## How the four compare with Neon [#how-the-four-compare-with-neon] | | 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; point-in-time recovery is coming in November 2026, and until then paid plans keep [daily snapshots](https://www.prisma.io/docs/postgres/database/backups) | 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-11-12) | 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 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 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 | Opt-in: once turned on in project settings, a [PR environment](https://docs.railway.com/environments) per pull request | [Per-PR full-stack preview](https://render.com/docs/preview-environments) on Pro workspaces, once turned on in the Blueprint; 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), taken only on days with database activity, kept 7 or 30 days, restored from the Console in place (same connection strings) or into a new database; the CLI and the REST restore endpoint restore in place, and the REST API and the MCP server can also restore into a new database. PITR is coming in November 2026 | [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 | | Postgres extensions | See [Neon's extensions list](https://neon.com/docs/extensions/pg-extensions) | [Supported list](https://www.prisma.io/docs/postgres/database/postgres-extensions) includes `vector` (pgvector), `pg_search`, `pg_trgm`, `pgcrypto` and `pg_stat_statements`; PostGIS is not listed | See [Railway's PostgreSQL docs](https://docs.railway.com/databases/postgresql#extensions) | See [Render's supported extensions](https://render.com/docs/postgresql-extensions) | See [Supabase's extensions guide](https://supabase.com/docs/guides/database/extensions) | | Observability | See [Neon's monitoring docs](https://neon.com/docs/introduction/monitoring-page) | [Query Insights](https://www.prisma.io/docs/postgres/database/query-insights), included at no extra cost: latency, queries per second and queries grouped by statement shape | See [Railway's metrics docs](https://docs.railway.com/observability/metrics) | See [Render's service metrics docs](https://render.com/docs/service-metrics) | See [Supabase's observability docs](https://supabase.com/docs/guides/observability) | | Pricing shape | [No base fee](https://neon.com/pricing) on paid plans; CU-hours, storage, branches, history and Functions meters | [Plan base](https://www.prisma.io/pricing) of $0 to $129 plus operations, storage and the Compute meters; spend limit on paid plans | [Free $0 with $1 of credit](https://railway.com/pricing), Hobby $5 or Pro $20 with matching credit, then metered per second for CPU, memory and disk | [Free workspace](https://render.com/docs/free); paid instances per month | [Plan fee](https://supabase.com/pricing) of $0 to $599 plus compute, disk, PITR and branch-hours | | Exit path | [`pg_dump` over a direct connection](https://neon.com/docs/manage/backup-pg-dump) | [`pg_dump` over the direct connection](https://www.prisma.io/docs/postgres/database/backups) | [Official Postgres image](https://docs.railway.com/guides/postgresql); `pg_dump` | [`pg_dump`](https://render.com/docs/postgresql-backups) | Supabase's [backup and restore guide](https://supabase.com/docs/guides/platform/migrating-within-supabase/backup-restore) (separate roles, schema and data dumps with `supabase db dump --remote` on [CLI v3](https://supabase.com/docs/guides/local-development/cli/migrating-to-v3); changes to `auth` and `storage` are restored separately), or [`pg_dump` over the direct connection](https://supabase.com/docs/guides/database/connecting-to-postgres) for a Postgres host outside Supabase | ## Can I host my existing GitHub repository next to Prisma Postgres? [#can-i-host-my-existing-github-repository-next-to-prisma-postgres] You can, and you keep your database client. What you add is a [Prisma Composer](https://www.prisma.io/docs/composer) declaration. Your server code stays the server, with three changes the porting guide lists: it reads its port from `service.port()` and binds `0.0.0.0`, its other `process.env` reads become service inputs or dependencies, and it builds its database client from the injected `db.url` instead of `process.env.DATABASE_URL`. A `service.ts` declares each server as a service with its build and the Postgres database it depends on. A `module.ts` composes the services and provisions that database, so the service receives the connection at runtime, and the CLI reads its deploy settings from the `composer` section of `prisma.config.ts`, where `entry: './module.ts'` names that module. The [porting page](https://www.prisma.io/docs/composer/porting-an-app) has a prompt a coding agent can write the declaration from, and after your usual build ([deploy does not build](https://www.prisma.io/docs/composer/deploying#build-first)), `npx prisma deploy` provisions the services and the database. Deploy on push takes two more steps: connect the repository with `npx prisma git connect`, and commit a GitHub Actions workflow that runs `prisma/cloud-deploy-action`. Connecting alone deploys nothing; with the workflow in place, a push to the default branch updates production and a push to any other branch creates a preview. Composer's [limitations page](https://www.prisma.io/docs/composer/limitations) lists what it does not do yet. ## Where Prisma Postgres + Compute is the wrong choice [#where-prisma-postgres--compute-is-the-wrong-choice] Prisma Postgres keeps daily snapshots on paid plans, taken only on days with activity, for 7 days on Starter and Pro and 30 on Business, and you can restore one in place, keeping the connection strings, or into a new database. Changes after the last snapshot may not be restorable, and point-in-time recovery is coming in November 2026. It has no preview that copies production data: a preview database starts with none. And each Compute service runs in one region, chosen from six. Neon covers the first two and Fly.io the third. The Compute FAQ keeps the full list under [Where it has trade-offs](https://www.prisma.io/docs/compute/faq#where-it-has-trade-offs). ## How to move from Neon [#how-to-move-from-neon] Both sides are standard PostgreSQL, so the move is a dump and a restore, and you keep your ORM or driver and point it at the new connection string. The [switch-from-Neon guide](https://www.prisma.io/docs/guides/switch-to-prisma-postgres/from-neon) uses PostgreSQL 17 tools, because Prisma Postgres runs PostgreSQL 17, and it stops if the source is newer; [Neon supports Postgres 14 through 18](https://neon.com/docs/postgresql/postgres-version-policy), so check the source version first. The guide moves one branch and one database, not other branches, roles or integrations, and it keeps writes stopped from the final `pg_dump` until the row counts match and traffic switches to the pooled connection string, so rehearse once with a throwaway dump. The guide then reconnects the app with whichever Postgres client it uses, with or without Prisma ORM. ## Frequently asked questions [#frequently-asked-questions] ### Do I need Prisma ORM to use Prisma Postgres or Prisma Compute? [#do-i-need-prisma-orm-to-use-prisma-postgres-or-prisma-compute] No, Prisma ORM is optional for both. Prisma Postgres is managed PostgreSQL 17 behind a standard connection string, so `pg`, Drizzle, Kysely, `psql` or Prisma ORM all connect to it, and a Compute service builds your app's client from the database URL it receives. The [Compute FAQ](https://www.prisma.io/docs/compute/faq#do-i-need-prisma-orm-to-use-compute) and the [Prisma Postgres FAQ](https://www.prisma.io/docs/postgres/faq#can-i-use-prisma-postgres-without-prisma-orm) say the same. ### Does Prisma Postgres have database branching like Neon? [#does-prisma-postgres-have-database-branching-like-neon] 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; production data is not copied, so any data in it is data you seed. If the app reads `DATABASE_URL`, the preview is only as separate as that value. Prisma Postgres has no database branching feature and no per-branch fee. The deploy applies your migrations only when the database is declared with `postgres()` and a Prisma ORM data contract; you migrate a `rawPostgres()` database yourself, in every preview. A Neon branch is a copy-on-write clone with its parent's data; Neon includes 10 branches per project on Free and Launch and 25 on Scale, then $1.50 per branch-month on paid plans. ### Can Neon host my app as well as the database? [#can-neon-host-my-app-as-well-as-the-database] Neon can host the backend: Neon Functions (generally available since [2026-09-17](https://neon.com/blog/neon-backend-is-ga), also on Free) run Node.js 24 HTTP handlers next to the database, including WebSockets and SSE, in four AWS regions today; Neon's [full-stack guide](https://neon.com/use-cases/full-stack-apps) keeps the UI on Vercel, Netlify or another frontend host (neon.com, checked 2026-11-12). Prisma Compute runs the frontend and the API in the same project as Prisma Postgres, with the frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server. ### Does Supabase host my app as well as the database? [#does-supabase-host-my-app-as-well-as-the-database] Supabase hosts the database and backend functions, not the frontend. Its [Edge Functions](https://supabase.com/docs/guides/functions) are server-side TypeScript functions on a Deno-compatible runtime, and Supabase says its [custom domains](https://supabase.com/docs/guides/platform/custom-domains) are not intended for hosting frontend applications through Edge Functions (supabase.com, checked 2026-11-02). [Supabase Compute](https://supabase.com/compute), which runs backend services, Node included, is a private alpha (us-west-2 only, not for production; supabase.com, checked 2026-11-02). So the frontend goes on another host, and so does a Node.js server that serves production. Prisma Compute runs the API and a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server in the same project as Prisma Postgres. ### Which is cheaper, Neon or Prisma Postgres? [#which-is-cheaper-neon-or-prisma-postgres] It depends on whether your bill should follow queries or uptime. Neon bills CU-hours with no base fee on paid plans, so a mostly idle, bursty or always-on high-volume database costs less there. Prisma Postgres bills per operation on top of a plan fee, so a user-facing app with quiet hours and moderate query volume costs less on Prisma when its users cannot wait for a cold start, which keeps Neon's compute awake through the quiet hours. The [pricing comparison](https://www.prisma.io/blog/prisma-postgres-vs-neon-pricing-2026) shows the arithmetic for five workloads; that case comes to $33 against $78 a month at 1 CU, and an app that fits Neon's 0.25 CU minimum inverts it. ## Sources [#sources] * Neon: [pricing](https://neon.com/pricing), [introduction](https://neon.com/docs/introduction), [Functions overview](https://neon.com/docs/compute/functions/overview), [full-stack apps](https://neon.com/use-cases/full-stack-apps), [compute sizes](https://neon.com/docs/manage/computes), [extensions](https://neon.com/docs/extensions/pg-extensions), [monitoring](https://neon.com/docs/introduction/monitoring-page), [branching](https://neon.com/docs/introduction/branching), [Postgres version policy](https://neon.com/docs/postgresql/postgres-version-policy), [autoscaling](https://neon.com/docs/introduction/autoscaling), [scale to zero](https://neon.com/docs/introduction/scale-to-zero) and the [backend launch post](https://neon.com/blog/neon-backend-is-ga). Pricing, Functions, Function Triggers, autoscaling and scale to zero checked 2026-11-12; compute sizes checked 2026-10-08. * Railway: [pricing](https://railway.com/pricing), [PostgreSQL guide](https://docs.railway.com/databases/postgresql), [what Railway manages](https://docs.railway.com/databases#what-railway-manages), [metrics](https://docs.railway.com/observability/metrics), [regions](https://docs.railway.com/deployments/regions), [backups](https://docs.railway.com/volumes/backups), [services](https://docs.railway.com/services), [environments](https://docs.railway.com/environments) and [scaling](https://docs.railway.com/deployments/scaling). Pricing, PostgreSQL guide, what Railway manages and environments checked 2026-11-12; services and scaling checked 2026-10-30. * Render: [pricing](https://render.com/pricing), [free tier](https://render.com/docs/free), [Render Postgres](https://render.com/docs/postgresql), [Postgres backups](https://render.com/docs/postgresql-backups), [supported extensions](https://render.com/docs/postgresql-extensions), [service metrics](https://render.com/docs/service-metrics), [regions](https://render.com/docs/regions), [preview environments](https://render.com/docs/preview-environments), [background workers](https://render.com/docs/background-workers), [cron jobs](https://render.com/docs/cronjobs) and [creating and connecting Postgres](https://render.com/docs/postgresql-creating-connecting). Pricing, free tier and preview environments checked 2026-11-12; background workers, cron jobs and creating and connecting Postgres checked 2026-10-30. * Supabase: [pricing](https://supabase.com/pricing), [database overview](https://supabase.com/docs/guides/database/overview), [backups](https://supabase.com/docs/guides/platform/backups), [extensions](https://supabase.com/docs/guides/database/extensions), [observability](https://supabase.com/docs/guides/observability), [Edge Functions](https://supabase.com/docs/guides/functions), [custom domains](https://supabase.com/docs/guides/platform/custom-domains), [branching](https://supabase.com/docs/guides/deployment/branching), [Compute](https://supabase.com/compute), [compute and disk](https://supabase.com/docs/guides/platform/compute-and-disk), [database size](https://supabase.com/docs/guides/platform/database-size) and [Cron](https://supabase.com/docs/guides/cron). Pricing and database size checked 2026-11-12; Compute and custom domains checked 2026-11-02; compute and disk and Cron checked 2026-10-30. * Supabase CLI and connections: [migrating to CLI v3](https://supabase.com/docs/guides/local-development/cli/migrating-to-v3), [backup and restore using the CLI](https://supabase.com/docs/guides/platform/migrating-within-supabase/backup-restore), [restoring a platform project to self-hosted](https://supabase.com/docs/guides/self-hosting/restore-from-platform) and [connecting to Postgres](https://supabase.com/docs/guides/database/connecting-to-postgres), checked 2026-11-08. * Prisma Postgres: [extensions](https://www.prisma.io/docs/postgres/database/postgres-extensions) and [Query Insights](https://www.prisma.io/docs/postgres/database/query-insights), checked 2026-10-08; the Composer [porting guide](https://www.prisma.io/docs/composer/porting-an-app) and [databases](https://www.prisma.io/docs/composer/databases) pages, [deploy on push](https://www.prisma.io/docs/compute/deploy-on-push), [Compute limitations](https://www.prisma.io/docs/compute/limitations) and the [Hono](https://www.prisma.io/docs/guides/frameworks/hono), [NestJS](https://www.prisma.io/docs/guides/frameworks/nestjs), [Elysia](https://www.prisma.io/docs/guides/frameworks/elysia) and [Bun](https://www.prisma.io/docs/guides/runtimes/bun) guides, checked 2026-10-28; the [Prisma Postgres overview](https://www.prisma.io/docs/postgres), the [Prisma Postgres announcement](https://www.prisma.io/blog/prisma-postgres-the-future-of-serverless-databases), [keeping instances awake](https://www.prisma.io/docs/compute/keeping-instances-awake) and Compute limitations again, checked 2026-10-30. Prisma Composer's [building blocks](https://www.prisma.io/docs/composer/building-blocks) and the early 2027 dates on the [WebSocket](https://www.prisma.io/compute/websocket-connections-dropping) and [scheduled jobs](https://www.prisma.io/compute/scheduled-jobs-not-running) guides, checked 2026-10-30. * Vercel: [pricing](https://vercel.com/pricing) and [Marketplace storage](https://vercel.com/docs/marketplace-storage). Fly.io: [regions](https://docs.fly.io/reference/regions/). * DigitalOcean: [App Platform](https://docs.digitalocean.com/products/app-platform/), [App Platform pricing](https://www.digitalocean.com/pricing/app-platform) and its [pricing docs](https://docs.digitalocean.com/products/app-platform/details/pricing/), [databases in App Platform](https://docs.digitalocean.com/products/app-platform/how-to/manage-databases/), [deploying with GitHub Actions](https://docs.digitalocean.com/products/app-platform/how-to/deploy-from-github-actions/), and Managed PostgreSQL [pricing](https://www.digitalocean.com/pricing/managed-databases) and [features](https://docs.digitalocean.com/products/databases/postgresql/details/features/), checked 2026-11-09. * Heroku: [how Heroku works](https://devcenter.heroku.com/articles/how-heroku-works), [Heroku Postgres](https://devcenter.heroku.com/articles/heroku-postgresql), [provisioning Heroku Postgres](https://devcenter.heroku.com/articles/provisioning-heroku-postgres), [pricing](https://www.heroku.com/pricing) and [review apps](https://devcenter.heroku.com/articles/github-integration-review-apps), checked 2026-10-30. * Northflank: [introduction](https://northflank.com/docs/v1/application/getting-started/introduction-to-northflank), [PostgreSQL](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-databases-on-northflank/deploy-postgresql-on-northflank), [backups](https://northflank.com/docs/v1/application/databases-and-persistence/backup-restore-and-import-data), [preview blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints), [preview environments](https://northflank.com/docs/v1/application/use-cases/create-preview-environments) and [pricing](https://northflank.com/pricing) and [pricing docs](https://northflank.com/docs/v1/application/billing/pricing-on-northflank), checked 2026-11-09. ## Update history [#update-history] * 2026-11-12: Railway's pricing line now says usage beyond the plan credit is billed per second for memory, CPU and volume, with egress billed per GB, and that the one-time $5 trial credit comes before the Free plan's $1 a month; the comparison table's Railway pricing cell now says usage is metered per second; Railway's "opt-in" links and the "what Railway manages" source now point to the What Railway manages table on Railway's databases page, which loads again, and the regions and backups sources use Railway's current paths; Render's entry and the previews row say full-stack preview environments are turned on in the Blueprint, and the trade-offs say only those need a Pro workspace; Supabase's pricing line says the Free database size is a billing quota next to a 2 GB disk, that the recovery add-on is paid and that the branch-hour price is a starting price. Checked against Neon's, Railway's, Render's and Supabase's pricing and docs on 2026-11-12; Neon's figures on this page still hold. * 2026-11-09: the situation table adds a row for a new app whose stack is not chosen yet, with Prisma Postgres + Prisma Compute and a TypeScript stack, and points to the rows below for an API that runs a WebSocket server, runs background workers or is written in Python or Go; short DigitalOcean App Platform and Northflank notes now sit on either side of the Heroku note after the numbered entries, under one opening sentence; the "App and database in one place, deployed from GitHub" row, the Prisma entry and "Can I host my existing GitHub repository next to Prisma Postgres?" now show `npx prisma deploy` (and, in the Prisma entry, `npx prisma dev`) with no `module.ts` argument, since the Prisma CLI reads the entry from the `composer` section of `prisma.config.ts`; the "Python or Go API next to Postgres" row says which TypeScript apps Prisma Compute runs. Checked against Prisma's CLI `dev` and `deploy` docs, DigitalOcean's App Platform and Managed PostgreSQL docs and pricing and Northflank's docs and pricing on 2026-11-09. No other facts changed. * 2026-11-08: the opening now names Prisma Postgres + Prisma Compute, Railway, Render and Supabase in one sentence, in the order the post's description uses; the Supabase exit path in the comparison table, which named a single `supabase db dump`, now points to Supabase's backup and restore guide, which dumps roles, schema and data separately with `supabase db dump --remote` (CLI v3 dumps the local stack without `--remote`) and restores changes to `auth` and `storage` separately, and names `pg_dump` over the direct connection for a Postgres host outside Supabase; checked against Supabase's CLI v3 migration guide, backup and restore guide, self-hosted restore guide and connection docs on 2026-11-08. No other facts changed. * 2026-11-03: the opening now says Supabase hosts no frontend and that its Compute private alpha runs backend services, as the situation table, the Supabase entry and the FAQ already did; checked against Supabase's custom domains docs and its Compute page on 2026-11-02. No other facts changed. * 2026-10-30: the situation table adds a row on database sizing and cold starts, with Neon, Railway, Render and Supabase beside Prisma Postgres, and a row on work outside a request; that row, the row on held-open connections and a twelfth checklist criterion now say what Prisma Compute does not run today, what Prisma Composer's `cron` building block adds, and what is planned for early 2027; the small production app row and criterion 3 spell out a preview for each pushed branch other than the default; the Prisma entry's best-for line is shorter; Railway's entry and the previews row now say first that PR environments are opt-in; and a short Heroku note follows the numbered entries. Checked against Prisma's docs and the Neon, Railway, Render, Supabase and Heroku docs on 2026-10-30. * 2026-10-30: the "Backups and PITR" row and the opening of "Where Prisma Postgres + Compute is the wrong choice" now start with how a Prisma Postgres snapshot is restored: from the Console in place, keeping the connection strings, or into a new database; the 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 row says snapshots are taken only on days with database activity. Checked against Prisma's backups docs on 2026-10-30. * 2026-10-28: the quick recommendation now says the database is a dependency the service that uses it declares and the Composer module provisions, so the deploy creates it and hands the service its connection, and a preview branch gets its own new database; the situation table adds a row for an existing TypeScript API server with a frontend and Postgres, with the three server changes from the porting guide, the frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server, links to the Hono, NestJS, Elysia and Bun guides, and a note that Railway and Render also deploy an existing Node.js server from GitHub; the paragraph under the situation table that repeated when Neon is the better pick was removed, since the quick recommendation, the situation table, the Prisma entry and "Where Prisma Postgres + Compute is the wrong choice" already say it. Checked against Prisma's porting guide, Composer databases docs, deploy-on-push docs, Compute limitations and the Hono, NestJS, Elysia and Bun guides on 2026-10-28. * 2026-10-27: the opening now says a preview is for each pushed branch other than the default one and that a push to the default branch deploys production, and it now adds that the frontend, the API and the database come from one provider, on one bill. Checked against Prisma's deploy-on-push docs and Compute FAQ on 2026-10-27. * 2026-10-26: each line that says Prisma Postgres has no point-in-time recovery yet (the Prisma entry's trade-offs, the "Who runs the database" and "Backups and PITR" rows, and the opening of "Where Prisma Postgres + Compute is the wrong choice") now starts with the date, November 2026, followed by the daily snapshots paid plans keep until then; the quick recommendation and the Prisma entry's best-for line now say Prisma Compute has been generally available since August 2026. Checked against Prisma's backups docs and changelog on 2026-10-26. * 2026-10-24: the quick recommendation and the Prisma entry now say a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server, the API and Postgres come from one provider, in one project, on one bill; and the branching FAQ now opens with the preview each pushed branch other than the default one gets, with its own services and, for databases declared in the Composer module, its own new database, and no production data, before saying there is no database branching feature; the quick recommendation, the situation table, the Prisma entry and the comparison table now say a preview is for each pushed branch other than the default one, since a push to the default branch updates production. Checked against Prisma's pricing page, changelog and deploy-on-push docs on 2026-10-24, and the deploy-on-push docs again on 2026-10-25. * 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: pointed the Railway "opt-in" links at Railway's PostgreSQL page and the "what Railway manages" source link at that table in Railway's docs source, because Railway's databases overview page returns 404; the Railway statements are unchanged and were checked against both on 2026-10-22. * 2026-10-21: the checklist starts with where the frontend, the API and the database run; the Prisma entry opens with the note that Prisma ORM is optional, and its trade-offs add that there is no database branching feature and that point-in-time recovery is not available yet; the entry-order sentence moved from the Prisma entry to the "How we compared" note, which now says the table and the entries both list vendors in alphabetical order; and the "wrong choice" section now says there is no point-in-time recovery yet. * 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-19: the situation table, the Supabase entry's description and trade-offs, and the FAQ on whether Supabase hosts the app 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-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. * 2026-10-07: added a "Who runs the database" row checked against each vendor's docs, called Prisma Postgres managed Postgres in the summary and the first entry, added an FAQ on using Prisma Postgres and Prisma Compute without Prisma ORM and dropped the Free plan storage figure. * 2026-10-05: corrected three statements against the Railway, Supabase and Prisma docs: Railway backups need setup, Supabase hosts no frontend, and a deploy applies migrations to a preview database only with a Prisma ORM data contract. * 2026-09-30: rewrote the post as a Neon-alternatives comparison with a recommendation table, numbered entries for Railway, Render, Supabase and Vercel, a criteria table and a move-from-Neon section; re-checked all five vendors' prices and docs. * 2026-09-24: first published as a two-way comparison of Neon and Prisma Postgres with app hosting.