> No performance tradeoffs, for any workload: Transactional workloads run in standard Postgres with full ACID semantics. Analytical workloads run across the full Lakehouse at any scale and concurrency. Each scales independently, and because there's no data movement between systems, operational and analytical results are always in sync — with no copies or shadow infrastructure.
How can there be no performance trade-off if storage is handled by PostGres and there is no data movement to convert it to columnar ?
This deserve a technical explanation because this seems impossible.
Few observations related to data engineering in the context of a data warehouse:
1. Protocols and IR (Intermediate Representation) have layed and continue to enable interoperability and composability of data tools (see Apache Arrow, Substrait, Catalog). (great introduction here https://voltrondata.com/codex).
2. Current OSS data tooling is really good (except on user interface).
3. Agentic workflow are working incredibly well for data-engineering tasks.
4. LLM is pushing for declarative tools and docs close to code.
That's why I am working on a (early) project called Orca [1]. Orca is a template and a set of patterns for building a production-ready and agentic-enabled data warehouse using entirely free and open-source tools. Go check-out the README for more info. I would be interested to get feedback to it!
I started building an agentic-ready data warehouse (GitHub.com/mathisdrn/orca) and was thinking that my skills could be optimized by benchmarking them. Turns out there is a better way of optimizing and building them using model languages themselves as evaluator and skill builder. See DsPy and GEPA.
I am wondering whether Anthropic and OpenAI skill-creator skill is themselves optimize to optimize skills efficiency on various tasks.
Author doesn't mention it but he should try to use BetterDisplay.
MacOS interface scaling works well for screens around 200 PPI (2K 13inch, 4K 24inch, 5K 27inch). 4K 32inch is 138 PPI, which likely means he is not using default interface scaling which causes some distortion and out of grid pixel rendering.
BetterDisplay fixes this by using an integer multiple of intended GUI scaling resolution before projecting it (3X -> 1.5X).
I believe the author missed another approach of the semantic layer. That is the one used by Power BI Semantic model or, and perhaps, the most interesting one Malloy.
In these tools, the semantic layer is a thin layer that only define the following:
- metric definition (mostly as aggregation function)
- dimensions of analysis (product category, country, etc.)
This blog makes a much better argument than I would at presenting why Malloy is a really interesting and welcome innovation in Data Analytics space : https://carlineng.com/?postid=malloy-intro#blog
How can there be no performance trade-off if storage is handled by PostGres and there is no data movement to convert it to columnar ? This deserve a technical explanation because this seems impossible.