Commodore 64 BASIC ahora corre dentro de PostgreSQL
Thom Brown, una cara conocida de la comunidad PostgreSQL, publicó a principios de julio de 2026 una extensión que suena a chiste de sobremesa pero funciona en serio: PL/CBMBASIC, que te deja escribir funciones almacenadas en el Commodore 64 BASIC original de 1982. No es un emulador liviano ni una recreación. Compila el ROM real en C y simula un encendido de la máquina en cada llamada, corriendo a 15 a 20 microsegundos por invocación.
PL/CBMBASIC es una extensión de lenguaje procedimental para PostgreSQL creada por Thom Brown (darkixion en GitHub) que permite escribir funciones en Commodore 64 BASIC v2. En lugar de emular la computadora entera, compila el intérprete del ROM de 1982 (el proyecto cbmbasic de Michael Steil) a código C nativo y lo ejecuta dentro del motor de la base de datos, igual que cualquier otro PL como PL/pgSQL o PL/Python.
En 30 segundos
- Qué es: una extensión que agrega Commodore 64 BASIC como lenguaje procedimental de PostgreSQL.
- Quién: Thom Brown, colaborador veterano de PostgreSQL, publicada en julio de 2026.
- Cómo: no emula, compila el ROM real de 1982 en C y “prende” la máquina en cada llamada.
- Velocidad: 15 a 20 microsegundos por llamada, unas 1000 veces más rápido que un C64 físico.
- Producción: es un juguete técnico brillante, no un reemplazo de PL/pgSQL.
¿Por qué alguien correría Commodore 64 BASIC dentro de PostgreSQL?
Ponele que estás mirando la lista de lenguajes que soporta PostgreSQL: PL/pgSQL, PL/Python, PL/Perl, PL/Tcl, hasta PL/v8 con JavaScript. La base de datos es extensible por diseño, y esa puerta abierta invita a cosas raras. PL/CBMBASIC es una de esas cosas raras (de las buenas).
La gracia está en el detalle técnico. Brown no reescribió BASIC ni lo aproximó. Tomó el intérprete de cbmbasic, que es el ROM del C64 portado a C, y lo enganchó al sistema de handlers de PostgreSQL. Cada vez que llamás una función, la extensión hace algo bastante teatral: simula un power cycle, ese momento en que la máquina arranca y te muestra el famoso READY. con 38911 bytes libres. Después inyecta tu código, lo corre y devuelve el resultado al motor SQL.
Es nostalgia tech pura, sí, pero también una demostración concreta de hasta dónde llega la arquitectura de plugins de PostgreSQL. Para más detalles técnicos, mirá plataformas de desarrollo modernas.
¿Quién es Thom Brown y por qué se le ocurrió esto?
Thom Brown no es un desconocido. Aparece en PostgreSQL Life como parte de la comunidad hace años, con trabajo real de testing, reportes de bugs y documentación sobre el proyecto. O sea: no es alguien que llegó de rebote a jugar con la base de datos, sino alguien que la conoce por dentro.
¿Y por qué BASIC del C64 y no otra cosa? Es la computadora con la que muchos de esa generación aprendieron a programar. Ese 10 PRINT "HOLA" seguido de 20 GOTO 10 fue la primera línea de código de un montón de gente que hoy administra clusters. Brown lo cuenta en su anuncio en el blog: la extensión es mitad homenaje, mitad experimento de “a ver si se puede”. Se pudo.
¿Cómo se escribe y ejecuta una función en PL/CBMBASIC?
La sintaxis usa el mismo CREATE FUNCTION de siempre, pero el cuerpo tiene que respetar las reglas del BASIC de 1982. Eso significa líneas numeradas, arrancando desde 10 o el número que quieras, y en orden.
Lo más ingenioso es el mapeo de parámetros. Un argumento de tipo text entra al programa como una variable string tipo WHO$, y un integer como una variable entera tipo LIVES%, respetando las convenciones de nombres del propio BASIC (el $ para strings, el % para enteros). Escribís tu 10 PRINT "HOLA "; WHO$ y la función te devuelve el texto armado.
Acá viene lo bueno: para leer datos de la base, la extensión reutiliza el concepto de Device 8, que en el C64 real era la disquetera 1541. Con un OPEN 1,8,0 seguido de los comandos de lectura, tu programa BASIC puede pedirle filas a PostgreSQL como si estuviera cargando un archivo del diskette. Es un puente conceptual precioso: el mismo verbo que usabas para cargar un juego ahora consulta una tabla. Más contexto en riesgos de seguridad en repositorios.
¿Cuánto más rápido es que un Commodore 64 de verdad?
El número mata: 15 a 20 microsegundos por llamada. En la práctica, eso son millones de sentencias BASIC por segundo, algo así como 1000 veces más rápido que el hardware original de 1982, que corría a poco menos de 1 MHz.
Eso sí: rápido comparado con un C64 no es lo mismo que rápido para producción. Contra PL/Python, PL/CBMBASIC es entre 6 y 19 veces más lento, según el tipo de operación. Tiene sentido, porque cada invocación paga el costo de simular el arranque completo de la máquina antes de correr una sola línea. Para un chiste de portafolio es despreciable. Para un trigger que dispara diez mil veces por minuto, no.
¿Qué no podés hacer con PL/CBMBASIC?
La lista de limitaciones es larga y viene heredada del BASIC de 1982 tal cual era. No hay atajos. Ya lo cubrimos antes en automatización en pipelines CI/CD.
- Todo en mayúsculas: el texto sale siempre en uppercase, porque así trabajaba el modo por defecto del C64.
- Strings de 255 caracteres: ese es el techo duro de una cadena en BASIC v2.
- Floats de 9 dígitos: la precisión numérica es la de 1982, nada de doubles modernos.
- Sin NULL: el concepto de valor nulo de SQL no existe en este mundo, lo cual complica mucho la vida real.
- INPUT no anda: no hay teclado interactivo dentro de una función de base de datos, obvio.
- POKE y SYS limitados: escribir en memoria o saltar a código máquina está muy recortado.
- Solo superusers: por seguridad, la extensión no se la dan a cualquier rol.
- Sin estado entre llamadas: como cada invocación simula un encendido nuevo, no guardás nada de una llamada a la otra.
PL/CBMBASIC frente a PL/pgSQL, PL/Python y compañía
Para ubicarlo en el mapa, conviene comparar dónde juega cada lenguaje procedimental. La respuesta corta: para aplicaciones serias seguís con PL/pgSQL o PL/Python. PL/CBMBASIC es otra categoría.
| Lenguaje | Rendimiento | Estado entre llamadas | Uso recomendado |
|---|---|---|---|
| PL/pgSQL | Alto, integrado al motor | Sí | Lógica de negocio, triggers, producción |
| PL/Python | Alto, ideal para lógica compleja | Sí | Cálculos, integraciones, ciencia de datos |
| PL/Perl | Bueno para texto | Sí | Manipulación de strings y regex |
| PL/CBMBASIC | 6 a 19x más lento que PL/Python | No | Nostalgia, demos, aprender extensibilidad |
Si estás corriendo tu PostgreSQL sobre un hosting o un VPS y necesitás lógica confiable en la base, quedate con PL/pgSQL. Y si querés que ese motor viva en infraestructura pensada para la región, donweb.com tiene planes de hosting y servidores en Argentina. PL/CBMBASIC, mientras tanto, dejalo para el ambiente de pruebas donde puede lucirse sin romper nada.
Errores comunes al probar PL/CBMBASIC
- Olvidarte de numerar las líneas: el cuerpo tiene que arrancar con línea 10 (o el número que elijas) y seguir en orden. Sin numeración, no corre.
- Esperar minúsculas en la salida: el texto sale en mayúsculas por diseño del C64. Si tu app depende del case, vas a tener que convertir del lado de SQL.
- Contar con NULL: no existe. Si una columna puede venir vacía, resolvé el caso antes de pasar el valor a la función, o vas a tener sorpresas.
- Querer guardar estado entre llamadas: cada invocación es un encendido nuevo. Las variables no sobreviven de una función a la siguiente, así que no armes contadores globales adentro.
Preguntas Frecuentes
¿Qué es PL/CBMBASIC?
Es una extensión de PostgreSQL creada por Thom Brown que agrega Commodore 64 BASIC v2 como lenguaje procedimental. Compila el intérprete del ROM original de 1982 en C y lo ejecuta dentro del motor, permitiendo escribir funciones almacenadas en BASIC.
¿Quién es Thom Brown?
Thom Brown es un colaborador veterano de la comunidad PostgreSQL, conocido en GitHub como darkixion. Tiene años de trabajo en testing, reportes y documentación del proyecto, y publicó PL/CBMBASIC en julio de 2026. En herramientas de automatización modernas profundizamos sobre esto.
¿Sirve para producción?
No. Corre entre 6 y 19 veces más lento que PL/Python, no soporta NULL, no guarda estado entre llamadas y limita strings a 255 caracteres. Para aplicaciones reales conviene PL/pgSQL o PL/Python. PL/CBMBASIC es un experimento y una demostración de la extensibilidad de PostgreSQL.
¿Cuánto más rápido es que un Commodore 64 real?
Alrededor de 1000 veces más rápido. Cada llamada tarda 15 a 20 microsegundos y llega a millones de sentencias BASIC por segundo, frente al procesador de menos de 1 MHz del hardware original de 1982.
¿Dónde encuentro el código de PL/CBMBASIC?
El repositorio está en GitHub, en github.com/darkixion/pl-cbmbasic. Depende del proyecto cbmbasic de Michael Steil, disponible en github.com/mist64/cbmbasic, que aporta el intérprete del ROM.
Conclusión
PL/CBMBASIC no va a aparecer en tu stack de producción, y Thom Brown es el primero en decirlo. Su valor es otro. Muestra, con un ejemplo que da ganas de probar, hasta dónde llega la arquitectura extensible de PostgreSQL: si podés meter el ROM de una computadora de 1982 como lenguaje procedimental, casi cualquier cosa entra. Si sos de los que aprendieron con el READY. parpadeando, cloná el repo, escribí tu 10 PRINT y disfrutá el guiño. Para lo demás, PL/pgSQL sigue esperándote.
