And how about those teams that are starting out and don't want to build all of that? It's worth the effort given that it's a common problem that teams need to solve over and over.
One of the biggest challenges for us has been getting through people's heads that "version controlled database" doesn't mean "schema migrations with extra steps". Some people get it immediately, but in general there's a real failure of imagination about what kind of use cases this technology enables.
Our customers are building workflows that are just impossible to achieve with other databases. There are a few common use cases that come up over and over:
* Game development, to version control game configuration data being edited by an entire team of developers at once
* CMS-like tools, including online storefronts, so you can have pull request workflows and easy rollback
* Collaborative data sourcing, where multiple independent sources get merged together into a single database
There's also the distributed use case, where people fork and clone each other's data sets, that we haven't really seen take off yet. Or maybe those people are just unlikely to buy hosting services or file support tickets.
Our customers are building workflows that are just impossible to achieve with other databases. There are a few common use cases that come up over and over:
* Game development, to version control game configuration data being edited by an entire team of developers at once * CMS-like tools, including online storefronts, so you can have pull request workflows and easy rollback * Collaborative data sourcing, where multiple independent sources get merged together into a single database
There's also the distributed use case, where people fork and clone each other's data sets, that we haven't really seen take off yet. Or maybe those people are just unlikely to buy hosting services or file support tickets.