DataStore2 does this.
Just gotta watch out for table changes. If you are saving tables, then that means that the values inside the table are changing, and not the actual table itself, thus could be marked as ‘clean’ still and not get saved. I ran into this issue with my DataStore system.
Call it a hack, but DataStore2 always deep copies tables before setting/getting to stop this exact oversight.
This forces you to call :Set if you change the table.
Periodical autosaving isnt required and it only prevents data loss when the datastores crash. Traditional bind to leave and bind to close saving should work almost all the time as long as connection maintained.
2022 Edit: It’s impossible to completely prevent all data loss. Fortunately, the reliability and resiliency of the Roblox Datastore backend has improved considerably since that post was originally made. Along with saving when a player exits the game, it’s a good idea to periodically autosave the players data. You can further mitigate damage by warning the player when their autosave has failed.
Datastores have a massive outage almost every weekend. You cannot rely on bind to close for data, ever.
Is it only big games that get hit by these massive outages? Because I 100% guarantee after setting up a pcall function using GetAsync inside a repeat loop that runs 7 times before giving up, I haven’t had a single case of data loss—and one of the first order of operations for any game I make is creating a Datastore module (nothing special, just using GetAsync & SetAsync) but then again, I don’t have a huge game that has to handle hundreds of thousands of players.