Hey, thanks for bringing up storage efficiency. This is an often cited objection and a big motivation of the Zed project actually. In Zed, data is organized around a self-describing type system rather than schemas, and unlike the relation model, heterogeneous data can land side-by-side at the storage layer. And unlike NoSQL JSON-based systems, Zed is comprehensively typed, which allows us to form vectors for heterogeneous data and get OLAP-style analytics performance even with heterogenous data. We're working on the vector analytics layer as we speak and hope to have an "MVP" of the Zed lake with vector support in the coming months.
TL;DR Zed stores data efficiently based on types not schemas so first-class error values of type "error" fit in anywhere with ease.
TL;DR Zed stores data efficiently based on types not schemas so first-class error values of type "error" fit in anywhere with ease.