About SSB Stats
How this all came to be — and how it works under the hood
The Origin
This all started as data in a school notebook. My brother and I playing Super Smash Bros. Brawl on Wii regularly, and one day we decided to create a WWE style season on the game — who fought who, what stage, what the result was, championships on the line, PPV events, the works. Seasons, months, weeks. It became a whole thing.
As we got older, we changed off the notebooks and utilized an Excel spreadsheet. Once I graduated college and learned more about SQL, I saw the potential to build something more robust and shareable — a MySQL database with all the notebook and excel data unioned together, where would run analytical queries to our heart's content. That was the spark: build something that does it automatically for a unique resume project, and makes the data personally fun to explore with my brother.
The first version of this site was a desktop app built with Python and PyQt5 — a dark-themed GUI with a Head-to-Head tab that ran queries against a database and displayed results in a table. It worked, but it was clunky to share. A web app was the obvious next step. SSB Stats is that web app. A place where we could easily look up fighter stats, head-to-head records, championship histories, and all the other fun insights that come from a rich dataset like this — without having to write SQL queries ourselves every time.
The Data
Every fight is recorded manually in a phsycial notebook or parsed out using a parser on my GitHub page — this includes fighter names, result, stocks remaining, stage, fight type (1v1, Tag Team, Handicap, etc.), championship stakes, brand, PPV event, and more. Records are loaded into a MySQL database hosted on Amazon RDS, organized across several normalized tables.
On top of the base tables, a set of MySQL views pre-compute the aggregations the app queries most often — career stats per fighter, head-to-head records, championship history by season, win/loss streaks, and a holistic season-level summary view. These views keep the application queries simple and fast.
How It Works
Backend
The backend is a Python Flask application. It handles two types of requests: server-rendered HTML pages (fighter profiles, leaderboard, seasons) and JSON API endpoints consumed by the frontend for dynamic data — fight logs, head-to-head stats, autocomplete.
Head-to-Head queries run in parallel using ThreadPoolExecutor, firing multiple database queries simultaneously to pull stats across different dimensions (by location, by fight type, by season, by championship, etc.) without waiting for each one sequentially.
Database
The database lives on Amazon RDS running MySQL. Connection pooling is handled via PyMySQL, with credentials stored in environment variables — never in code. The schema uses foreign keys for referential integrity and indexed columns on the fields most commonly used in filters (Fighter_Name, Season, Decision).
Deployment
The app runs on AWS Elastic Beanstalk with a Gunicorn WSGI server in front of Flask. Elastic Beanstalk handles provisioning, load balancing, and health monitoring. Deployments are one command via the EB CLI, triggered from a Git-tracked codebase. Static assets (fighter portraits, stage images) are served directly by the app instance.