metriql VS perspective

Some of the companies that operate in space are Cube Dev; Transform(currently acquired by dbt); metriql. See more companies at https://www.moderndatastack.xyz/companies/metrics-store.

Presto is pretty successful but its focus is to be distributed query engine, not a proxy layer for the existing query engines. We use Trino ( formerly Presto) as our query layer and do something similar to Hydra at Metriql [1] with a fairly different use-case. Data people provide a semantic layer with the mecrics and expose them to 18+ downstream tools.

[1]: https://metriql.com

This is why metrics store tooling have started appearing recently (e.g. TransformData, SuperGrain, Metriql, dbt Metrics) - to solve the problem of this table / metric disorganization across an org's data landscape.

We're using Superset to enable our analysts to explore our clients' SEM/SEO/analytics data. It also posts alerts to Slack when, say, the daily session count of a website isn't what was expected given the historical data.

Yeah, it's a little rough to get going, but once it is, we've found it to be a really powerful (and actively developed!) BI tool. It's even better with dbt + MetriQL [0], which can automatically sync Superset's dataset metadata directly with properties you set up in dbt.

Adding custom visualizations is much harder than it should be, but they're very much aware of that, and working to address it. Their Slack community is super-helpful, too.

[0]: https://metriql.com

As a current Looker power-user, this looks really solid.

One thing I’m not sure about though: can you use the metrics outside of the native tool, and if so how?

That is, I see Looker as a BI tool, not a metrics layer, since you mainly use the metrics you define inside Looker, not in other tools. On the other hand, something like MetriQL[0] is a pure metrics layer that can supposedly be used anywhere.

Is this both? If so, some better documentation around how to use the metrics layer would be helpful (or maybe I just didn’t look in the right place).

[0] https://metriql.com/

3. Define metrics in one place on top of your data models and expose the metrics to all the data tools. (This layer is new, and we're tapping it at https://metriql.com)

We use BSL license and metriql is free with a single database target. If you want to connect multiple dbt projects in a single deployment, you need to go through the sales cycle.

We work with ETL vendors that use metriql to make revenue with our BI tool integrations so we picked BSL license to be able to structure our business model in a way that you should be required to pay only if you're reselling metriql to your customers.

You can find the license here: https://github.com/metriql/metriql

Why do you want to render to canvas?

Perspective seems to be the most performant html table. It is more focused on extremely fast updates than styling, although it looks good.

Glide is a newcomer that also renders to canvas.

https://github.com/finos/perspective

https://github.com/glideapps/glide-data-grid

SQL workbench also uses https://perspective.finos.org/ for tables. It's a WASM table library which pairs nicely with duckdb and works well with large tables.

Yes. We are working on adding support for aggregation and pivoting using https://github.com/finos/perspective

I haven't looked extensively at react-datasheet. It looks like it is trying to build more of a full product than the other data tables.

I have used ag-grid extensively, its an impressive product. Some pieces are a little awkward to use, particularly auto-sizing. But generally ag-grid has thought of most functionality and has a solution. The creator of ag-grid had a great interview on Javascript Jabber [1].

The other serious data table component that I have seen is FinOS Perspective [2]. This is extremely high performance, also more specialized and probably harder to customize. I think Perspective renders to a canvas element from Rust/C++ compiled to WASM (not 100% sure). It is also made for streaming updates.

AG-Grid supports streaming updates... but only in the commercial version.

Eventually the data model for these types of tables becomes tricky. I will be investigating parquet-wasm for my use case. Hit me up if you want to collaborate.

[1] https://blog.ag-grid.com/javascript-jabber-podcast/

[2] https://perspective.finos.org/

Something like https://github.com/finos/perspective ? We use an OLAP(-y) WASM engine to provide query-ability to our data visualization tool, and doing the calculations in the browser is cheaper and simpler than a server-side database for datasets that fit in browser memory.