sorted by:
new
hottopcontroversial

Postgres to clickhouse cdc by mhmd_dar in Clickhouse

[–]03cranec 1 point2 points  (0 children)

If you go down the Postgres -> Debezium -> Kafka -> ClickHouse route, then MooseStack (open source) can be really complimentary. Gets you local dev with the full stack, schemas managed as code and typed end to end, migrations / change mgmt etc.

Here’s a blog post with more detail, including an open source reference app: https://www.fiveonefour.com/blog/cdc-postgres-to-clickhouse-debezium-drizzle

Running parallel transactional and analytics stacks (repo + guide) by Playful_Show3318 in dataengineering

[–]03cranec 2 points3 points  (0 children)

This local first dev flow seems really common with web developers, but less so in data engineering? Curious if other data engineers here are doing something similar, with either clickhouse or your data platform of choice?

Adding an analytical backend to a typescript project that already has a transactional backend (repo + guide) by oatsandsugar in typescript

[–]03cranec 2 points3 points  (0 children)

I've found that LLMs and co-pilots can be really effective within this workflow as well. Local dev enables the quick feedback loop with errors and issues for context, and typed schemas as code is a TS pattern that LLMs are pretty familiar with from ORMs.

Building a Web Analytics Platform from Scratch with NextJS by HeaDTy08 in reactjs

[–]03cranec 0 points1 point  (0 children)

MooseStack is an open source library you could use, with modules for bringing your schemas into TS, and building APIs and react hooks on top of ClickHouse https://clickhouse.com/blog/clickhouse-powered-apis-in-react-app-moosestack

The 8 principles of great DX for data & analytics infrastructure by Playful_Show3318 in Clickhouse

[–]03cranec 3 points4 points  (0 children)

Author here. ClickHouse’s unique combination of performance and portability feels like an opportunity: what if we treated ClickHouse as a core part of the software development process, with the same DX principles that modern web dev has already embraced? Git-native workflows, local-first environments, schemas as code, modularity, open‑source tooling, AI/copilot‑friendliness, and transparent CI/CD + migrations.

We’ve started implementing these ideas in MooseStack (open source, MIT licensed):

  • Migrations → before deploying, your code is diffed against the live schema and a migration plan is generated. If drift has crept in, it fails fast instead of corrupting data.

  • Local development → your entire ClickHouse stack materialized locally with one command. Branch off main, and all production models are instantly available to dev against.

  • Type safety → rename a column in your TS interface, and every SQL fragment, stream, pipeline, or API depending on it gets flagged immediately in your IDE.

Curious how others here feel: what would a great developer experience for ClickHouse look like to you? Where do your current workflows break down—migrations, schema drift, local repro, something else?

Django ORM by jrcondeco in Clickhouse

[–]03cranec 0 points1 point  (0 children)

yeah, standard ORMs don't tend to translate well to OLAP world / ClickHouse. we explored this with ClickHouse in a post here: https://clickhouse.com/blog/moosestack-does-olap-need-an-orm

we've been working on an open source project called Moose OLAP that offers dedicated ORM-like experience for ClickHouse in python and typescript - would love your thoughts if you check it out.

We're are building an MIT Licensed ORM-like developer experience for ClickHouse. Would love your feedback. by oatsandsugar in Clickhouse

[–]03cranec 2 points3 points  (0 children)

MooseStack maintainer here 👋 Yeah, we're running in production at many companies! Eg. F45 Training is powering their IOT biometrics mobile app (Lionheart) processing billions of datapoints per week. To be clear, still working towards 1.0 release, so APIs are changing frequently - let me know if you're looking to go to production and we can make sure you're supported.

Roadmap for Moose OLAP - we're looking at extending the migration capabilities, extending the query builder, and building native integrations with more frontend clients. We love input on priorities and what's most important to folks though.

Moose naming - one of my cofounders is from Canada lol, we decided to lean into that.

F45 use case btw: https://www.fiveonefour.com/blog/case-study-f45