The only cost would be storage, if you're going to use SQL. But then again cheap enough.
I'd suggest porting to key/value pair DBs like mongo or firestore.
> I'd suggest porting to key/value pair DBs like mongo or firestore.
Why? The data set feels pretty "relational" to me (contests have divisions, divisions have scorings and results, results have players, players have sponsors) and seems to fit SQL. To be fair though, I've not used Mongo or Firestore or a NoSQL db in general before.
The "scorings" part is the only thing that tripped me up designing a schema since it varies between divisions in a contest as well as between contests themselves, so I ended up w/ a JSONB column for scoring rubric for divisions and then in the results table there's both final_score and scoring_breakdown columns, the beakdown being another JSONB column w/ the individual category results.