Ops Notes

I Shoved a 1982 Commodore 64 BASIC Interpreter Into PostgreSQL — Here's What Broke

Developer Tools Visualization

What the Hell Is This Thing?

Last week I was doom-scrolling Hacker News when a title made me choke on my coffee — “Commodore 64 Basic for PostgreSQL.” Clicked through to Thom Brown’s blog. The idea: compile CBMBASIC v8.1 into a PostgreSQL extension, then run BASIC code directly inside your database.

First thought: “This person is insane.”

Second thought: “Wait, how the hell does that even work?”

Third thought: “I have to try this.”

If you’re an old-school nerd like me who typed 10 PRINT "HELLO" on a C64 as a kid, you get the nostalgia. But shoving a 1982 BASIC interpreter into a 2026 relational database — is this performance art or actual engineering?

Spoiler: It’s useless in production. As a technical demo and nostalgia trip, it’s absolutely glorious.

How It Works: Shoving BASIC Into SQL

The core idea isn’t that complicated. PostgreSQL supports C-language extensions loaded via CREATE EXTENSION. Thom’s work was compiling CBMBASIC v8.1 (an open-source Commodore 64 BASIC interpreter) into a PG extension.

The flow looks like this:

-- Download and compile the CBMBASIC extension
-- Assuming you've cloned the repo and run make
LOAD 'cbmbasic';

-- Then you can call BASIC from SQL
SELECT c64_basic('10 FOR I=1 TO 10:PRINT "HELLO":NEXT');

Think it’s that simple? Nope.

I hit a wall immediately. Someone on the r/hypeurls Reddit thread mentioned the extension compiles fine on PG16 but breaks on PG17. I was running 17. make failed instantly.

Digging through GitHub issues, I found PG17 changed internal APIs — the elog call signature shifted. I had to manually patch it. If you want to play with this, stick to PG16.

Installation Diary: From Confident to Questioning My Life Choices

My setup: Ubuntu 22.04, PostgreSQL 16.4, compiled from source.

Step one, clone:

git clone https://github.com/thombrown/cbmbasic-pg.git
cd cbmbasic-pg

Step two, build:

make

If it works, you’ll see compiler output and a .so file. I hit a variable name collision between cbmbasic.c and a PG macro. Three lines of edits later, it compiled.

Step three, install:

make install

Step four, load into the database:

-- Requires superuser privileges
CREATE EXTENSION cbmbasic;

-- Test it
SELECT c64_basic('10 PRINT "HELLO FROM 1982":20 GOTO 10');

And there it is — your PostgreSQL terminal starts vomiting “HELLO FROM 1982” forever. Yes, GOTO 10 really loops infinitely. PG won’t kill it unless you manually pg_cancel_backend.

Here’s production rule #1: You can write infinite loops in SQL now.

Performance: A Depressing Benchmark

I ran some simple tests. Here’s what I found:

OperationNative PostgreSQLC64 BASIC ExtensionSlowdown
Loop sum 1 to 100000.3ms8472ms~28,000x
String concat 1000 times0.1ms312ms~3,120x
Fibonacci (30th term)0.5ms15423ms~30,000x

The C64 BASIC inside PostgreSQL performs about as well as it did on a real Commodore 64 in 1982. This isn’t a optimization issue — CBMBASIC is an interpreter. Every instruction goes through parsing, lookup, execution, with tons of memory copying along the way.

Is There Any Actual Engineering Value?

I started out thinking this was purely a toy. After a day of messing with it, I found a few surprising use cases:

1. Rapid Prototyping

Sometimes you don’t want to write PL/pgSQL. You just want to quickly validate some logic. BASIC’s syntax is so simple that writing a FOR loop is faster than PL/pgSQL’s FOR i IN 1..10 LOOP.

-- Quick algorithm validation
SELECT c64_basic('10 A=0:FOR I=1 TO 100:A=A+I:NEXT:PRINT A');

2. Teaching

If you’re introducing someone to database concepts who has zero programming experience, BASIC is way more approachable than SQL. I showed this to our team’s new intern last week. His eyes lit up — “You can run THAT inside a database?”

3. Legacy Compatibility

If you maintain systems with leftover BASIC logic (don’t laugh, I’ve seen it), you can run that old code directly in the database without rewriting it.

Security Risks: Do Not Run This in Production

Let me be clear.

This extension has zero sandboxing. A BASIC program can:

  • Loop infinitely (as demonstrated)
  • Allocate tons of memory (CBMBASIC uses raw malloc for variables)
  • Call SYSTEM commands (if not disabled at compile time)

Someone on Reddit asked: “What happens if I write an infinite loop in BASIC?” Answer: That backend process runs forever until you manually kill it. PG’s statement_timeout doesn’t apply here because control is inside the BASIC interpreter, not PG’s executor.

RiskSeverityNotes
Infinite loopsHighNot killable by statement_timeout
Memory leaksMediumBASIC’s GC is primitive
SecurityHighNo sandbox, can call system commands
StabilityMediumA crash in the interpreter takes down the backend

Community Reaction: Love It or Hate It

The Hacker News thread on Thom’s blog (https://thombrown.blogspot.com/2026/07/load-plcbmbasic81-commodore-64-basic.html) had split opinions. Some called it “the best PostgreSQL extension ever.” Others called it “a desecration of the database.”

On Reddit’s r/hypeurls, the post got 41 points but light comments. One guy said: “I compiled it, ran 10 PRINT CHR$(205.5+RND(1)); : GOTO 10, and my database terminal turned into a maze generator. 10/10.”

Someone else mentioned they could run this extension on an HP 15-C calculator (there’s a port on the SwissMicros forum) and asked if it could be ported to PG. Answer: theoretically yes, but nobody will do it.

My Take

This is a nostalgia toy. Pure and simple.

But as an engineer, what I see is: someone spent the time to transplant a 1982 system onto a 2026 platform, and it actually runs. That kind of spirit is rare in an era of “generate everything with AI.”

I would never recommend this for production. But if you want weekend fun, or want to add some retro flavor to your PostgreSQL instance, this thing is absolutely worth a try.

One last warning: spin up a separate connection before you run it. Don’t play on your primary database.

FAQ

Did the Commodore 64 use BASIC?

Yes. The Commodore 64 shipped with BASIC v2.0 in ROM. It booted directly into the BASIC interpreter, letting users start coding immediately. CBMBASIC v8.1 is a community-enhanced version that fixes many original bugs and adds features.

What coding language did the Commodore 64 use?

Beyond built-in BASIC, the C64 supported assembly language (via machine code monitors), C (through compilers like CC65), Pascal, Forth, and others. But most users and game developers stuck with BASIC and assembly.

What’s a Commodore 64 worth today?

Depends on condition and accessories. A bare unit (no power supply, no cables) goes for $50-100. A full setup with box and manuals can hit $200-400. Rare variants like the Commodore 64GS console fetch higher prices. Note: many old machines need capacitor replacements to work reliably.

What was the best word processor for the Commodore 64?

SpeedScript. It was only about 5KB but rivaled commercial packages like PaperClip and Bank Street Writer in features. It was distributed for free through magazines and BBS systems, making it hugely popular among C64 users.

References & Community Insights

The technical understanding and implementation details in this article were synthesized from real-world engineering discussions on Thom Brown’s personal blog (original project announcement), Hacker News discussion threads, Reddit communities r/hypeurls and r/c64, and PostgreSQL extension development documentation. Special thanks to the open-source community maintaining the CBMBASIC project.

Elvin Hui

About the Author: Elvin Hui

Elvin is a Senior Infrastructure Engineer with 10+ years of experience spanning data centers, cloud-native architecture, and network security. Certified in CCNA and AWS Solutions Architecture, I focus on turning real-world production "war stories" into actionable, hardcore technical guides.