Multi-user concurrent transaction support will be required if you have multiple designers who are not actively deciding who will work on the data at such-and-such a time. Without this, data can be corrupted. Implementing such an advanced feature yourself, would consist of far more effort than it would be worth, when you are only trying to write a game. Large / proprietary DBs do support this transaction model, but you'd still be stuck with designers using a raw DBMS to do their work. On the other hand, Git is very good at synchronising the work of multiple users commiting at any time they like, if your designers are willing to work in pure text files. This provides a simple solution and your designers will quickly enough learn to work with CSV. Besides, you will not have to pay for expensive services or worry about (any single revision of) your data ever being lost. **CSV (text)**, import CSV into Excel / Calc, then export to CSV before they commit/push to the git repository. This will also tie in easily with your development pipeline, since devs these days use Git for source control of code. Indeed - you could be using the very same source repository for _everyone_ - major win. **JSON (text)** is another solution if your data is inherently more hierarchical in nature, as opposed to flat. This eliminates the traditional DB concept of joins, allowing for an easier-to-follow setup if designers are willing to use JSON editors, instead (there are some nice ones out there). This also is text, and so can also be pushed to Git and kept safe at every single revision.