Prisma Postgres – Runs on bare metal and unikernels

Technical approach (Firecracker + unikernels)

  • Service runs Postgres on Firecracker microVMs and unikernels (via Unikraft) to achieve “scale-to-zero” with millisecond startup.
  • Memory reclaim is handled by Firecracker’s ballooning; unikernels mainly reduce baseline memory footprint.
  • Some see this as real innovation vs reselling existing serverless PG; others note VM snapshots + fast boot are conceptually similar to existing patterns.

Pricing and billing model

  • Core shift: charge by number of queries/events, not by CPU or instance size.
  • 60k queries/month are free; above that, a per‑million‑queries rate applies, varying by plan.
  • Many find the pricing page confusing: overlap between free and paid tiers, unclear egress costs, and difficulty estimating query volumes.
  • Critics compare costs unfavorably to cheap VPS or reserved managed Postgres; others argue the price includes global caching, pooling, and real‑time features.

Performance, limits, and suitability

  • Each additional concurrent query allocates more compute; all queries share a pool and have strict timeouts (default 10s, max 60s).
  • Supporters say production OLTP workloads should have timeouts anyway.
  • Detractors say hard limits and per‑query billing discourage complex or long‑running analytics queries and make the service a non‑starter for mixed OLTP/analytics DBs.
  • Some question Prisma ORM overhead and want benchmarks vs raw Postgres.

Comparisons and alternatives

  • Neon is seen as more feature‑rich today (e.g., branching), with Prisma aiming for parity plus no‑cold‑start and deeper data‑layer integration.
  • Nile is mentioned as another serverless Postgres provider with simpler pricing.
  • Some note similarities between Accelerate and Cloudflare Hyperdrive‑style global DB access.

Self‑hosting and lock‑in

  • Prisma Postgres, Accelerate, and Pulse are not planned for self‑hosting.
  • This worries users considering Pulse/CDC for mission‑critical or on‑prem needs; they see real vendor lock‑in.

ORM and product direction

  • Discussion revisits Prisma’s history (GraphQL BaaS → proxy → ORM) and the Rust sidecar “query engine.”
  • The Rust process is slated to become optional; driver adapters already allow using native DB drivers.
  • Users complain about long‑standing ORM issues (missing Postgres features, JSON/geospatial gaps, performance, case‑sensitive naming, lack of partial indexes/partitions).
  • Prisma acknowledges poor communication about issue prioritization and promises more transparency.

Operational concerns and target use cases

  • Early access: no production recommendation, 1GB DB size cap, no scaling config yet; GA is planned to add autoscaling, larger instances, and direct DB access.
  • Some see it as ideal for many small, low‑maintenance databases or microservices; others argue standard Postgres on k8s or a VPS is cheaper and simpler if you already have ops capability.