Raymond Cheng

I'm just concerned that anything that's not programmatically generated will get out of date and will be a burden to keep up-to-date. How about using something like this instead? [**https://www.npmjs.com/package/@adobe/jsonschema2md**](https://www.npmjs.com/package/@adobe/jsonschema2md)

https://www.kaggle.com/competitions?hostSegmentIdFilter=11 For a list of open-ended analytics competitions. They seem to take submissions out of band via a Google form

@VinitaSilaparasetty I think this should be reserved for someone who has more experience notebooking with our data. I'd suggest trying out our product and making some notebooks first? Thanks!

Categories of things that we care about - Usage / analytics - Performance (throughput, latency) - Availability (i.e. uptime) - NPS (i.e. impact attestation) Types of telemetry - Server-side telemetry...

Saves time but not money

We discussed this, we are currently assuming that network and storage costs are negligible. In this case, the only thing we are saving is time, which Clickhouse imports are pretty...

We can also consider Apache Iceberg instead of Delta Lake. This would be for data upstream from the events table. We should try to preserve the benefits we get currently...

Ever since we solved https://github.com/opensource-observer/oso/issues/821 It's an open question now whether we should move more of our datapipeline to sqlmesh + Trino + Iceberg, instead of dbt + BigQuery. This...

Rescoping. Since we are migrating to sqlmesh in #2559, we should consider just using Trino with the BigQuery connector for the query processing.

I might just close this issue since it's a bit outdated at this point. We did it! Just need to migrate models from dbt to sqlmesh now