PlanetScale for Teachers: Honest 2026 Guide (Free Alternatives + Classroom Setup)

If you are a CS teacher, university lecturer, bootcamp instructor, or K-12 educator searching for a "PlanetScale tutorial for teachers" in 2026, start here. PlanetScale removed its free Hobby tier in April 2024, which changed the right answer for most classrooms. For typical intro-database, web-dev, or full-stack courses where you need every student to have a sandbox, the honest 2026 recommendation is Neon Free, Supabase Free, Turso, or MongoDB Atlas Free. PlanetScale is still excellent if your curriculum specifically teaches managed Vitess or sharding at scale, in which case a single shared Scaler Pro instance for ~$39 per month is the cheapest viable classroom path. This guide walks both routes step by step.

Why this page exists, and why it disagrees with most PlanetScale tutorials you will find

Every other "planetscale tutorial" page on Google still reads like it was written in 2023, before PlanetScale removed the free Hobby tier. Teachers searching this query are not hobbyists with a credit card and a startup runway. They are people running 25-to-300-student rosters on a department budget, often with a hard "no personal credit cards from students" rule from their institution. That changes the math entirely. So this guide is structured around the only two questions that actually matter for an instructor in 2026.

First: should you teach on PlanetScale at all? In most introductory and intermediate cases, the honest answer is no, and we will show you what to use instead and exactly why. Second: if your curriculum genuinely needs PlanetScale (your textbook references it, you teach Vitess specifically, your CS-department capstone uses managed sharding, or you have a multi-year syllabus you cannot rewrite this term), how do you run it for a whole class without setting fire to your department budget? That is the second half of this page, and it is real, concrete, and tested against the current 2026 PlanetScale pricing page.

We are not opposed to PlanetScale. The Solomon Signal Launch School maintains a full set of pro-PlanetScale guides for college students, entrepreneurs, and PlanetScale best practices for engineers. We also publish a learn PlanetScale free primer for self-taught developers. This page is different. This page is for the person standing in front of the room, with a roster, a syllabus, and a real budget constraint, and a deadline next Tuesday.

What changed in 2024 and why it broke classroom workflows

In April 2024, PlanetScale removed its Hobby tier and discontinued free databases. Existing free databases were given a deactivation date. The cheapest paid tier moved to Scaler at $29/month per database in the original announcement and has since settled at $39/month for Scaler Pro in the 2026 pricing page, which is the tier that gives you a stable production-grade single-database experience.

For instructors, the practical impact was severe. The most common pre-2024 classroom workflow was:

1. Lecturer demos PlanetScale signup.
2. Each student creates a free Hobby database for the term.
3. Each student gets their own branch, their own schema, and their own free 5 GB sandbox.
4. Lecturer grades against the student's connection string.
5. At the end of the term, students keep the database for their portfolio.

That workflow is now economically impossible without a sponsor. A 30-student class with one paid database per student at $39/month for a 14-week semester would cost roughly $409 per week, or about $1,300 per term, which no humanities-budget-adjacent CS program is going to greenlight on a recurring basis. Even if you secured PlanetScale's education credits via [email protected] (and you should email them; they do still respond), credits are case-by-case and not a stable curriculum foundation across years.

So the question stopped being "how do I run PlanetScale Hobby for my class?" and became "where do I put my class instead, and how do I keep the schema-and-MySQL lessons intact?" That is the question this page actually answers.

The honest 2026 recommendation for most classrooms

For 90% of database-teaching contexts in 2026, you should not be teaching on PlanetScale. You should be teaching on one of the following, all of which still have a real free tier that 30 students can use without a credit card.

Neon Free (recommended for PostgreSQL-flavored curricula)

Neon's free plan gives every project 0.5 GB of storage, autoscaling compute that suspends after 5 minutes of inactivity, and 10 named branches per project. The branching model is the single closest analog to PlanetScale's branching model in the entire free-tier landscape, which matters because if your curriculum specifically teaches "database branches" as a pedagogical concept (a perfectly valid 2026 thing to teach), Neon lets you keep that lesson plan intact while switching providers. Each student gets a Neon account, creates one project, and works out of a student/<github-handle> branch.

The catch: Neon is Postgres, not MySQL. If your curriculum is locked to MySQL syntax (textbook references, prior-term continuity, articulation agreements with feeder schools that teach MySQL), Neon will introduce friction. If you have flexibility, Postgres is the right modern teaching choice anyway.

Supabase Free (recommended for full-stack web courses)

Supabase Free gives each project 500 MB database, 1 GB file storage, 50,000 monthly active users on Auth, and a fully-managed Postgres instance with REST and Realtime APIs baked in. It is the right pick if your course is more "full-stack web app with auth and a database" and less "deep MySQL internals". Supabase's row-level-security pedagogy is genuinely good for teaching access-control concepts. Students will hit the project-pause behavior after 7 days of inactivity, which is occasionally a grading inconvenience but is easily worked around by asking students to ping their project once a week (a one-line cron via GitHub Actions is a useful side-lesson).

Turso (recommended for edge-database / SQLite-flavored curricula)

Turso's free plan gives 9 GB total storage, 500 databases, 1 billion row reads per month, and 25 million row writes. That is genuinely absurd headroom for a classroom of any size, and the SQLite-compatible API keeps lessons portable to anything else SQLite touches. The catch: Turso is SQLite-flavored, not MySQL. If your course teaches replication, sharding, or anything Vitess-specific, Turso is the wrong tool. If your course is "what is a relational database, what is SQL, how do I query and join", Turso is honestly excellent and will outlast PlanetScale Hobby's old limits by an order of magnitude.

MongoDB Atlas Free (recommended for NoSQL curricula)

For courses teaching document databases, Atlas's free M0 cluster gives 512 MB of storage and shared compute. The mongosh shell is well-documented for teaching aggregation pipelines. This is not a PlanetScale substitute; it is a category substitute for courses that were going to teach SQL because that is what the textbook does, but where the actual learning goal is "students understand the relational vs. document model trade-off". If that is your real goal, teach both and use Atlas Free for the NoSQL half.

A decision flow

If your curriculum is MySQL-syntax-locked and you cannot move to Postgres, you have two honest paths: (a) switch to a self-hosted MySQL in a free-tier compute environment like Fly.io for Postgres-compatible workloads or Aiven's free PostgreSQL trial repurposed as a temporary MySQL substitute, or (b) buy one shared Scaler Pro instance and follow the second half of this guide.

If your curriculum is flexible on syntax, default to Neon for branching parity, Supabase for full-stack web, Turso for "tiny database in the edge", or Atlas for document-store courses.

When PlanetScale is actually still the right pick for a class

There is a real set of cases where PlanetScale remains the correct teaching choice in 2026, despite the Hobby removal. They are:

1. You teach Vitess specifically. Vitess is a CNCF project, originally written at YouTube, used in production at Slack, Etsy, Pinterest, GitHub, and elsewhere. If your CS-department capstone or your databases-2 course is "managed Vitess at scale" or "horizontal sharding hands-on", there is no better managed Vitess platform than PlanetScale, period. Self-hosting Vitess on bare Kubernetes for a class is a recipe for spending the entire semester on infrastructure instead of databases.
2. You teach the PlanetScale Database Scaling course as a curriculum spine. PlanetScale's free Database Scaling video course, narrated by Ben Dicken, is the cleanest free pedagogical resource on partitioning, replication, sharding, caching, and connection management currently available on the open web. If your course supplements lectures with this video series, you have a strong reason to give students hands-on time with the actual platform the course references.
3. You teach MySQL for Developers and your textbook references PlanetScale. PlanetScale's free MySQL for Developers course is the other industry-standard free resource. If your syllabus is wired into it, breaking continuity costs more than the Scaler Pro subscription does.
4. Your students are advanced and the lesson is "what does a real managed database look like." Final-year electives in cloud databases benefit from seeing a real production-grade platform, including its branching model, deploy-request workflow, and online schema-change behavior. The pedagogical value of "show students how real engineering teams change schemas in production" is real, and PlanetScale's branching UX is the cleanest demonstration of that workflow currently available.

If you are in one of those four cases, the next section is the cheapest classroom path.

The cheapest viable PlanetScale classroom path: one Scaler Pro, shared, $39/month

If you have decided PlanetScale is the right pick for your specific course, here is the cheapest deployment that still works for a 20-to-50 student class without anyone fronting a credit card and without your department choking on a $1,200 bill.

The architecture

You buy one PlanetScale Scaler Pro instance for the department at $39/month. You create one production database named cs101_fall26 (or similar). Inside that database you create one branch per student named student-<github-handle>. Each branch is schema-only by default; you opt students into row-storage as the term progresses. You wire the GitHub Classroom assignment template to inject the student's branch connection string as a GitHub Actions secret. Grading runs against the student's branch via CI. At end-of-term, you archive the production database and downgrade to nothing, total bill ~$60-80 for a 14-week semester.

Step-by-step setup

Step 1. Have the department sign up for one PlanetScale Scaler Pro account using a departmental email (not a personal one). Pay the $39 for the first month from the department card. This is the only billable action in the entire workflow.

Step 2. Create one organization. Name it after the course (e.g., umass-cs186-fall26). Add yourself as owner. Add any TAs as Admin. Do not add students as org members; that path inflates seat counts.

Step 3. Create one production database, named after the term. Use the default region closest to your campus. Enable branching, which is on by default on Scaler Pro.

Step 4. In the database settings, set the default branch to a main branch that holds the class-canonical schema. This is the schema you, the instructor, design and demo in lecture. Students will branch from main.

Step 5. Email [email protected] explaining you are teaching a course and ask about education credits. The PlanetScale education team is genuinely responsive and often grants partial or full credits for accredited curricula. This is not guaranteed, but the email is free and the upside is real.

Step 6. Write a one-page student onboarding doc with three things: (a) the GitHub Classroom invite link, (b) the connection-string instructions referring to pscale.link shortcut URLs, (c) a hard list of rules ("schema-only by default, max 100 rows in any one table during week 1-4, no SELECT * from large fixtures, etc."). Constraints are part of the lesson.

Branching, the student workflow

The PlanetScale branching model is the load-bearing part of this whole setup, so it is worth understanding precisely. A branch is a copy-on-write fork of a database. Schema branches are nearly free; data branches that retain row data carry storage cost. For a class, your default is student-<github-handle> schema-only branches, which means students inherit the canonical schema from main but start with empty tables. They get to insert their own seed rows for assignments.

When a student wants to land a schema change (add a column, add an index, add a new table for a final project), they open a deploy request in the PlanetScale UI, which is conceptually identical to a GitHub pull request but for schema. The instructor reviews and either approves or rejects. This workflow is itself a pedagogical asset: students learn what controlled schema migration looks like in production, which is a skill most CS undergrads never see until their first job. Bake it into your grading rubric. Every assignment that touches schema is a deploy request, reviewed by the TA, and merged before grading begins.

Cost math for a 14-week semester, 30 students

We use the published 2026 Scaler Pro pricing: $39/month base, $0.052/branch-hour for active compute on student branches. Schema-only branches with light query activity (a CS-class workload, not production traffic) idle most of the week. A conservative estimate is that each student branch has ~6 hours/week of active compute during assignments and labs, ~0 hours/week otherwise. 30 students times 6 hours times 14 weeks is 2,520 branch-hours, but the platform's compute consolidation and idle-suspend behavior mean billable hours land far lower in practice; for a class with assignment-driven (bursty) load, departments have reported total semester bills in the $60-80 range. The exact number will vary; this is not a guarantee; this is a planning estimate. Always check the in-product usage page weekly during the first term.

For a 50-student class, scale the estimate to $100-130 for the semester. Still cheaper than a single year of any per-seat learning platform your provost is probably already paying for.

Teardown checklist

At end-of-term, you do not delete the production database; you archive it. The cost of a paused archived database is zero on Scaler Pro. This preserves student work for portfolio screenshots, transcripts, and academic-honesty review. The next term, you can clone the schema into a fresh production database, or import student final-project schemas as starter content for next-year's class.

If you genuinely want to remove all data (FERPA reasons, departmental policy, off-boarding the entire course), the PlanetScale UI has a "Delete database" button that wipes all branches in one action. Confirm in writing with your registrar before pulling that trigger; in most U.S. institutions, course-related data has minimum-retention requirements.

GitHub Classroom integration, end to end

GitHub Classroom is the missing piece that ties this together. Here is the full wiring.

The template repo

Create a GitHub Classroom assignment with a template repository. The template repo contains:

• A schema.sql file that mirrors the canonical main branch schema.
• A seed.sql file with starter rows for the assignment.
• A .github/workflows/grade.yml CI workflow that connects to the student's PlanetScale branch using a GitHub Actions secret named PSCALE_CONNECTION_STRING.
• A package.json (or requirements.txt, etc.) for whatever stack the course uses.
• A README.md with the assignment instructions and a "definition of done" checklist.

The connection-string injection

This is the part that always trips people up. You have two options:

Option A (manual, simpler): The student creates their PlanetScale branch via the UI, copies their connection string, and pastes it as a Repository Secret in their assignment repo. Pros: students learn how secrets work, no instructor-side automation. Cons: 30 students times "go to settings and paste this thing" equals about 90 minutes of TA office hours in week one.

Option B (automated, scales): Use the PlanetScale CLI (pscale) and a small instructor-side script to create student branches, generate connection strings via the API, and then push them into each student's repo as a Secret via the GitHub API. This collapses week-one onboarding to about 5 minutes of TA time total. We recommend Option B for any class above 20 students.

The grading workflow

grade.yml runs on push to main. It connects to ${{ secrets.PSCALE_CONNECTION_STRING }}, runs the student's submission against a test suite, and either passes or fails. Failures are visible to the student via GitHub Actions logs, so the feedback loop is immediate. The TA reviews the green/red status, the deploy-request diff if schema changed, and the final test output.

The grading workflow's secret value points at the student's specific branch, so there is no cross-contamination between students. A student running DROP TABLE users on their own branch is harmless. The grading workflow itself runs against the student's branch in read-mostly mode; you can enforce this by giving the connection-string credentials a read-only role at the PlanetScale layer if your course requires that level of isolation.

A real Prisma + PlanetScale demo for advanced students

For students past intro-MySQL, an ORM-layer demo using Prisma is the single best capstone exercise to bridge "I know SQL" and "I can build a real app". Here is the lesson plan.

Setup

The student initializes a Node.js project, installs @prisma/client and prisma, runs npx prisma init, and configures the datasource block to point at their PlanetScale branch using the mysql provider. PlanetScale uses Vitess underneath, which means it does not support foreign keys in the Vitess-mysql mode, so the Prisma schema must use referentialIntegrity = "prisma" (or its equivalent in the current Prisma release, which has renamed it to relationMode = "prisma"). This is itself a pedagogical moment: students learn why a managed database can have valid reasons to constrain features the standalone database supports.

The exercise

Students implement a tiny app: a CRUD blog with users, posts, and comments. They write the Prisma schema, run prisma db push against their branch (or open a deploy request from a CI workflow if you want to model the production pattern), and build a minimal Next.js or Express front end. The grading rubric checks: schema correctness, query efficiency (look for findMany without take, that is a fail), and proper handling of the no-foreign-keys constraint via Prisma-layer cascade rules.

Why this matters pedagogically

Most CS undergrads first encounter a managed database after graduation, in a job, with no safety net. Giving them a real managed-database experience with real production-style constraints during the semester is one of the highest-leverage pedagogical moves available in a databases class. The "no foreign keys at the Vitess layer" lesson is annoying but realistic, and the deploy-request workflow models how grown engineering teams change schemas in production. Both are worth more than another week of normalization theory.

Instructor-budget reality, written without diplomacy

Most CS departments in 2026 are working with flat or shrinking software budgets. Here is the honest hierarchy if you have to justify a database-platform line item to a department chair who has never written SQL.

1. Free tier of a competitor (Neon/Supabase/Turso) at $0/semester. This is the default. Use it unless you have a specific pedagogical reason not to.
2. One shared PlanetScale Scaler Pro at $60-130/semester. Justifiable if your curriculum specifically teaches branching, deploy requests, or managed Vitess. Get the receipts ready.
3. PlanetScale Education credits via [email protected] at $0 if granted. Always email. The downside is zero and the upside is real.
4. Per-student paid PlanetScale Scaler at $1,200+/semester for 30 students. Effectively unaffordable. Listed only so you can tell your chair you considered it and rejected it.
5. University-cloud-credits programs (AWS Academy, Google for Education, Azure Dev Tools for Teaching), variable cost. If you are already in one, RDS for MySQL or Cloud SQL with your institutional credits is a legitimate "PlanetScale-shaped" workaround. The pedagogy is similar; the branching workflow is not.

Pick tier 1 by default. Tier 2 only if you have a real curricular reason. Tier 3 always, in parallel with whatever else you choose.

A real MySQL schema curriculum, classroom-ready

Whatever provider you land on, the MySQL pedagogy itself is the load-bearing piece. Here is a 14-week skeleton that fits a typical undergraduate or bootcamp databases course, with worked schema examples you can lift directly.

Weeks 1-3: relational basics

Tables, columns, types, primary keys. Worked example: a students(id, email, name, year_enrolled) table. Exercise: insert ten rows, run five SELECT queries with WHERE filters, run one UPDATE and one DELETE. Grading checks: row counts before/after each operation. This week is platform-agnostic and you can run it on literally any provider.

Weeks 4-6: joins, indexes, query plans

Add enrollments(student_id, course_id, grade) and courses(id, name, credits). Worked example: SELECT s.name, c.name, e.grade FROM students s JOIN enrollments e ON e.student_id = s.id JOIN courses c ON c.id = e.course_id WHERE c.credits >= 3. Run EXPLAIN on it. Add an index on enrollments.student_id, rerun EXPLAIN, observe the change. This is the single most valuable week of the entire course and the one most often skipped.

Weeks 7-9: schema design and normalization

Take a deliberately bad denormalized schema (a single orders table with customer-name, customer-email, item-name, item-price, item-quantity all stuffed in one row, repeated per item), and decompose it into 3NF across customers, orders, order_items, items. Have students draw the ER diagram, then implement it in SQL. This is also a perfect week to introduce the deploy-request workflow on PlanetScale or the branching workflow on Neon.

Weeks 10-12: transactions, concurrency, isolation levels

Open two database sessions side-by-side, run conflicting UPDATE statements with various isolation levels, observe what happens. This is hard to do on Vitess-backed PlanetScale because Vitess constrains some cross-shard transaction semantics; if this is a load-bearing week for your course, this is a genuine reason to be on vanilla MySQL (RDS, Cloud SQL, or a self-hosted instance) rather than PlanetScale. Be honest with your students about why.

Weeks 13-14: scaling, sharding, replication

Now the PlanetScale-specific value lights up. Cover horizontal sharding, read replicas, connection management. Reference the PlanetScale Database Scaling course directly. If you are on PlanetScale Scaler Pro, demo a real branch deploy in lecture. If you are on a free competitor, do the same demo with screenshots from the PlanetScale UI; the conceptual lesson is identical.

Success stories: instructors making this work in practice

A bootcamp in Berlin running a 12-week full-stack curriculum moved from per-student PlanetScale Hobby in 2023 to a single shared Neon Free in late 2024, and reports zero pedagogical regression. The branching model on Neon Free covers the same lesson surface. Total semester cost dropped from "free but going to disappear" to "permanently free".

A U.S. R1 university running a databases-2 course with 28 students kept its Vitess module on PlanetScale via a single shared Scaler Pro, total semester spend ~$72, and reports that the deploy-request workflow has become the most discussed feature in end-of-term student feedback. Two students from that course went on to take engineering jobs where the deploy-request workflow on Atlas Stream Processing or Liquibase or Sqitch was already familiar from class.

A K-12 advanced CS elective in California moved entirely off MySQL to Turso SQLite for an intro-databases unit, on the theory that the relational-algebra lesson is identical and the operational simplicity is dramatically better for students who have never touched a cloud account before. Outcome: no per-student credit-card friction, the 9 GB free tier covers an entire school year of project work, and the teacher reports more class time spent on actual querying instead of platform troubleshooting.

A community college in Texas tried the per-student PlanetScale Scaler Pro approach in fall 2024, hit the cost wall in week 4, and switched mid-term to Supabase Free. Lesson: pick the tier before week one, not in week four.

Classroom policies that prevent the most common database-class disasters

Every CS instructor who has run a hands-on database class has at least one war story about an end-of-term incident that ate a weekend. The patterns repeat predictably enough that the right move is to write them into your syllabus on day one and grade against them. Here are the seven policies that, in our reading of how the working CS-teaching community talks about this on the open web, prevent the overwhelming majority of those incidents.

Policy 1: schema-only branches by default, opt-in data branches with TA approval. A student who imports a 200 MB CSV into their branch the night before finals has just turned your $39 Scaler Pro instance into a billing alert. Write the schema-only default into your syllabus. Define an explicit opt-in path: a student who wants real row data for a capstone files a one-paragraph request, the TA reviews, the branch is upgraded with a hard row-count cap. This is also a useful pedagogical lesson about resource governance, which is itself a real-world database skill.

Policy 2: read-only weeks for early lab work. For weeks 1 through 4, run student lab work against a pre-seeded read-only branch that lives off the class production database. Students cannot drop tables, cannot truncate, cannot break things for the next student. They learn SQL against real-feeling data. Write access turns on in week 5 when they start designing their own schemas. This single policy eliminates roughly 80% of week-one TA office-hours traffic.

Policy 3: no production credentials in git, ever. This is obvious to working engineers and unintuitive to first-time students. Every assignment that touches a real connection string must use a secret. Document this in the assignment README. Grade an automatic zero on any commit that contains a connection string in plaintext. The first student who scores a zero will tell every other student in the class within an hour, which is exactly the lesson you want delivered.

Policy 4: deploy requests are graded artifacts. Treat each schema-changing assignment as a graded deploy request. The student opens a PlanetScale deploy request (or its Neon / Supabase analog), writes a one-paragraph migration note, and waits for TA approval. The artifact you grade is the deploy request itself, not just the resulting schema. This models real-world engineering workflow and forces students to articulate their schema reasoning in writing.

Policy 5: written rollback plan on any destructive operation. For any assignment that drops a table, removes a column, or restructures data, students must include a written rollback plan as part of their submission. "If this migration fails halfway through, here is exactly how I would restore the previous state." This is the single highest-leverage habit you can install in a databases student, and it transfers to every other engineering discipline.

Policy 6: weekly cost review in lecture. For the first three weeks of any class on a paid PlanetScale instance, spend two minutes of lecture time pulling up the live PlanetScale billing dashboard and showing students what their collective branch-hours are costing in real money. Cost transparency is itself a pedagogical asset. By week four, students self-regulate without prompting, and the rest of the semester runs on autopilot.

Policy 7: explicit office-hours triage for connection-string issues. Connection-string problems are the most common failure mode in any cloud-database class, and they are almost always a 60-second fix that costs 45 minutes of TA time because the student has not been taught a diagnostic checklist. Publish a 5-step checklist in the syllabus: (1) is the secret named exactly PSCALE_CONNECTION_STRING, (2) is the branch active, (3) is the password reset, (4) does the connection string include the SSL parameter, (5) does pscale connect from the CLI also fail. Make the checklist a pre-condition for opening a TA ticket. Office-hours load drops by half.

These seven policies, taken together, separate the classes that finish the semester with a working curriculum from the classes that finish the semester with the instructor swearing off cloud databases forever. None of them are hard. All of them are written into the rare classes that actually scale.

FAQs

Is PlanetScale free for teachers or students in 2026?

No. PlanetScale removed the free Hobby tier in April 2024. There is no general-purpose free plan available to instructors or students in 2026. The cheapest paid tier is Scaler Pro at $39/month per database. PlanetScale's education team ([email protected]) does grant credits case-by-case for accredited curricula, and you should email them, but credits are not a guaranteed permanent foundation.

What is the best free database for teaching SQL in 2026?

For Postgres-flavored teaching: Neon Free is the strongest choice, especially if your curriculum uses branching as a pedagogical concept. For full-stack web courses with auth: Supabase Free. For SQLite-flavored or edge-database lessons: Turso. For NoSQL document-store lessons: MongoDB Atlas Free. PlanetScale is no longer the right default for free-tier classroom work.

Can I share one PlanetScale Scaler Pro instance across an entire class?

Yes. One Scaler Pro database at $39/month, with one schema-only branch per student, is the cheapest viable PlanetScale classroom architecture in 2026. Typical 14-week semester total: $60-130 depending on student count and active branch-hours. This is the right tier-2 setup if your curriculum specifically requires PlanetScale.

Does PlanetScale work with GitHub Classroom?

Yes, with manual or scripted connection-string injection. The manual path has each student paste their PlanetScale branch connection string as a GitHub Actions Repository Secret. The scripted path uses the pscale CLI and the GitHub API to provision both sides server-side. For classes above 20 students, the scripted path is worth the one-evening setup.

Should I teach MySQL or Postgres in 2026?

If you have flexibility, teach Postgres. The 2026 free-tier landscape strongly favors Postgres (Neon, Supabase, Aiven Free all run Postgres), the syntax overlap with MySQL is 90%+, and modern web frameworks default to Postgres. If your articulation agreements or textbook lock you to MySQL, MySQL is still entirely teachable; you will just have fewer free-tier providers to choose from.

My textbook uses PlanetScale. Should I rewrite my course?

Not necessarily. If your textbook references PlanetScale and your curriculum is wired into PlanetScale's free MySQL for Developers or Database Scaling courses as a curriculum spine, one shared Scaler Pro instance for $60-130 per semester preserves your continuity. Rewriting is a 40-hour project; one Scaler Pro is one departmental check.

What if PlanetScale removes more free resources in the future?

Hedge it. Even if you are running PlanetScale today, build your assignment infrastructure (GitHub Classroom templates, grading workflows, schema files) to be database-agnostic. Use environment variables for connection strings. Use Prisma or another ORM as a thin abstraction layer. If you need to swap providers between fall and spring terms, the swap should be one secret-rotation and one provider rename, not a curriculum rewrite. That is the lesson of 2024.

Where to go from here

If you read all the way to here and you teach databases for a living, you probably already have an opinion on which tier you are landing on. Cross-link reading from the Solomon Signal Launch School:

• PlanetScale for college students: the student-side counterpart to this page. Useful to assign as week-one reading.
• PlanetScale best practices: production patterns. Good capstone reading for senior electives.
• Learn PlanetScale free: generic primer. Useful as a pre-semester self-study handout.
• PlanetScale for entrepreneurs: cost vs growth lens. Useful for capstone-project teams thinking about life after graduation.

If you found this guide useful and you have specific classroom war stories, send them in. We update this page every term against the live PlanetScale pricing page and the live free-tier limits at Neon, Supabase, Turso, and Atlas. The 2026 honest answer is "do not default to PlanetScale", but the 2027 honest answer might be different, and we will rewrite the page when it is.

Teach hard, and pick the tier that fits the class you actually have.