> Question is, what applications is a document-first database good for, outside of prototyping?
Some criteria I’d use:
* Data is already naturally segregated and won’t be shared/joined much during normal usage
* App already has transactions modeled in the application layer (or I guess if consistency really doesn’t matter)
* App would benefit from being geographically distributed.
* App is written in a language with a strong type system, has high code quality, test coverage, etc.
In my case, my company makes a distributed project management application. All changes to projects are canonically ordered and applied in the application layer.
Data is stored in Cloudflare Durable Objects and R2. Hard to classify DOs but they’re a lot closer to a document store than an SQL Db.
There are some nice benefits that would be hard to replicate with a traditional SQL Db setup.
Some criteria I’d use: * Data is already naturally segregated and won’t be shared/joined much during normal usage * App already has transactions modeled in the application layer (or I guess if consistency really doesn’t matter) * App would benefit from being geographically distributed. * App is written in a language with a strong type system, has high code quality, test coverage, etc.
In my case, my company makes a distributed project management application. All changes to projects are canonically ordered and applied in the application layer.
Data is stored in Cloudflare Durable Objects and R2. Hard to classify DOs but they’re a lot closer to a document store than an SQL Db.
There are some nice benefits that would be hard to replicate with a traditional SQL Db setup.