PlanetScale removed its perpetual free Hobby tier on April 8, 2024, and any guide still telling you to sign up for a free PlanetScale database is two years out of date. In 2026, the cheapest legitimate way to learn PlanetScale is a stack of four options used together: a 14-day developer trial of the Scaler Pro plan for the dashboard and branching experience, a local Vitess cluster in Docker for unlimited unmetered hands-on time on the same engine PlanetScale runs in production, the free vendor-published MySQL for Developers course for the relational fundamentals, and the open-source pscale CLI for muscle memory you keep after the trial ends. This guide walks every option end to end with real commands, real schema, and real cost numbers. No free-tier bait-and-switch.

This is the companion to our PlanetScale Best Practices 2026 guide. Best Practices is for engineers already shipping production on Scaler Pro. This page is for everyone earlier in that journey: students, indie devs evaluating before committing a credit card, and engineers asked to "take a look at PlanetScale" with zero budget.

Free-or-cheap learning paths at a glance (the four options)

Pin this table. Every path below is a real option in 2026, each with a concrete cost ceiling and a real upper limit on what you can build.

Paths 1 and 2 are the "actually learn PlanetScale, actually free" combo. Use path 3 in parallel for the SQL fundamentals. Path 4 is what you graduate to once you're sure.

The rest of this guide takes each path end to end with the actual commands you will run.

What changed in 2024: the Hobby tier sunset, in PlanetScale's own words

PlanetScale published the PlanetScale forever announcement on March 6, 2024. The Hobby plan was retired on April 8, 2024. The reasoning was published verbatim by founder Sam Lambert and is reproduced here because every community blog quoting the decision loses the structural argument:

PlanetScale is an infrastructure company. Our service is mission critical, and we value reliability above all else. Reliability isn't just an uptime percentage on your status page. It means your business is self-sustaining. Every unprofitable company has a date in the future where it could disappear. With an ever changing world and economy, this is a situation fraught with risk. We've chosen to build a company that can last forever. This is why I have made the decision to prioritize profitability for PlanetScale.

That paragraph is doing real work. It is the difference between "PlanetScale rug-pulled the community" (the Codú framing, and the dev.to framing, and most of the social-media discourse from April 2024) and "PlanetScale chose long-term solvency over a free tier that was bleeding the unit economics." The 2026 reading is closer to the second. Free tiers are a marketing instrument; they are not a moral obligation. PlanetScale built a high-quality infrastructure business with the kind of operational depth (Vitess Online Schema Change, deploy requests, Insights, Boost) that nobody else in the serverless-MySQL space matches, and the company decided that pricing the product to cover its cost of capital was more important than retaining the cohort of users who would never pay. That is a defensible call.

If you arrived here from a 2024 blog post written the day of the announcement, the heat has dissipated. The platform got better. The trial replaced the perpetual free tier. The learning path is different from what it was in March 2024, but it still works.

You should also know what the cost-of-not-using-PlanetScale path looks like. The LogRocket 11 PlanetScale alternatives post (the current #1 editorial result for this query, published April 5, 2024) is also stale in three specific ways: it does not mention the 14-day trial that replaced the Hobby tier, it does not mention local Vitess, and almost none of its eleven alternatives are MySQL. They are Postgres (Supabase, Neon, Tembo, Render, CockroachDB), SQLite (Turso), or proprietary stores (Convex, Astro DB, Xata). If you want PlanetScale specifically because you want MySQL-on-Vitess, the LogRocket list is not actually answering your question.

Honest scoring of the 2024 facts:

• Date announced: March 6, 2024
• Date Hobby plan retired: April 8, 2024
• What replaced it: A 14-day developer trial of Scaler Pro (no perpetual free database)
• Was anyone grandfathered: Existing Hobby databases had to migrate or were deleted; there is no grandfathered tier
• Why: PlanetScale's stated reasoning, long-term solvency of an infrastructure business

Now to the actual paths.

Path A: The 14-day developer trial: sign up, get sample data, learn the branching workflow

The trial gives you a full Scaler Pro instance for 14 days. You see the actual dashboard, you run actual deploy requests, you watch actual Online Schema Change cutovers, and at day 14 the database deletes itself unless you convert to paid. The trial is the right way to learn the dashboard-driven workflow that the platform is famous for.

Step 1: Create the account

You will need a working email address, a credit card on file (zero charge during the trial; the card is the platform's anti-abuse), and a GitHub account if you plan to use SSO. The credit-card-on-file detail is the part hobbyist learners trip over: there is no anonymous trial. If your credit card is the constraint, jump to Path B (local Vitess).

Sign up at planetscale.com/sign-up. Choose the developer trial. Confirm the email. The trial clock starts the moment your first database is created, not the moment you sign up.

Step 2: Install the pscale CLI

The CLI is the unlock for the rest of the trial. Install it once and you can do every dashboard action from the terminal.

# macOS
brew install planetscale/tap/pscale

# Linux (apt)
echo 'deb [trusted=yes] https://apt.fury.io/planetscale/ /' \
  | sudo tee /etc/apt/sources.list.d/planetscale.list
sudo apt update
sudo apt install pscale

# Windows (scoop)
scoop bucket add pscale https://github.com/planetscale/scoop-bucket.git
scoop install pscale

# Verify
pscale --version
# pscale version 0.182.x (or current as of your install)

# Authenticate (opens a browser)
pscale auth login

The pscale auth login step opens a browser and walks you through OAuth. The CLI stores a token under ~/.config/planetscale/.

Step 3: Create your first database

# Pick a region close to you: us-east-1, us-west-2, eu-west-1, ap-southeast-1, etc.
pscale database create learning-planetscale --region us-east-1

Verify

pscale database list

Connect to the main branch on localhost:3306

pscale connect learning-planetscale main --port 3306

`pscale connect` opens a secure tunnel from your machine to PlanetScale and exposes the database on `localhost:3306`. In a second terminal, open any MySQL client (DBeaver, TablePlus, MySQL Workbench, or the `mysql` CLI) against that port and the connection is live.

### Step 4: Load sample data the trial wants you to use

PlanetScale ships sample data sets in their docs. The one most worth your time is the "Vitess employees" sample, an adaptation of the classic MySQL `employees` database (about 300,000 rows across six tables).

```bash
# In one terminal, hold pscale connect open
pscale connect learning-planetscale main --port 3306

# In another, dump the employees sample
git clone https://github.com/datacharmer/test_db.git
cd test_db
mysql -h 127.0.0.1 -P 3306 -u root < employees.sql

The first time you load 300k rows over the local tunnel takes about 3-5 minutes. While it runs, browse the PlanetScale dashboard: you should see the row count climb in the Insights tab in real time.

Step 5: Open the Insights tab

This is the trial moment most worth your attention. PlanetScale Insights is a query-performance UI that surfaces slow queries, scanned-rows percentages, and missing-index suggestions automatically. With the employees sample loaded, try a deliberately bad query:

-- This query has no index on first_name; Insights will flag it
SELECT * FROM employees WHERE first_name = 'Georgi';

Run it 10-20 times. Refresh the Insights tab. The query shows up in the slow-query list with the suggested index. Apply the index via the dashboard's one-click apply, or generate the DDL and run it through a deploy request (next section). This is the workflow that is hard to replicate on any other MySQL host.

Step 6: Practice the branching workflow

The branching model is the actual product. Every schema change is a branch and a deploy request, not a mysql -h main ALTER. Practice this on the trial because the muscle memory transfers to whatever paid plan you choose.

# Create a dev branch from main
pscale branch create learning-planetscale add-first-name-index --from main

# Connect to the dev branch on a different port
pscale connect learning-planetscale add-first-name-index --port 3307

# In your MySQL client against port 3307, apply the change
# (the change does NOT touch main yet)
ALTER TABLE employees ADD INDEX idx_first_name (first_name);

# Open a deploy request to merge dev -> main
pscale deploy-request create learning-planetscale add-first-name-index

# Inspect the request
pscale deploy-request show learning-planetscale 1
pscale deploy-request diff learning-planetscale 1

# Deploy the change (Vitess Online Schema Change handles the cutover)
pscale deploy-request deploy learning-planetscale 1

Watch the PlanetScale dashboard during the deploy. You will see the OSC engine create a shadow table, copy rows in, and atomically swap. Production reads and writes continue throughout. This is the central pedagogical experience of the trial: replicating this dance on any other MySQL host requires writing your own gh-ost or pt-online-schema-change wrapper.

Step 7: Use the 14 days deliberately

Suggested cadence for the trial clock:

The day-14 deletion is non-negotiable. The card on file converts to a billed Scaler Pro plan if the database survives midnight UTC on day 15. Set a calendar reminder.

# Delete the database before the trial expires
pscale database delete learning-planetscale --force

Path B: Local Vitess in Docker, the genuinely free indefinite path

This is the wedge no competitor mentions and it is the most important section of this guide. PlanetScale is built on Vitess, the Apache-2.0-licensed sharding and scaling layer originally built at YouTube. The engine bits PlanetScale wraps in a dashboard are all open source: Vitess Online Schema Change, VStream, vtgate routing, vtctld topology, vtorc orchestration. You can run a Vitess cluster locally for $0 forever, study the same engine, and migrate your skills directly back to PlanetScale when you are ready to pay.

What you give up: the polished dashboard, the Insights query analyzer, the deploy-request UI, the managed backups, the cross-region failover. What you keep: the entire query engine, the schema-change semantics, the branching primitives (via Vitess's LocalCluster topology), the wire compatibility, and your laptop.

Step 1: Install Docker

If you do not already have Docker Desktop on Mac/Windows or Docker Engine on Linux, install it. Docker is the only prerequisite. Verify:

docker --version
# Docker version 24.x or newer
docker compose version
# Docker Compose version v2.x or newer

Step 2: The minimum-viable Vitess docker-compose

Save the following as docker-compose.yml in a new directory. This is a single-keyspace, single-shard Vitess cluster using the vitess/lite image; it boots in under a minute and exposes a MySQL-compatible port at 15306.

version: "3.8"

services:
  consul:
    image: hashicorp/consul:1.18
    command: ["agent", "-dev", "-client=0.0.0.0"]
    ports:
      - "8500:8500"

  vtctld:
    image: vitess/lite:latest
    depends_on: [consul]
    command:
      - /vt/bin/vtctld
      - --topo_implementation=consul
      - --topo_global_server_address=consul:8500
      - --topo_global_root=/vitess/global
      - --service_map=grpc-vtctl,grpc-vtctld
      - --port=15999
      - --grpc_port=15998
    ports:
      - "15999:15999"
      - "15998:15998"

  vttablet:
    image: vitess/lite:latest
    depends_on: [vtctld]
    command:
      - /bin/bash
      - -c
      - |
        /vt/bin/mysqlctl --tablet_uid=100 --mysql_port=17100 init --init_db_sql_file=/vt/config/init_db.sql
        /vt/bin/vttablet \
          --topo_implementation=consul \
          --topo_global_server_address=consul:8500 \
          --topo_global_root=/vitess/global \
          --tablet-path=zone1-100 \
          --init_keyspace=commerce \
          --init_shard=0 \
          --init_tablet_type=primary \
          --port=15100 --grpc_port=16100 --mysql_port=17100
    ports:
      - "15100:15100"
      - "17100:17100"

  vtgate:
    image: vitess/lite:latest
    depends_on: [vttablet]
    command:
      - /vt/bin/vtgate
      - --topo_implementation=consul
      - --topo_global_server_address=consul:8500
      - --topo_global_root=/vitess/global
      - --cells_to_watch=zone1
      - --tablet_types_to_wait=PRIMARY,REPLICA
      - --service_map=grpc-vtgateservice
      - --mysql_server_port=15306
      - --mysql_auth_server_impl=none
      - --port=15001 --grpc_port=15991
    ports:
      - "15306:15306"
      - "15001:15001"

This config is intentionally minimal. It uses Consul for the topology service (you can also use etcd or zk2), a single primary tablet for a keyspace called commerce, and a single vtgate. It is enough to learn the workflow.

# Boot the cluster
docker compose up -d

# Watch the logs until vtgate reports "registered"
docker compose logs -f vtgate

# Connect with the MySQL CLI
mysql -h 127.0.0.1 -P 15306 -u root --skip-ssl

You are now talking to a real Vitess cluster on localhost:15306. Any MySQL client, any ORM, any framework that speaks MySQL wire protocol works against this address.

Step 3: Apply a schema and run the same practice

Vitess Online Schema Change is available locally via the vtctldclient tool. The same DDL workflow you practiced in Path A works here, with vtctldclient ApplySchema instead of pscale deploy-request.

# Inside a one-off container that has the Vitess client tools
docker run --rm --network <your_compose_network> vitess/lite:latest \
  /vt/bin/vtctldclient --server vtctld:15999 \
  ApplySchema --sql "CREATE TABLE products (id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255));" commerce

To run an Online Schema Change with the same semantics as PlanetScale's deploy request, use the --ddl_strategy=online flag and inspect with OnlineDDL show:

docker run --rm --network <your_compose_network> vitess/lite:latest \
  /vt/bin/vtctldclient --server vtctld:15999 \
  ApplySchema --ddl_strategy=online \
  --sql "ALTER TABLE products ADD COLUMN sku VARCHAR(50);" commerce

The Vitess docs at vitess.io cover the OSC semantics in depth. The point of this section is that the same engine, the same primitives, the same workflow run on your laptop for free.

Step 4: When local Vitess is and is not enough

Local Vitess is enough to: learn the query engine, learn OSC, learn vtgate routing, learn vschema sharding, learn Vitess streaming replication, build production-quality muscle memory.

Local Vitess is not enough to: replicate the Insights query analyzer (a PlanetScale-specific UI on top of slow-query log analysis; you can roll your own with pt-query-digest or pg_stat_statements-style tools, but it is not turnkey), the managed backups across regions, the one-click branch UI (Vitess has the primitive; PlanetScale wraps it in a dashboard), or PlanetScale Boost (a specific managed query-caching layer that is a paid SKU).

For roughly 80% of what people mean when they say "I want to learn PlanetScale" (the relational engine, the branching mental model, the schema-change semantics) local Vitess is a full substitute. It is also the only learning path with no card, no clock, and no service-of-record dependency on a third party.

Path C: The free PlanetScale-published MySQL course (do this in parallel)

PlanetScale maintains a course called MySQL for Developers. It is free, requires no account, and is roughly 8-10 hours of structured video and reading. It covers schema design, indexing, query plans, joins, normalization, and the parts of MySQL that PlanetScale's platform amplifies. Here is the educator's framing: every learner who picks up the dashboard before they understand relational fundamentals ends up with the same problem. They treat the database as a key-value store, scan-everything queries, then get billed.

The course pairs naturally with Path A (the trial) because you can run the course's example queries against the trial's sample data. It pairs with Path B (local Vitess) the same way.

Time investment: 2-3 hours per session, 3-5 sessions, total 8-10 hours. Recommended cadence: do half the course before starting Path A, then alternate course videos with hands-on trial work.

PlanetScale's killer feature for beginners: the branching workflow

If you only learn one thing in your 14 days, learn this. PlanetScale's branching workflow is the single most operationally transformative pattern in the platform, and it is the answer to a real production pain (online schema changes on busy databases) that other MySQL hosts make you solve yourself with gh-ost or pt-online-schema-change.

The mental model: every schema change starts as a dev branch (a full database copy, not a logical pointer), gets verified against real data, then merges into main through a deploy request that the Vitess Online Schema Change engine executes without downtime. Application code keeps reading and writing main throughout the cutover.

Here is the full lifecycle in pscale commands, using a realistic add-soft-delete-column example:

# 1. Create a branch from main
pscale branch create my-app add-soft-delete --from main

# 2. Connect to the branch (not main)
pscale connect my-app add-soft-delete --port 3307

# 3. Apply the DDL on the branch
# (in your MySQL client connected to localhost:3307)
ALTER TABLE users ADD COLUMN deleted_at TIMESTAMP NULL;
CREATE INDEX idx_users_deleted_at ON users (deleted_at);

# 4. Verify on the branch
# Run app integration tests against localhost:3307 with the new schema

# 5. Open a deploy request
pscale deploy-request create my-app add-soft-delete

# 6. Inspect the request: diff and risk analysis
pscale deploy-request show my-app 2
pscale deploy-request diff my-app 2

# 7. Approve and deploy
pscale deploy-request review my-app 2 --approve
pscale deploy-request deploy my-app 2

# 8. Once deployed, the branch is consumed; delete it
pscale branch delete my-app add-soft-delete

Three observations a beginner often misses:

First, the dev branch is a full database with real schema and (optionally) real data. You can run integration tests against it with confidence that the schema you tested is exactly the schema that lands in production. This is not the case with shared dev databases or with schema files reviewed in code reviews.

Second, the deploy request enforces the platform's no-foreign-keys rule. If your DDL adds FOREIGN KEY constraints, the Vitess engine strips them silently during the OSC cutover. The platform-aware way to model relations is INDEX on the foreign-key column, plus application-level integrity checks. Our PlanetScale Best Practices page has the production-level treatment of this; for learning, just know that the constraint disappears.

Third, the OSC engine handles arbitrary table sizes. For tens-of-millions-of-rows tables the cutover may take hours, but it does so without blocking traffic. Compare this to a stock MySQL ALTER TABLE on a 50M-row table, which acquires a metadata lock for the duration and effectively takes the table offline for writes.

Schema management with the pscale CLI

The pscale CLI is roughly forty subcommands. You do not need all of them for learning; the following twelve cover 95% of the trial experience.

# Auth and account
pscale auth login            # OAuth login (browser)
pscale auth logout           # Drop stored credentials
pscale org list              # List your organizations
pscale org switch my-org     # Set the active org

# Databases
pscale database create <name> --region us-east-1
pscale database list
pscale database show <name>
pscale database delete <name> --force

# Branches
pscale branch create <db> <branch> --from main
pscale branch list <db>
pscale branch delete <db> <branch>

# Connections
pscale connect <db> <branch> --port 3306    # Tunnel for any MySQL client
pscale shell <db> <branch>                   # Drop into mysql shell directly

# Deploy requests
pscale deploy-request create <db> <branch>
pscale deploy-request show <db> <number>
pscale deploy-request diff <db> <number>
pscale deploy-request review <db> <number> --approve
pscale deploy-request deploy <db> <number>
pscale deploy-request cancel <db> <number>

# Passwords (connection credentials per branch)
pscale password create <db> <branch> <password-name>
pscale password list <db> <branch>
pscale password delete <db> <branch> <password-name>

# Backups
pscale backup list <db>
pscale backup create <db> <branch>
pscale backup restore <db> <branch> --backup-id <uuid>

Two specific learning exercises to internalize the CLI:

Exercise 1: Rotate a connection credential. Application code should never hold a long-lived database password. Practice the rotation: create a new password, deploy it to your app's environment variables, delete the old password. The application should keep running because PlanetScale supports multiple concurrent credentials.

pscale password create my-app main app-2026-q2
# Capture the username and password from the output
# Update your .env or platform secrets
# Wait for the deploy to roll
pscale password list my-app main
pscale password delete my-app main app-2025-q4

Exercise 2: Restore to a branch. Production data corruption is the wrong moment to learn restore semantics. Practice it on the trial:

pscale backup list my-app
# Note the most recent backup's UUID
pscale branch create my-app investigation --restore main --backup-id <uuid>
pscale connect my-app investigation --port 3308
# Connect a MySQL client and explore the restored state
pscale branch delete my-app investigation

These two exercises are not in the LogRocket post, the Codú post, or any other learn-planetscale-free competitor. They are the difference between a learner who completed a tutorial and a learner who can operate the platform.

Connecting your app: Prisma, Drizzle, raw mysql2, and deploys

The trial is only worth the calendar days if you actually wire a real application against it. The good news: PlanetScale uses standard MySQL wire protocol with TLS. Anything that connects to MySQL connects to PlanetScale.

Connection-string format

The host varies by region. The dashboard's "Connect" tab generates the full string with the right credentials.

Prisma

Prisma is the most-asked-about ORM in the trial period. Two specific PlanetScale gotchas matter:

// schema.prisma
datasource db {
  provider     = "mysql"
  url          = env("DATABASE_URL")
  relationMode = "prisma"   // <-- platform-aware: no FK constraints
}

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["driverAdapters"]
}

model User {
  id        Int    @id @default(autoincrement())
  email     String @unique
  posts     Post[]
}

model Post {
  id       Int  @id @default(autoincrement())
  authorId Int
  author   User @relation(fields: [authorId], references: [id])

  @@index([authorId])   // <-- required because Vitess doesn't enforce FKs
}

relationMode = "prisma" tells Prisma to do referential-integrity checks in application code instead of emitting FOREIGN KEY constraints in the migration. The @@index([authorId]) is required because Vitess strips foreign-key constraints; without an explicit index, joins go full-scan.

For deploys, use prisma migrate diff and prisma db push against a dev branch, not prisma migrate dev against main. Migrations live in your repo as files; the deploy-request workflow puts them in front of main.

Drizzle

// drizzle.config.ts
import type { Config } from "drizzle-kit";

export default {
  schema: "./db/schema.ts",
  out: "./drizzle",
  dialect: "mysql",
  dbCredentials: {
    url: process.env.DATABASE_URL!,
  },
} satisfies Config;

// db/index.ts
import { drizzle } from "drizzle-orm/mysql2";
import mysql from "mysql2/promise";

const pool = mysql.createPool({
  uri: process.env.DATABASE_URL,
  ssl: { rejectUnauthorized: true },
  connectionLimit: 10,
});

export const db = drizzle(pool);

For serverless deploys, swap mysql2 for @planetscale/database (the HTTP-based driver) to avoid connection-pool exhaustion across cold starts.

Raw mysql2

import mysql from "mysql2/promise";

const conn = await mysql.createConnection({
  uri: process.env.DATABASE_URL,
  ssl: { rejectUnauthorized: true },
});

const [rows] = await conn.query(
  "SELECT id, email FROM users WHERE created_at > ? LIMIT 100",
  [new Date(Date.now() - 7 * 24 * 60 * 60 * 1000)],
);

console.log(rows);
await conn.end();

Always use parameter binding (? placeholders) rather than string interpolation. The Vitess query parser will refuse certain patterns and the SQL-injection risk is real on any platform.

Deploying to Vercel, Render, or Fly

The connection string from the trial works identically across hosts. Three deployment specifics:

• Vercel: Add DATABASE_URL to the Vercel project's environment variables. For serverless functions, use @planetscale/database (HTTP) instead of mysql2. The HTTP driver avoids opening a TCP pool on every cold start.
• Render: Standard environment-variable injection. The Render runtime has long-lived processes, so mysql2 works without trouble.
• Fly.io: Set the env var with fly secrets set DATABASE_URL=.... Fly's edge proximity means cross-region latency matters; pick a PlanetScale region geographically close to your Fly app region.

Verify the connection on first deploy with the simplest possible health check:

// /api/db-health
import { connect } from "@planetscale/database";

export default async function handler(req, res) {
  const conn = connect({ url: process.env.DATABASE_URL });
  const result = await conn.execute("SELECT 1 AS ok");
  res.json({ ok: result.rows[0].ok === 1 });
}

What to do AFTER the 14-day trial ends: the decision tree

Day 14 ends and the trial database deletes itself. This is the moment most learners get stuck because no competitor guide addresses it. Here is the decision tree.

Question 1: Do I want to keep using PlanetScale specifically?

Yes → Convert to Scaler Pro. The base plan starts around $39/month plus usage (storage, queries, branches). Scaler Pro gives you the full dashboard, Insights, deploy requests, and Boost availability. This is the right choice if your project needs PlanetScale's specific differentiators (branching workflow at scale, Boost query caching, multi-region replication).

No → Go to Question 2.

Question 2: Do I need MySQL specifically?

Yes → Two real options. (a) Continue on local Vitess in Docker for indefinite hands-on time, paired with the free MySQL for Developers course. (b) Move to a managed MySQL host with a free tier; most are not Vitess-based. Aiven offers a free MySQL tier with limited storage; Railway offers free $5 of usage credits per month, enough to run a small MySQL instance; FreeSQLDatabase.com offers a free shared MySQL host for genuinely tiny projects.

No → Go to Question 3.

Question 3: Am I open to Postgres?

Yes → Neon is the closest analog to PlanetScale's branching experience, on Postgres. Free tier as of 2026 includes 0.5 GB storage, 10 branches, and unlimited databases. The mental model transfers cleanly. Supabase is the broader Postgres-plus-auth-plus-storage option (500 MB storage, 50K MAU). Render gives 1 GB SSD Postgres free.

No → Go to Question 4.

Question 4: Am I open to a non-relational store?

If yes, Turso is the SQLite-on-the-edge option (9 GB free as of 2024). Cloudflare D1 is also SQLite at the edge (5 GB/mo free).

The honest 2026 answer for someone who wants a perpetual free MySQL-on-Vitess experience is: there isn't one, because PlanetScale was the only managed Vitess offering with a free tier and they ended it. Local Vitess in Docker is the structural answer. Everything else is a different database.

Free MySQL alternatives in 2026: honest comparison

This is the table the LogRocket post is missing: a 2026 view of which alternatives are actually MySQL.

The honest read on this table: if you specifically need MySQL with branching and OSC at the engine layer, local Vitess is the only real free option. Everything else either changes the database engine or skips the branching/OSC primitive that makes PlanetScale interesting.

Frequently asked questions

Did PlanetScale really kill the free tier?

Yes. The Hobby plan was announced for retirement on March 6, 2024 and retired on April 8, 2024. The current closest free experience is the 14-day developer trial of Scaler Pro, which requires a credit card on file and deletes the database if not converted by day 15. PlanetScale's stated reason was the unit economics of running a high-quality infrastructure business; the reasoning is reproduced verbatim in the PlanetScale forever blog post. Any 2026 guide claiming you can sign up for a free PlanetScale database is incorrect.

Is the 14-day developer trial actually enough to learn PlanetScale?

For the dashboard-level experience: yes, comfortably. The 14 days are enough to install the CLI, load sample data, practice the branching workflow, run several deploy requests, exercise Insights, and connect a real app. For the engine-level depth: no. Engine learning takes months and the 14-day clock is the wrong instrument for it. Pair the trial with local Vitess in Docker (covered in Path B above) for the engine-level work and you get the best of both.

What is the best PlanetScale free alternative in 2026?

For learning the same engine: local Vitess in Docker. For an experience close to PlanetScale's branching workflow on a different database: Neon (Postgres). For hosted MySQL without Vitess: Aiven's limited free tier or Railway's $5/mo of free credits. There is no exact like-for-like free replacement; PlanetScale was the only managed Vitess service with a free tier.

Can I self-host PlanetScale?

You cannot self-host PlanetScale's specific dashboard, Insights UI, Boost caching layer, or managed-services stack. You can self-host the Vitess engine that PlanetScale wraps. Vitess is Apache 2.0 licensed and lives at github.com/vitessio/vitess. The docker-compose configuration in Path B above is a working minimal Vitess cluster. For production self-hosting, the Vitess docs and the PlanetScale team's KubeCon talks are the right starting points.

PlanetScale vs Neon for learning: which should I pick?

Neon if you can use Postgres and want a free perpetual learning environment with a branching analog. PlanetScale if you specifically need MySQL or specifically want to learn Vitess. The branching mental model is roughly transferrable in either direction. The OSC semantics differ (Vitess Online Schema Change is its own beast), so if your goal is "learn Vitess specifically," PlanetScale's 14-day trial plus local Vitess is the right combination. If your goal is "learn a serverless database with branching, free forever," Neon is the better choice.

Will PlanetScale bring back a free tier?

There is no public commitment to a new free tier as of May 2026. The 14-day developer trial is the platform's stated answer. The PlanetScale forever post made the structural argument against perpetual free tiers (long-term solvency of an infrastructure business), so do not plan around a free-tier return.

How much does PlanetScale actually cost after the trial?

Scaler Pro starts at around $39/month base with usage-based billing on storage, queries, and branches above the included quotas. Production workloads typically land in the $300-$2,000/month range depending on scale; the Best Practices page covers the production cost framing in depth. For learning specifically, a Scaler Pro instance with light usage stays well under $100/month, but local Vitess at $0 is still the more sensible choice if cost is the constraint.

Is there a discount for students or open-source projects?

PlanetScale does not publicly advertise a student or OSS discount tier as of 2026. The university tier that some 2023 community posts reference was a separate program that has been integrated into general pricing. Open-source maintainers can apply directly to sales for case-by-case sponsorship, but this is not a posted plan.

Where to go next

You now have four real paths to learn PlanetScale without spending. Recommended sequence: start with the free MySQL for Developers course (Path C) for relational fundamentals, fire up local Vitess in Docker (Path B) for hands-on engine practice, then use the 14-day trial (Path A) for the dashboard-and-deploy-request workflow, and convert to Scaler Pro only when you have a real project that justifies it.

When you are ready for production, read our PlanetScale Best Practices 2026 guide for the 30+ production patterns Scaler Pro teams actually need (connection pooling, deploy-request etiquette, index strategy, Insights workflow, Boost configuration, and the explicit foreign-key handling that bites every newcomer).

If you are still evaluating whether PlanetScale is the right fit, our PlanetScale tool page has the pricing breakdown and feature scorecard alongside the alternatives. And if you've decided MySQL-on-Vitess is not the right fit, the tutorials hub has the equivalent learning paths for Neon, Supabase, Turso, and several others.

The honest framing one more time: free PlanetScale is gone, but learning PlanetScale free is still possible, through the trial, through local Vitess, through the free course, and through deliberate practice. Pick the path that matches your constraints and ship something.

What you'll learn

Prerequisites

Step by step

1. 1

   Start with the free PlanetScale MySQL for Developers course

   Spend 8-10 hours on the vendor-published MySQL for Developers course at planetscale.com/learn/courses/mysql-for-developers. It is free, requires no account, and covers schema design, indexing, query plans, joins, and normalization. Build the relational foundation before touching the platform.

2. 2

   Install Docker and the pscale CLI in parallel

   Install Docker Desktop (or Docker Engine on Linux) and the pscale CLI via brew/apt/scoop. Verify with `docker --version` and `pscale --version`. You will use Docker for the local Vitess path and pscale for the 14-day trial path.

3. 3

   Boot a local Vitess cluster for indefinite hands-on time

   Save the docker-compose.yml from Path B (Consul + vtctld + vttablet + vtgate) and run `docker compose up -d`. Verify with `mysql -h 127.0.0.1 -P 15306 -u root --skip-ssl`. This is your $0-forever learning environment, no credit card, no trial clock.

4. 4

   Sign up for the 14-day developer trial only when you are ready to learn the dashboard

   Sign up at planetscale.com/sign-up with a credit card on file (zero charge during the trial). Run `pscale auth login`, then `pscale database create learning-planetscale --region us-east-1`. The trial clock starts when the first database is created, not at signup.

5. 5

   Load the Vitess employees sample data and practice with Insights

   Clone github.com/datacharmer/test_db and load it via `mysql -h 127.0.0.1 -P 3306 -u root < employees.sql` while `pscale connect` holds the tunnel open. Run deliberately bad queries (SELECT * with no index) and watch the Insights tab surface them with one-click index suggestions.

6. 6

   Practice the full branching workflow end to end

   Run `pscale branch create`, connect to the branch, apply DDL, open a deploy request via `pscale deploy-request create`, inspect the diff, approve, and deploy. Watch the Vitess Online Schema Change engine cut over without downtime. Repeat at least three times during the trial.

7. 7

   Connect a real application with Prisma or Drizzle

   Use `relationMode = "prisma"` and explicit `@@index` directives on FK columns (Vitess strips FOREIGN KEY constraints). For serverless deploys, use @planetscale/database (HTTP) instead of mysql2 to avoid pool exhaustion across cold starts.

8. 8

   Make the day-14 decision deliberately

   By day 13, decide: convert to Scaler Pro ($39/mo base + usage), continue on local Vitess only, switch to Neon for a Postgres branching analog, or move to Aiven/Railway for cheap hosted MySQL. If not converting, run `pscale database delete <name> --force` before day 15 to prevent surprise charges.

Common mistakes