--- og_image: "/images/guides/supabase-vs-neon-vs-planetscale-serverless-db-2026.webp" title: "PlanetScale Status 2026: Supabase vs Neon vs PlanetScale" description: "Is PlanetScale still available in 2026? Compare current PlanetScale pricing and posture with Supabase and Neon for serverless database API decisions." date: "2026-03-16" updated: "2026-05-15" author: "APIScout Team" tier: 2 tags: ["supabase", "neon", "planetscale", "serverless-database", "postgres", "mysql", "api-comparison", "2026"] --- ## Is PlanetScale still available in 2026? Yes. PlanetScale is still an active database provider in May 2026, but it is no longer the same "free serverless MySQL for every side project" story many developers remember. Current official PlanetScale pages position the product around managed Postgres, MySQL/Vitess, dedicated Metal infrastructure, and query-traffic controls. That makes the right comparison less about whether PlanetScale is "gone" and more about whether its current pricing and operational model fit your workload. This guide keeps the canonical **Supabase vs Neon vs PlanetScale** decision framing, because reader intent has shifted rather than disappeared. Developers now ask about PlanetScale acquisition/status, PlanetScale pricing, and PlanetScale free-tier history, while the buying decision is still: full backend platform, branching-first serverless Postgres, or dedicated database hardware. **Supabase** is still the broadest product: Postgres plus auth, storage, edge functions, realtime, and AI/vector tooling. **Neon** is still the cleanest serverless Postgres primitive for branching, preview environments, autosuspend, and ephemeral databases. **PlanetScale** is still relevant when MySQL/Vitess, managed Postgres, or dedicated NVMe-backed database nodes are worth paying for. > **May 15, 2026 freshness note:** pricing, free-tier limits, database availability, and acquisition/status language are volatile. Re-check the official [Supabase pricing](https://supabase.com/pricing), [Neon pricing](https://neon.com/pricing), [PlanetScale pricing](https://planetscale.com/pricing), [PlanetScale Postgres](https://planetscale.com/postgres), and [PlanetScale Metal](https://planetscale.com/metal) pages before procurement. ## TL;DR Verdict Choose **Supabase** when you want a full backend platform around Postgres: database, auth, storage, realtime, edge functions, and vector tooling in one API surface. Choose **Neon** when the database itself is the product decision: serverless Postgres, copy-on-write branches, preview databases per PR, autosuspend, and pay-for-use compute. Choose **PlanetScale** when its current operational posture matches your needs: MySQL/Vitess scale, managed Postgres, dedicated Metal/NVMe performance, or schema/deploy-request workflows that your team values enough to pay for. Do not choose PlanetScale only because an older article called it a free serverless database. Current official pricing needs a fresh quote: PlanetScale's pricing page now exposes small entry nodes and Metal tiers, while the Postgres page advertises single-node starts at $5/month. Production high-availability, storage, replicas, and hardware choices can move the real bill quickly, so model your own workload instead of anchoring on legacy free-tier expectations. ## Key takeaways - **PlanetScale is active, but repositioned.** Current official pages sell PlanetScale for Postgres, MySQL/Vitess, Metal infrastructure, and query-traffic controls; the old free-tier developer narrative is not the current buying frame. - **Supabase is the broadest backend API.** Its pricing page still leads with a free plan, then paid project tiers; its docs position Postgres and pgvector as the foundation for AI/vector apps. - **Neon is the branching-first serverless Postgres default.** Its current pricing page emphasizes autoscaling, branching, read replicas, connection pooling, and usage-based CU-hour/storage pricing. - **Pricing must be rechecked close to purchase.** Supabase, Neon, and PlanetScale all expose usage-sensitive costs that can change the practical winner: compute, storage, egress, branches/replicas, and support/compliance requirements. - **Database semantics come before price.** Supabase and Neon are Postgres-first; PlanetScale can be a fit for MySQL/Vitess teams and now also sells managed Postgres. Migrating between those semantics is not a small API swap. ## What Changed Since the Old Serverless DB Narrative | Platform | What changed | Why developers care in 2026 | |---|---|---| | Supabase | Expanded beyond Postgres into auth, storage, edge functions, realtime, and AI/vector workflows. | It is often the fastest default when the database is only one piece of the backend. | | Neon | Doubled down on serverless Postgres branching, autosuspend, connection pooling, and preview-environment use cases. | It fits teams that need many short-lived databases without owning database ops. | | PlanetScale | Moved from the old hobby-tier serverless MySQL story toward managed Postgres, MySQL/Vitess, Metal/NVMe hardware, and query traffic controls. | It is still a real option, but the fit is operational scale and database workflow, not "free default for every starter app." | If your search started with “PlanetScale news 2026,” treat this as a current-status and market-fit question. The practical answer is: PlanetScale is available, but you should compare its current official pricing and product pages against Supabase and Neon before assuming older serverless database advice still applies. ## PlanetScale status: what current official pages show PlanetScale's current public pages show an active product, not a shutdown. The Postgres page describes fully managed, high-availability PostgreSQL database clusters in AWS and GCP and says single-node Postgres starts at $5/month. The pricing page lists small entry configurations and Metal options, and the Metal page frames PlanetScale as a dedicated NVMe-backed database option for MySQL and PostgreSQL workloads. That status matters for searchers reading old forum threads or pricing-change discussions. The action item is not "avoid PlanetScale because it disappeared." The action item is "verify whether today's PlanetScale economics and architecture match your workload." If you need free-tier experimentation, Supabase or Neon may be a better first stop. If you need MySQL/Vitess compatibility, non-blocking schema workflows, or dedicated hardware performance, PlanetScale can still belong on the shortlist. ## At-a-glance pricing comparison | Plan | Supabase | Neon | PlanetScale | |------|----------|------|-------------| | Free tier | ✅ 500MB database, 50K MAU | ✅ 0.5 GiB storage, 100 CU-hours/mo | ❌ Current pricing does not market a free database tier | | Entry paid | $25/mo (Pro) | Usage-based Launch with low monthly minimum | $5/mo single-node Postgres page claim; pricing page shows small PS configurations and Metal options | | Mid tier | $599/mo (Team) | Scale plan / higher CU-hour rate | Metal / HA / storage / replica choices vary by workload | | Enterprise | Custom | Custom | Custom / dedicated Metal | | Compute pricing | Hourly add-on tiers | $0.106/CU-hr (Launch), $0.222/CU-hr (Scale) | Included in Metal plan | | Storage pricing | $0.125/GB (DB), $0.021/GB (files) | $0.35/GB-month | Dedicated NVMe (plan-included) | | Autoscale | Manual tier selection | ✅ per-second, CU-based | ❌ dedicated hardware | | Scale to zero | Free projects can pause when inactive | ✅ autosuspend (configurable) | Not the core Metal posture; verify per selected plan | ### Supabase Pricing Detail Supabase prices compute separately from storage and other services: - **Free**: Pauses after 1 week of inactivity; 500MB storage; 50,000 auth users; 1GB file storage; 5GB egress; 500K edge function invocations; 2 active projects max - **Pro ($25/month)**: No pausing; includes $10 compute credit; 8GB storage; 100K MAUs; 250GB bandwidth; 7-day PITR backup - **Team ($599/month)**: SOC 2; SSO; 28-day log retention; longer backup retention - **Enterprise**: Dedicated infrastructure; SAML; custom SLAs Compute add-ons are billed hourly on top of the base plan: Small (~2GB RAM) adds ~$50/month; 2-core/8GB adds ~$110/month. Supabase migrated from PgBouncer to **Supavisor** — its own cloud-native connection pooler — supporting both session (port 5432) and transaction (port 6543) pooling modes. ### Neon Pricing Detail Neon is usage-based, priced per CU-hour (1 CU ≈ 1 vCPU + 4 GB RAM) and GB-month of storage: - **Free**: 0.5 GiB storage; 10 projects; unlimited branches; **100 CU-hours/month** (doubled from 50 in October 2025); autosuspend after 5 minutes idle; 6-hour PITR - **Launch** ($5/month minimum): Compute at $0.106/CU-hour; Storage $0.35/GiB-month; branch billing at $1.50/branch-month; higher autoscaling limits - **Scale** ($5/month minimum, higher rate): Compute at $0.222/CU-hour; includes Private Link, 99.95% SLA, SOC2 Type 2, HIPAA, SSO, dedicated support - **Enterprise**: Custom Neon's current pricing page is the source of truth for CU-hour and storage rates. The free tier's 100 CU-hours can be enough for a small application with autosuspend enabled throughout the month, but production teams should model branch count, storage growth, and always-on compute before treating it as the cheapest option. ### PlanetScale Pricing Detail (Current Status) PlanetScale pricing should be checked directly before purchase because the current public pages expose several different buying paths rather than one old serverless row-read/write model: - **Postgres single-node entry**: the PlanetScale Postgres product page says single-node Postgres starts at $5/month. - **Small pricing-page configurations**: the pricing calculator currently shows small PS configurations, with CPU, memory, storage, egress, and architecture choices affecting the quote. - **PlanetScale Metal**: the Metal page positions dedicated NVMe-backed nodes for MySQL and PostgreSQL workloads where CPU, storage, I/O, and HA topology matter more than hobby-tier economics. - **Enterprise / production topology**: high availability, replicas, regions, support, and query-traffic controls should be quoted from the current pricing page or sales flow. The practical caveat: do not compare PlanetScale to Supabase or Neon by old free-tier anecdotes. Compare it by the exact current plan shape your workload needs: MySQL/Vitess vs Postgres, single node vs HA, storage size, egress, replica count, and hardware tier. ## Architecture and Core Features ### Supabase: The Backend Platform Supabase wraps PostgreSQL with a full application backend: ```typescript // Supabase client — single import covers database, auth, storage, realtime import { createClient } from '@supabase/supabase-js' const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY) // Query with auth context (RLS enforced automatically) const { data: todos, error } = await supabase .from('todos') .select('*') .order('created_at', { ascending: false }) // Realtime subscription const subscription = supabase .channel('todos') .on('postgres_changes', { event: 'INSERT', schema: 'public', table: 'todos' }, (payload) => setTodos(prev => [payload.new, ...prev]) ) .subscribe() // File storage const { data } = await supabase.storage .from('avatars') .upload(`${userId}.jpg`, file) ``` **Supabase's differentiators:** - PostgreSQL with full extension support (pgvector, PostGIS, pg_cron, etc.) - Row-level security enforced at the database layer - Realtime subscriptions via logical replication — handles 10K+ concurrent connections - Built-in vector search for AI workloads (pgvector + Vector Buckets, Public Alpha) - Auth, Storage, Edge Functions — the full Firebase competitor - Supavisor connection pooler (replaced PgBouncer in 2024–2025) - Open source: the entire stack runs self-hosted ```sql -- Supabase vector search example CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE documents ( id BIGSERIAL PRIMARY KEY, content TEXT, embedding VECTOR(1536) ); -- Semantic search using cosine distance SELECT content, 1 - (embedding <=> $1::vector) as similarity FROM documents ORDER BY embedding <=> $1::vector LIMIT 5; ``` ### Neon: Branching-First Postgres (Now Databricks-Backed) Neon's architecture separates storage from compute, enabling features impossible with traditional PostgreSQL: ```bash # Neon CLI — manage branches like Git branches neon branches create --name feature/new-schema # Create a branch from a specific point-in-time neon branches create --name debug/prod-snapshot --parent main --timestamp 2026-03-15T12:00:00Z # List branches neon branches list # BRANCH ID NAME STATE CREATED AT # br-dawn-cloud-123 main active Mar 15, 2026 # br-cold-sun-456 feature/new-schema active Mar 16, 2026 # br-blue-moon-789 debug/prod-snapshot active Mar 16, 2026 ``` ```typescript // Different connection strings per branch — perfect for CI/CD const prodDb = neon(process.env.DATABASE_URL) // main branch const previewDb = neon(process.env.PREVIEW_DATABASE_URL) // preview branch // Each branch is a full, independent Postgres database // Branches share storage pages; only diverge on writes (copy-on-write) // Cold starts measured in milliseconds as of 2025 ``` **Neon's differentiators:** - **Branching**: Instant copy-on-write clones — every PR can have its own database with real data. Unlimited branches on free tier. - **Current Databricks-backed positioning**: the current Neon pricing page describes Neon as "Serverless Postgres, by Databricks" and emphasizes autoscaling, branching, read replicas, connection pooling, and agent/developer workflows. - **Storage-compute separation**: Neon markets its lakebase architecture, with storage-compute separation and autoscaling as core reasons to choose it for serverless Postgres. - **True scale-to-zero posture**: compute can autosuspend; test cold-start behavior in your own regions and workloads before making latency claims. - **Vercel integration**: Vercel Postgres is Neon; first-class integration with Vercel preview deployments - **AI agent story**: Purpose-built for agent systems that spin up ephemeral databases on demand ```yaml # GitHub Actions: create a fresh database per PR - name: Create Neon branch for PR uses: neondatabase/create-branch-action@v5 with: project_id: ${{ env.NEON_PROJECT_ID }} branch_name: preview/pr-${{ github.event.number }} api_key: ${{ secrets.NEON_API_KEY }} id: create_branch - name: Run migrations on PR branch run: npx prisma migrate deploy env: DATABASE_URL: ${{ steps.create_branch.outputs.db_url_with_pooler }} ``` ### PlanetScale: MySQL, Postgres, and Metal-oriented Database Ops PlanetScale now needs to be evaluated as a current database operations platform, not just as the old serverless MySQL startup favorite. Its official pages describe managed Postgres clusters, MySQL/Vitess heritage, Metal/NVMe performance, and schema/deploy workflows: ```typescript // PlanetScale uses standard MySQL/Postgres drivers import { connect } from '@planetscale/database' const conn = connect({ host: process.env.DATABASE_HOST, username: process.env.DATABASE_USERNAME, password: process.env.DATABASE_PASSWORD }) const results = await conn.execute('SELECT * FROM users WHERE id = ?', [userId]) ``` **PlanetScale's differentiators:** - **Active current status**: current product pages market PlanetScale for Postgres, pricing plans, and Metal infrastructure. - **Deploy requests**: Schema changes can go through a review/approval workflow before applying to production. - **Non-blocking schema changes**: MySQL/Vitess workflows remain a reason to consider PlanetScale for large MySQL estates. - **Metal hardware**: Dedicated NVMe SSD posture for workloads where local storage performance and predictable database nodes matter. - **PostgreSQL support**: PlanetScale now also sells managed Postgres; verify feature parity, pooling, extensions, and HA details against current docs before migration. ```bash # PlanetScale schema workflow pscale deploy-request create my-database add-user-roles --branch main # Creates a deploy request that can be reviewed before applying # Non-blocking: the migration applies without locking the table ``` ## Connection Pooling All three platforms handle connection pooling differently, and this matters for serverless and edge deployments: | Platform | Pooler | Method | Notes | |----------|--------|--------|-------| | Supabase | Supavisor (built-in) | Session + Transaction modes | Replaced PgBouncer 2024–2025 | | Neon | PgBouncer (built-in) | HTTP WebSocket driver | Up to 10K concurrent connections | | PlanetScale | Vitess / Postgres infrastructure | Driver and plan dependent | Verify pooling, connection limits, and proxy behavior for the selected MySQL or Postgres plan | ```typescript // Neon serverless driver — works in Cloudflare Workers / Vercel Edge import { neon } from '@neondatabase/serverless' // HTTP-based queries, no persistent TCP connection needed const sql = neon(process.env.DATABASE_URL) const posts = await sql`SELECT * FROM posts WHERE published = true` // Supabase — works via its JS client everywhere (Supavisor handles pooling) // PlanetScale — database/js driver uses HTTP proxy under the hood ``` ## Vector Search / AI Workloads | Platform | Vector Support | Implementation | Notes | |----------|---------------|----------------|-------| | Supabase | ✅ First-class | pgvector + Vector Buckets (Alpha) | Hybrid search, LangChain integration | | Neon | ✅ | pgvector via extension | Lakebase also supports PostGIS | | PlanetScale | ⚠️ Limited | Postgres only | Not marketed; MySQL has no pgvector | The AI workload story diverges sharply. Supabase is building dedicated vector infrastructure (Vector Buckets). Neon's AI story is about **agentic provisioning** — AI agents spinning up and tearing down databases on demand is the primary use case Databricks acquired them for. PlanetScale is not competing in this space. ```sql -- Neon pgvector — same syntax as Supabase CREATE EXTENSION vector; CREATE TABLE embeddings ( id SERIAL PRIMARY KEY, content TEXT, embedding VECTOR(1536) ); -- cosine similarity search SELECT content, 1 - (embedding <=> $1) as similarity FROM embeddings ORDER BY embedding <=> $1 LIMIT 10; ``` ## Development Workflow Comparison | Feature | Supabase | Neon | PlanetScale | |---------|----------|------|-------------| | Local development | Supabase CLI + Docker | Local proxy / Neon CLI | pscale CLI / local MySQL or Postgres | | Schema migrations | Supabase migrations | Any Postgres migration tool | Deploy requests | | Preview environments | Via migrations (no native branching) | Native copy-on-write branching ✅ | Via dev branches (per-cluster) | | Point-in-time restore | ✅ (Pro+) | ✅ (6hr free, PITR on paid) | ✅ | | CLI tooling | `supabase` CLI | `neon` CLI | `pscale` CLI | Neon's copy-on-write branching is fundamentally different from PlanetScale's deploy-request branching. Neon branches are **instant data + schema clones that cost nothing until they diverge**. PlanetScale's branches run on separate dedicated clusters and are schema-change workflow tools, not data snapshots. Supabase has no native branching equivalent. ## When to Choose Each ### Choose Supabase if: - Building a full-stack app and want auth, storage, and database in one platform - Need realtime subscriptions (multiplayer features, live dashboards) - Building AI features that require vector search (pgvector + Vector Buckets) - Want the most features on the free tier - Prioritize open source and the option to self-host - Replacing Firebase — Supabase is the best Firebase alternative in 2026 ### Choose Neon if: - Database branching per PR is a requirement for your CI/CD workflow - Deploying on Vercel (Vercel Postgres = Neon; first-class integration) - Building AI agent systems that provision databases dynamically - Need true scale-to-zero cost optimization (pay for actual seconds of compute) - Want the pure Postgres database primitive — no BaaS overhead - Databricks ecosystem alignment matters (Lakebase integration) ### Choose PlanetScale if: - Existing MySQL codebase (Rails, Laravel, legacy PHP) at high scale - Need Vitess horizontal sharding — the tech behind YouTube's database - Non-blocking schema changes on production tables with billions of rows - Can absorb current PlanetScale plan economics after modeling storage, HA, replicas, and hardware tier - Want managed Postgres or MySQL/Vitess on PlanetScale's current infrastructure - The deploy request schema review workflow fits your team's process --- *Track Supabase, Neon, and PlanetScale API health and usage trends on [APIScout](https://apiscout.dev).* *Related: [Supabase vs Firebase](/guides/supabase-vs-firebase-developer-comparison-2026) · [LLM API Pricing 2026](/guides/llm-api-pricing-comparison-2026) · [Vercel AI SDK vs LangChain](/guides/vercel-ai-sdk-vs-langchain-2026)* ## Search Intent Refresh: PlanetScale News and Serverless DB Choice Searchers landing here often want to understand whether pricing and platform changes should alter their database choice. The practical answer: choose Supabase when you want a broader app platform around Postgres, Neon when you want serverless Postgres branching and scale-to-zero ergonomics, and PlanetScale when MySQL/Vitess workflows and operational model fit your team. Decision checklist: - Choose based on database semantics first: Postgres vs MySQL is not a minor detail. - Test branching, migrations, connection pooling, and local development workflows. - Model pricing at realistic storage, compute, and connection levels rather than free-tier demos. - Verify backup, restore, observability, and production support before migration. ## Source notes and methodology This refresh prioritizes PlanetScale current-status, pricing, availability, and free-tier-history questions while preserving the canonical serverless database decision-guide role. It answers those status questions in this comparison guide without creating a separate news URL. Source-backed evidence reviewed on May 15, 2026: - [Supabase pricing](https://supabase.com/pricing) for current free/pro/team posture, project limits, database size, auth MAU limits, and compute-credit framing. - [Supabase AI & Vectors documentation](https://supabase.com/docs/guides/ai) for Postgres/pgvector AI workload positioning. - [Neon pricing](https://neon.com/pricing) for current free-plan, Launch/Scale, CU-hour, storage, branching, autoscaling, and connection-pooling language. - [PlanetScale pricing](https://planetscale.com/pricing) for current pricing-page posture, small configurations, architecture/storage/egress inputs, and Metal options. - [PlanetScale Postgres](https://planetscale.com/postgres) for current Postgres availability and single-node starting-price language. - [PlanetScale Metal](https://planetscale.com/metal) for current dedicated NVMe/Metal positioning and performance claims. Pricing and availability are volatile. Treat every dollar amount and free-tier limit here as a planning prompt, not a procurement quote; re-open the vendor pages before signing up, migrating production, or publishing a budget. ## FAQ ### Is PlanetScale shut down? No. Current official PlanetScale pages still market active Postgres, pricing, and Metal products. The better question is whether the current PlanetScale product and price model match your workload, because older free-tier advice may be stale. ### Did PlanetScale become a Postgres provider? Yes, PlanetScale now markets a managed Postgres product alongside its MySQL/Vitess heritage. If you are evaluating PlanetScale for Postgres, test extension support, connection behavior, backup/restore, HA topology, and migration tooling rather than assuming it behaves like Neon or Supabase. ### Should a new app start on Supabase, Neon, or PlanetScale? For a new product that needs auth, storage, realtime, and database together, start with Supabase. For a database-first Postgres app that needs branching and preview databases, start with Neon. For teams with existing MySQL/Vitess needs, large schema-change workflows, or dedicated hardware requirements, evaluate PlanetScale with a current quote. ## Related Guides - [Best Database-as-a-Service APIs](/guides/best-database-as-a-service-apis-2026) - [Best Serverless Database APIs](/guides/best-serverless-database-apis-2026) - [Neon vs Turso](/guides/neon-vs-turso-2026) - [Convex vs Supabase](/guides/convex-vs-supabase-2026) - [Supabase vs Firebase](/guides/supabase-vs-firebase-developer-comparison-2026) - [Best database APIs and platforms](/apis/database) - [Supabase API profile](/apis/database/supabase) - [Neon API profile](/apis/database/neon)