This, basically, uses a table to store 64 kilobytes of memory, a single-row table for storing register values, and uses regular procedural programming to run the CPU (https://github.com/lasect/pg_6502/blob/main/init/05_execute....)

I give that an A+ for perseverance, but I would have hoped to see something that uses the strengths of SQL more.

For example, there could be a table with the decode ROM (https://www.cpcwiki.eu/index.php/MOS_6502#The_Decode_ROM_.28...) that could be used to drive the logic.

Have a main loop that uses the inputs of that ROM to look up the output bits and update a table, and add triggers that handle each “micro-op”. A SQL engine could run those triggers in parallel until they hit a race condition, but those can be avoided a bit by having separate tables for each register.

Even better would be if there were tables with every logic gate and wire in the original CPU, using a trigger to move the signals around. That would be a good test of the trigger handling in a SQL engine.