- Type accretion: I don't think in general that schema changes like what happens in sql databases works very well (I say this having worked on such systems). In

- Type accretion: I don't think in general that schema changes like what happens in sql databases works very well (I say this having worked on such systems). In big systems, it's hard to get everyone to agree on a moment to CHANGE THE SCHEMA. You can certainly do something like that in Noms -- just write a new dataset and replace the old one. But being able to read old data and leave old clients working I think is powerful. Couple this with the structural typing that falls naturally out of Noms and - I think - you have a more flexible way to change schemas over time. - Security: current thoughts: https://github.com/attic-labs/noms/issues/1183 https://github.com/attic-labs/noms/issues/1183 - Perf: I'm not really following you here. CAS has some positives and some negatives for performance. - expiration: 1. there are a huge number of systems today that never delete data. Taking advantage of that to make other operations faster makes sense. 2. yeah, it's a gc problem. luckily gc is a well-studied problem. Also, as Noms is a merkle tree and merkle trees are good at diff, we have some additional leverage. We don't need to do a full scan everytime. - querying: disagree that it is essential to perf. Another option is to have a schema that matches your access model. You can do that server-side in addition (or instead) of having a query language. === It sounds like you have thought a lot about all of this! If you are interested, your brain would be very appreciated in the github or slack.