KRkristianp·Oct 10, 2026Submission
Dbt enables data analysts and engineers to transform their data
2 points · Open discussiondbt-labs
dbt
Rust2019–2026
dbt-labs / dbt
dbt
dbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.
20Distinct people
22Mentions
1Explicit recommenders
14.2KGitHub stars
What to know before exploring
What it is
dbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I highly recommend dbt (data build tool) for a modular approach to sql; postgres, snowflake, bigquery or redshift. https://github.com/fishtown-analytics/dbt
chishaku used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year22 dated mentions
Observed mentions: 2019-04-20 14:15:24 UTC to 2026-10-10 21:37:35 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 3 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 5 | 3 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
22 sourcesI'm biased since I built a dbt[1] inspired utility[2] that turns markdown into a runnable DAG, but I think a new language is the wrong abstraction.
In a time where people are reading less and less code, introducing a new surface area -- that you don't have a good feel for -- to handle orchestration feels risky.
---
[1] https://github.com/dbt-labs/dbt-core
[2] https://github.com/pdthq/pdt
In Show HN: Skillscript – A declarative, sandboxed language for tool orchestrationit's fun for things you're ok with throwing away.
For example, I wanted a dbt[0] like tool, but written in rust, specifically focused on duckdb. Claude Code knocked it out[1] it without much guidance.
Also added support for all duckdb output options (e.g. write to a partitioned parquet instead of a table).
0 - SQL transformation tool (https://github.com/dbt-labs/dbt-core)
1 - https://github.com/definite-app/crabwalk
In I've been using Claude Code for a couple of daysJust noticed 404s on dbt core - was this announced recently?
https://github.com/dbt-labs/dbt-core
In Dbt no longer open source?Dbt-Core: Transform Your Data with Software Engineering Best Practices
2 points · Open discussionCheckout Airbyte and singer.io for data movement. They're tailored for moving offsite data local, but also have support for moving data between different database vendors. I'd recommend starting with Airbyte.
For transformations I'm a sucker for dbt-core, which executes transformations as SQL against your data warehouse vs. a separate process. This keeps everything simple and (generally) snappy. It uses the Python Jinja2 template library to compose SQL templates, and the process that parses templates to SQL also implicitly creates an execution DAG so you could have hundreds of transformations running in the exact order they need to.
There are also many commercial offerings (Fivetran, Dataform) that don't tick self-hosted, but could be easier to deploy if getting internal hardware support is an issue.
https://github.com/airbytehq/airbyte
h
Read the rest
dbt integration was one of our major goals early on but we found that the interaction wasn't as straightforward as we had hoped.
There is an open PR in the dbt repo: https://github.com/dbt-labs/dbt-core/pull/5982#issuecomment-...
I have some ideas about future directions in this space where I believe PRQL could really shine. I will only be able to write those down in a couple of hours. I think this could be a really exciting direction for the project to grow into if anyone would like to collaborate and contribute!
In Relational is more than SQL> Could you share more specific details? Happy to look over / revise where needed.
Sure thing! I'd say first off, the solutions may look different for a small company/startup vs. a large enterprise. It can help if you explain the scale at which you are solving for.
On the enterprise side of things, they tend to buy solutions rather than build them in-house. Things like Informatica, Talend, etc. are common for large enterprises whose primary products are not data or software related. They just don't have the will, expertise, or the capital to invest in building and maintaining these solutions in-house so they just buy them off the shelf. On the surface, these are very expensive products, but even in the face of that it can still make sense for large enterprises in terms of the bottom line to buy rather than build.
For startups and smaller
Read the rest
companies, have you looked at something like `dbt` (https://github.com/dbt-labs/dbt-core) ? I understand the desire to write some code, but often times there are already existing solutions for the problems you might be encountering.
ORM's should typically only exist on the consumer-side of the equation, if at all. A lot of business intelligence / business analysts are just going to use tools like Tableau and hook up to the data warehouse via a connector to visualize their data. You might have some consumers that are more sophisticated and may want to write some custom post-processing or aggregation code, and they could certainly use ORM's if they choose, but it isn't something you should enforce on them because it's a poor place to validate data since as mentioned there are different ways/tools to access the data and not all of them are going to go through your python SDK.
Indeed in a large enough company, you are going to have producers and consumers that are going to use different tools and programming languages, so it's a little bit presumptuous to write an SDK in python there.
Another thing to talk about, and this probably mostly applies to larger companies - have you looked at an architecture like a distributed data mesh (https://martinfowler.com/articles/data-mesh-principles.html)? This might be something to bring to the CTO more than try to push for yourself, but it can completely change the landscape of what you are doing.
> More broadly is the issue of the gap of what you think the role is, and what the role actually is when you join. There are definitely cases where this is accidental. The best way I can think of to close the gap is to maybe do a short-term contract, but may be challenging to do under time constraints etc.
Yeah this definitely sucks and it's not an enviable position to be in. I guess you have a choice to look for another job or try to stick it out with the company that did this to you. It's possible there is a geniune existential crisis for the company and a good reason why they did the bait-and-switch. Maybe it pays to stay, especially if you have equity in the company. On the other hand, it could also be the case that it is the result of questionable practices at the company. It's hard to make that call.
I really dislike SQL, but recognize its importance for many organizations. I also understand that SQL is definitely testable, particularly if managed by environments such as DBT (https://github.com/dbt-labs/dbt-core). Those who arrived here with preference to python will note that dbt is largely implemented in python, adds Jinja macros and iterative forms to SQL, and adds code testing capabilities. No ORM required whatsoever.
In Python: Just Write SQLIntriguing! I would like to learn more about how well dbt can "take over"/reverse engineer an existing database.
> What is dbt?
https://docs.getdbt.com/docs/introduction
Collaborate on data models, version them, and test and document your queries before safely deploying them to production, with monitoring and visibility.
https://docs.getdbt.com/docs/supported-data-platforms
--
core: https://github.com/dbt-labs/dbt-core - Python, Apache 2 license
cloud: https://www.getdbt.com/pricing/
In SQL + M4 = Composable SQLAsk HN: It's time for a `.config` path in repos
As the number of tools built for repos increases, the roots of repos are becoming increasingly cluttered.
A repo like dbt-labs/dbt-core [0] has 21 files in its root, almost all config files like `Makefile`, `Dockerfile.test`, `pyproject.toml`.
GitHub's structure — showing the full file listing before the Readme — means that this clutter adds a small tax to browsing repos. Those 21 files appear below 14 directories, so it's 2+ screens before we can see the readme.
Would folks support a standard path for config files, like a `.config` path, similar to the XDG default? Tools would look there in addition to the root of the repo, and so we could move many of those config files out of the root.
If there were support: I'm not sure of the best way of organizing this. Maybe a few tools start embracing the standard, and others follow? Or we have a
Read the rest
"arewedotconfigyet.com" site? Does putting a config file in the root help the marketing of tools, such that tools are less incentivized to do this?
[0]: https://github.com/dbt-labs/dbt-core
yeah, this issue has been open for years. We need them for Clickhouse for our product.
https://github.com/dbt-labs/dbt-core/issues/1162
In PostgreSQL views and materialized views and how they influenced TimescaleDBdbt has just opened a serious conversation about supporting Python models. I'm sure they'd value your viewpoint! https://github.com/dbt-labs/dbt-core/discussions/5261
In Lessons learned from running Apache Airflow at scaleShowing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.