# From Scripts to RelSpec: What Years of Database Pain Taught Me It started as a need. A problem I’ve carried with me since my early PHP days. Every project meant doing the same work again. Same patterns, same fixes—just in a different codebase. It became frustrating fast. I wanted something solid. Not another workaround. ## The Early Tools Phase Like most things in development, it began small. A simple PHP script. Then a few Python scripts. Just tools—nothing fancy. The goal was straightforward: generate code faster and remove repetitive work. I even experimented with Clarion templates at one point, trying to bend existing systems into something useful. Then came SQL scripts. Then PostgreSQL migration stored procedures. Then small Go programs using templates. Each step was solving a problem I had at the time. Nothing unified. Nothing polished. Just survival tools. --- ## Argitek: The First Real Attempt Eventually, those scattered ideas turned into something more structured: Argitek. Argitek powered a few real systems, including Powerbid. On paper, it sounded solid: > “Argitek Next is a powerful code generation tool designed to streamline your development workflow.” And technically, it worked. It could generate code from predefined templates, adapt to different scenarios, and reduce repetitive work. But something was off. It never felt *complete*. Not something I could confidently release. So I did what many developers do with almost-good-enough tools—I parked it. --- ## The Breaking Point: Database Migrations Over the years, one problem kept coming back: Database migrations. Not the clean, theoretical kind. The real ones. * PostgreSQL to ORM mismatches * DBML to SQL hacks * GORM inconsistencies * Manual fixes after “automated” migrations failed It was always messy. Always unpredictable. Always more work than expected. By 2025, after a particularly tough year, I had accumulated enough of these problems to stop ignoring them. --- ## December 2025: RelSpecGo Begins In December 2025, I bootstrapped something new: **RelSpecGo** It started simple: * Initial LICENSE * Basic configuration * A direction By late December: * SQL writer implemented * Diff command added January 2026: * Documentation February 2026: * Schema editor UI (focused on relationships) * MSSQL DDL writer * Template support with `--from-list` --- ## April 2026: A Real Tool Emerges By April 2026, it became something I could finally stand behind. RelSpecGo reached version **1.0.44**, with: * Packaging for AUR, Debian, and RPM * Updated documentation and README * A full toolchain for: * Convert * Merge * Inspect * Diff * Template * Edit Support includes: * bun * dbml * drizzle * gorm * prisma * mssql * pgsql * sqlite Plus: * TUI editor * Template engine * Bidirectional schema handling 👉 RelSpecGo: [https://git.warky.dev/wdevs/relspecgo](https://git.warky.dev/wdevs/relspecgo) This wasn’t just another generator anymore. It became a system for managing *database truth*. --- ## Lessons Learned (The Hard Way) This journey wasn’t about tools. It was about understanding databases properly. Here are the principles that stuck: ### 1. Data Loss Is Not Acceptable Changing table structures should **never** result in lost data. If it does, the process is broken. ### 2. Minimal Beats Clever The simpler the system, the easier it is to trust—and to fix. ### 3. Respect the Database If you fight database rules, you will lose. Stay aligned with them. ### 4. Indexes and Keys Matter More Than You Think Performance and correctness both depend on them. Ignore them at your own risk. ### 5. Version-Control Your Backend Logic SQL scripts, functions, migrations—these must live in version control. No exceptions. ### 6. It’s Not Migration—It’s Adaptation You’re not just moving data. You’re fixing inconsistencies and aligning systems. ### 7. Migrations Never Go as Planned Always assume something will break. Plan for it. ### 8. One Source of Truth Is Non-Negotiable Your database schema must have a single, authoritative definition. ### 9. ORM Mapping Is a First-Class Concern Your application models must reflect the database correctly. Drift causes bugs. ### 10. Audit Trails Are Critical If you can’t track changes, you can’t trust your system. ### 11. Manage Database Functions Properly They are part of your system—not an afterthought. ### 12. If It’s Hard to Understand, It’s Too Complex Clarity is a feature. Complexity is technical debt. ### 13. GUIDs Have Their Place Especially when moving data across systems. They solve real problems. ### 14. But Simplicity Still Wins Numbered primary keys are predictable, efficient, and easy to reason about. ### 15. JSON Is Power—Use It Carefully It adds flexibility, but too much turns structure into chaos. --- ## Closing Thoughts Looking back, this wasn’t about building a tool. It was about: * Reducing friction * Making systems predictable * Respecting the database as the core of the system RelSpecGo is just the current result of that journey. Not the end. Just the first version that feels *right*.