Theme 1 – SQL as a surprisingly expressive language for complex logic
Many commenters marveled at how much functionality can be squeezed into SQL, noting that the game’s logic fits in fewer lines than the original C implementation.
- “The game logic is just ~5900 lines of SQL. While this sounds a lot, it’s definitely less than the original C source code which does the same in about 9000 lines!” — paul‑vernon
- “Yes, this is fantastic! I'm trying it right now…. This works way better than I would have expected, since, well, it's sql all the way down.” — Alive‑in‑2025
Theme 2 – Trade‑offs, concurrency pitfalls, and the “malpractice” debate
While the approach is clever, several users warned about atomicity, deadlocks, and scaling nightmares when using SQL tables as mutable game state.
- “Less lines of code than vanilla C while abusing query planning as a state machine is peak engineering malpractice. I love it.” — soltanov
- “With multiple players you can imagine that there would sometimes be issues. Some of the deadlock problems early on were horrific; scaling was a nightmare. But everything was atomic.” — noduerme
Theme 3 – Real‑world applicability and operational observations
Beyond the novelty, participants pointed out practical benefits: multi‑region servers, ease of testing via DB replication, and the use of stored procedures for business‑logic‑heavy domains.
- “I want to point out that they set up an EU and US multiplayer server! Nice touch.” — ralfd
- “When I was working in semiconductor manufacturing, we relied very heavily on stored procedures and SQL to operate the factory… Testing this stuff was trivial because we replicated the prod DB every morning…” — bob1029