There's a category of software project that exists at the intersection of "technically impressive" and "completely unjustifiable," and pg_6502 lands squarely in it. Someone implemented the MOS Technology 6502 - the 8-bit processor that powered the Apple II, the Atari 8-bit line, the Commodore 64, and the original NES - entirely in PostgreSQL.
This is a toy, but a "working toy" - an emulator that apparently passes the Klaus 6502 Functional Test suite.
The architecture is straightforward in the way that only deeply strange things can be. CPU state lives in a single-row table: registers A, X, Y, the stack pointer, the program counter, status flags, all of it. The full 64KB address space is a table with one row per byte. Every 6502 opcode - all 151 of them - is a stored procedure. Instruction execution is a database operation. The fetch-decode-execute cycle runs in PL/pgSQL.
It's worth being precise here: this isn't SQL in the declarative sense. PL/pgSQL is emphatically imperative - it has loops, conditionals, variables, and procedural flow. What makes this interesting isn't that SQL is Turing complete in some abstract theoretical sense; it's that PostgreSQL's procedural extension is expressive enough, and its type system rich enough, that someone could model a complete CPU state machine in it cleanly enough to test.
Which raises the obvious question: could you load a ROM?
The 6502's memory model is simple. The address space is flat, 64KB, and pg_6502 already models it as exactly that - 65,536 rows, one byte each. An Apple II ROM, a Commodore 64 BASIC interpreter, an Atari cartridge image - these are just byte sequences that need to land at the right addresses. The memory table is already there. The COPY command exists. Someone is going to do this, if they haven't already; if you can model the 6502 cleanly enough, you could model the other chips that contributed to those machines.
And if you model the other aspects of those machines, well, someone will find a way to port DOOM into PostgreSQL emulating a 6502... if it hasn't happened already. This is tradition. It is known.
The "why can't other databases do this" question might be genuinely interesting. Most enterprise databases with serious procedural extensions - Oracle's PL/SQL, SQL Server's T-SQL - are probably capable of something similar. Oracle's PL/SQL is actually the ancestor PL/pgSQL was modeled on, so the theoretical distance isn't far. MySQL's stored procedures are more limited but not obviously incapable. SQLite, without native stored procedures, would require a different approach entirely. Maybe "can run the 6502" becomes the new validation suite for stored procedure languages.
What PostgreSQL has is a culture that encourages this kind of thing, a type system that cooperates, and a community that will write a Klaus test harness for their database CPU emulator rather than just claiming it works. That last part is not nothing. (Worth noting: BCN runs on PostgreSQL.)
Should you use pg_6502 for anything like this? Performance would be orders of magnitude slower than any conventional emulator, and several orders of magnitude slower than hardware. There is no production use case. There is no reasonable justification other than nostalgia, but even nostalgia is real: there's an active set of communities for old hardware. I wouldn't complain in the slightest if a Commodore 64 Ultimate showed up on my doorstep, for example.
But regardless (or "irregardless," if you like) of rational justification, it works. It passes its tests. And it's a cleaner illustration of CPU architecture - state, addressable memory, opcode dispatch - than probably half the tutorial content written for the purpose.
Sometimes the point isn't that you should - sometimes the point is that you can.