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.