3 ms·

Here's where I've never been smart enough to use this model... help me explain how you deal with scenarios like this... 1) There's an incident and we are tryin

Here's where I've never been smart enough to use this model... help me explain how you deal with scenarios like this... 1) There's an incident and we are trying to replicate the issue, but our database is just shapeless blobs and we can't track down the data that is pertinent to resolving the issue. 2) Product management wants to better understand our users and what they are doing so that they can design a new feature. But they can't figure out how to query our database or how to make sense of the unstructured data. 3) QA wants to be able to build tests and set up test data sets that match those tests, but rather than a sql script, they've got to roll all this json that doesn't have any constraints. These are just some examples, but maybe you get the gist of why I don't quite understand how this model scales "outside" the database.

zegl 4y ago
1) I think that the biggest difference between how you use KV/NoSQL databases is that your objects tends to be much bigger than a "normal" SQL row. Each object can be a parent entity, plus many sub-objects and sub-arrays of information. In a relational model, that data would have to go in other tables that you'd have to join etc. I believe that this model makes things much easier for us, as all you need to debug a single failure usually is stored in a single object, instead of spread out across the entire database. 2) Very true. We're using other tools (like PostHog) for collecting and analysing user behaviour. At a bigger scale, we'd probably ship of event data to something like BigQuery for analysis. 3) We don't have QA, but for testing, objects are created in code just like any other object, and unit tests (aka most of the tests), don't need the database at all. :-)