Nearly every data science team eventually produces the same artifact. It starts as a notebook. It grows. Someone copies it and modifies it.
Paths get hardcoded. Configuration lives in variables at the top of cells. Nobody can run it except the person who wrote it, and eventually not even them. Kedro is an opinionated answer to that pattern, and its documentation is essentially an argument that data science projects should be structured like software projects, delivered through a tutorial rather than a lecture.
The spaceflights tutorial is the centrepiece and it is well made. It builds a realistic project from nothing, introducing each concept when it becomes necessary rather than front loading the theory. You meet the data catalogue when you need to stop hardcoding file paths. You meet nodes and pipelines when the processing steps need structure.
You meet parameters when configuration needs to leave the code. The pacing is good and the example is substantial enough to be convincing without being so large it becomes tedious. A lot of framework tutorials are too trivial to demonstrate why the framework exists, and this one avoids that trap. The data catalogue is the idea most worth taking away, and it is one that improves your thinking whether or not you adopt the framework.
Declaring your datasets and their locations and formats in configuration, separate from the code that processes them, sounds like a small thing. In practice it eliminates an entire category of problem. Moving from local files to cloud storage becomes a configuration change. Swapping a development sample for the full dataset stops being a code edit.
Anyone who has tried to run a colleague's script and spent an hour fixing paths will see the value immediately, and the documentation makes the case well. The framework's stance on separating configuration from code, keeping credentials out of the repository, and making pipelines composable and testable is not novel to anyone with a software engineering background, but a great many data scientists arrived through statistics or science rather than software and were never taught any of it. Kedro teaches these practices by making them the path of least resistance, which is far more effective than telling people they should write better code. Now the honest costs.
This framework is opinionated and that is not a soft opinion. There is a Kedro way to structure a project and deviating from it produces friction at every turn. If the conventions match how you want to work, that constraint is liberating because the decisions are already made. If they do not, you will spend your time fighting the framework and you should use something else.
The documentation presents the conventions as obviously correct without acknowledging that reasonable people organise projects differently, and I would prefer a franker treatment of where the opinions come from. The overhead is real and the documentation does not weigh it honestly. Setting up a project properly takes time. Adding a step means touching several files.
For an exploratory analysis that will run once, this structure is pure cost with no return. The framework pays off on projects with real lifespans, multiple contributors, and code that will be run repeatedly by people who did not write it. Applying it to everything is a mistake and the docs will not warn you. Migration is harder than the documentation suggests.
Restructuring an existing tangled project into Kedro's shape means untangling it first, which is the actual work, and the framework does not help with that part. Teams hoping to adopt Kedro as a way to fix an existing mess usually discover that the fixing has to happen before the adoption. Start fresh where you can. The ecosystem is smaller than the mainstream orchestration tools.
There are plugins and integrations and they cover the common cases, but you will find gaps that would not exist in the more widely adopted alternatives, and you will occasionally be the person writing the connector. Four point zero for documentation that teaches genuinely valuable discipline through a well constructed tutorial, and that has real substance behind its opinions. Marked down for not being honest about when the overhead exceeds the benefit, for the difficulty of migration, and for a smaller ecosystem than the alternatives. If your team keeps producing projects nobody can run twice, this is a serious and worthwhile answer.