How I Built a Live SQL Workshop Where Students Can't Break Anything

Mohamed Hedi Ben Jemaa — Sun, 24 May 2026 21:43:23 +0000

Picture this. It's a Tuesday evening. Half the students are in the room. The other half are little rectangles on a Zoom call, cameras off, maybe paying attention. You're 40 minutes into a live SQL workshop, things are actually going well, and then one student, trying to be helpful, runs this:

DELETE FROM students;

No WHERE clause. No hesitation. Just confidence and destruction.

The table is empty. Every row, the sample data you spent 20 minutes explaining, gone. The remote students have no idea what happened. The in-room students are staring at you. And now you're digging through a folder of SQL dump files, trying to remember which one is the "clean" version, wondering why you didn't just become a frontend developer.

That scenario? I've lived it. More than once.

After years of teaching full stack development in hybrid environments, I can tell you: the hardest part of running live database workshops isn't the SQL. It's keeping the environment alive long enough to finish the lesson.

What Every Platform Gets Wrong

Platforms like Udemy, Scrimba, and Pluralsight have genuinely transformed how developers learn. The production quality, the pacing, the interactive sandboxes, it's remarkable. But they all solve the same problem: recorded, self-paced learning.

Live workshops are a completely different beast.

Scrimba gives each student an isolated coding environment. Great for JavaScript. Useless when you need 12 students sharing a single evolving database state, building on each other's schema, watching the same rows appear in real time, following along as the instructor adds a foreign key to a table they all created together.

Pluralsight has hands-on labs. But resetting between groups? That's still your problem. It still means Docker dumps, seed scripts, manual imports. The ritual goes like this: end one session, restore the database, pray nothing is broken, start the next session, repeat. If something breaks mid-lesson, and it always breaks mid-lesson, you either scramble to recover live or you apologize and move on with a broken example.

That apology is what I got tired of making.

The Git Mental Model, Applied to Databases

Here's the thing about teaching developers: they already understand Git. They commit code. They branch. They check out previous states. It's muscle memory.

GFS, Git for database Systems, borrows exactly that model and applies it to PostgreSQL and MySQL. The command syntax is intentionally familiar:

gfs commit -m "lesson-1"       # save this exact database state
gfs log                        # see the full history
gfs checkout <hash>            # restore to any point instantly
gfs checkout -b student-alice  # give a student their own isolated branch

Under the hood, GFS runs your database in a Docker container and wraps every state change in a commit structure. Each commit is a snapshot, not a backup you restore from, but a save point you jump to. The difference matters more than it sounds. Backups are for disasters. Save points are for teaching.

Install it in one line:

curl -fsSL https://gfs.guepard.run/install | bash

Then initialize a database:

mkdir sql-workshop && cd sql-workshop
gfs init --database-provider postgres --database-version 17
gfs commit -m "initial-empty-state"

Your workshop database is live, versioned, and ready.

The Three-Lesson Checkpoint Structure

The workshop I built covers three progressive SQL lessons. Each one ends with a GFS commit, a named checkpoint the instructor can return to from anywhere, at any time.

Lesson	Core Concept	GFS Checkpoint
1	CREATE TABLE, INSERT, SELECT	`lesson-1`
2	Foreign keys, related tables	`lesson-2`
3	ALTER TABLE, JOIN queries	`lesson-3`

Lesson 1 creates the foundation:

gfs query "CREATE TABLE students (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  age INT
);"

gfs query "INSERT INTO students (name, age) VALUES
  ('Alice', 22), ('Bob', 25), ('Carol', 21);"

gfs commit -m "lesson-1"

Lesson 2 introduces relationships:

gfs query "CREATE TABLE grades (
  id SERIAL PRIMARY KEY,
  student_id INT REFERENCES students(id),
  subject TEXT NOT NULL,
  score INT
);"

gfs commit -m "lesson-2"

Lesson 3 adds complexity, ALTER TABLE and a real JOIN:

gfs query "ALTER TABLE students ADD COLUMN email TEXT;"

gfs query "SELECT students.name, grades.subject, grades.score
FROM students
JOIN grades ON students.id = grades.student_id
ORDER BY students.name;"

gfs commit -m "lesson-3"

After all three lessons, gfs log shows the full history:

lesson-3   →  ALTER TABLE + JOIN demo
lesson-2   →  grades table with FK
lesson-1   →  students table + seed data
initial    →  empty database

Four commits. Four checkpoints. Any of them is one command away.

Every Student Gets Their Own Branch

This is where the teaching dynamic fundamentally shifts. Before GFS, student experimentation was a liability. Letting someone freestyle on a shared database meant risking the entire session. So most instructors, myself included, discouraged it. "Don't try that yet. Wait until you're on your own machine." It killed curiosity right when curiosity was highest.

With GFS, every student gets a branch:

gfs checkout lesson-2          # start from this checkpoint
gfs checkout -b student-alice  # Alice gets her own copy

Alice can now run anything. Drop tables. Insert garbage. Break every foreign key constraint she can find. Her branch absorbs all of it. And when she's done experimenting:

gfs checkout main
gfs query "SELECT * FROM students;"

Alice, Bob, Carol. Exactly as left. Main branch untouched.

For hybrid sessions specifically, this changes the remote dynamic in a real way. Students joining via Zoom tend to participate less, partly because they feel more like observers than participants. Giving them their own branch makes the experimentation feel real and safe at the same time. It signals: your curiosity won't cost anyone else their session.

The Demo That Earns the Room

Here's the moment I now run at the start of every workshop. It's a deliberate act of sabotage.

With the full lesson history in place, I simulate what happens when something goes wrong:

gfs query "DROP TABLE grades;"

Then:

gfs query "SELECT * FROM grades;"
# ERROR: relation "grades" does not exist

The table is gone. I let that sit for a second. Then:

gfs checkout HEAD~1
gfs query "SELECT * FROM grades;"

 id | student_id | subject | score
----+------------+---------+-------
  1 |          1 | Math    |    88
  2 |          1 | English |    92
  3 |          2 | Math    |    75
...

Every row. Back. Three seconds.

Without GFS, that recovery takes 5 to 10 minutes, find the dump file, stop the container, restore, verify, explain to remote students what just happened, lose the thread of the lesson entirely. With GFS, it's one command and a breath. The lesson continues like nothing broke.

The room's reaction to that demo is always the same. Something clicks. Not just about GFS, about what version control actually means when it's applied to data, not just code.

What Changes When You Teach This Way

Something subtle shifts when you know you have an undo button.

As an instructor, the low-grade anxiety that lives in every live demo, what if something breaks, what if a student touches the wrong table, what if the seed script doesn't run cleanly this time, it quietly disappears. You stop designing lessons around what students can't be allowed to touch. You start designing around what they should try.

Students feel that. They experiment more. They ask "what happens if I do this?" instead of waiting to be told. In a hybrid room, the remote students stop lurking and start running queries on their branches. The energy is different when nobody's afraid of breaking something that can't be fixed.

That shift, from a fragile shared environment that everyone tiptoes around, to a versioned system where every mistake is recoverable, that's the real value of GFS in a teaching context. Not the commands. The psychological safety those commands create.

The full workshop, including lesson SQL files, a student worksheet, and complete replay instructions, lives on GitHub: https://github.com/LHedi22/sql-workshopt-gfs

Set it up. Build the checkpoints. Then run the DROP TABLE demo in front of your next group and watch gfs checkout HEAD~1 do its thing.

Some tools you adopt because they're useful. This one you'll keep because it changes how you teach.

GFS is open source and actively developed. Find it at github.com/Guepard-Corp/gfs. Join the community on Discord.