It's kind of unheard of to do this for things like game dev (preferring custom solutions), but it works and makes things way easier to manage. The shape of the data in a database affects how well it works for a use case, and that model scales well for virtually every kind of software ever, the same should apply here!
Feel free to prototype some game ideas you might have been tossing around, our priority is DX for the project as a whole to enable more developers with less resources to build bigger worlds, so please do share feedback here and/or in GH issues!
Our roadmap is for more SDKs, and cutting down on bloat where possible, with the express goal of giving devs more cycles in the day to focus on the actual gameplay instead of tooling.
Postgres is not slow by any stretch of the imagination, but it depends on how the schema is setup and what layers you have between the user and the DB, naturally any game developer will want to tweak the client+schema before going live. The layers between we manage to make it as minimal as possible, so that shouldn't be touched, if it's too slow for a reasonable use case, it means we have more optimization to do!
This is because gamers require low latency to effectively play, but things can be slightly out of sync and logic can be complex, and anti cheat can be hard to implement server side only (which is why eg fortnite and valarant install fancy client side anti cheat software too).
For a friendly game of stardew valley or turn based strategy you can afford to wait for transactions to complete and causality to be enforced.
Our old system, being very monolithic, while extremely performant and capable, was nearly impossible to adapt and change. So what we have now is much more dynamic but also still a work in progress, a more complete example will be published in the coming weeks.
