SpaceX disrupted the commercial launch industry with a single engineering insight: if you can reliably land and reuse the first-stage booster, you can cut the cost of reaching orbit by more than half. A Falcon 9 launch costs approximately $62 million. Comparable launches from other providers cost $165 million or more. The difference is almost entirely the booster.
The booster recovery is not guaranteed. It depends on a precise sequence of atmospheric re-entry maneuvers, controlled deceleration, and landing pad targeting that represents an engineering challenge of extraordinary difficulty. Whether the booster survives depends on the mission parameters payload mass, orbit type, launch site, atmospheric conditions, booster version in ways that are not fully predictable from first principles.
That is a machine learning problem. And it is the problem this project addresses.
Why This Problem Is Interesting
The economic stakes are real. If you can predict, before a launch, whether the first-stage booster is likely to survive, you can:
- Price launch contracts more accurately
- Plan booster refurbishment schedules
- Identify mission parameters that increase recovery probability
- Compete with SpaceX's pricing by predicting their cost structure on a per-mission basis
This is not a toy classification problem. It is a business intelligence question with direct commercial implications.
The Data: Two Sources, One Integrated Dataset
The project integrates two data sources, which is itself a non-trivial engineering task.
The SpaceX REST API provides structured launch records: launch site, booster version, payload mass, orbit type, launch outcomes, and landing attempt results. The API returns nested JSON that requires careful flattening, normalization, and type conversion. Missing values exist not because of data quality failures, but because not every mission recorded every variable, and some fields were added to the API schema after older launches were logged.
Wikipedia's Falcon 9 launch record tables provide supplementary historical data, extracted using BeautifulSoup HTML parsing. Web scraping presents its own challenges: HTML table structure varies across pages, text encoding inconsistencies require handling, and the parsed data must be reconciled with the API records without introducing duplicate rows.
The integration step merging two datasets that share overlapping but not identical records, with different levels of completeness and different schema conventions is where data engineering judgment is required. Which source takes precedence for conflicting values? How are launch records matched across sources with different identifier conventions? These decisions affect every downstream analysis.
The EDA: What the Data Actually Shows
Before touching a model, I spent significant time understanding what the launch data reveals about recovery success. Several patterns emerged with strong signal.
Launch site matters substantially. Not all sites are created equal for landing recovery the distance from potential landing zones, the orbital inclination constraints, and the infrastructure for drone ship versus land landing operations all vary by site. The data shows distinct success rate differences across KSC LC-39A, CCAFS SLC-40, and Vandenberg SLC-4E.
Orbit type is strongly predictive. Polar orbits and sun-synchronous orbits require different trajectory profiles than geostationary transfer orbits or low Earth orbit missions. The energy budget for re-entry varies dramatically, directly affecting landing success probability.
Payload mass has a complex relationship with landing success. Lighter payloads leave more propellant available for the landing burn. Heavier payloads require more first-stage fuel for ascent, leaving less for recovery. The relationship is not linear there are mission-specific factors that mediate the mass-recovery connection.
Booster version shows a clear learning curve. Early Falcon 9 versions (v1.0, v1.1) had substantially lower recovery rates than the Full Thrust and Block 5 variants. The Block 5 the current operational version was explicitly designed for reusability, with heat-resistant titanium grid fins and other modifications that improve landing reliability.
The Feature Engineering Decisions
Several features required engineering decisions beyond simple extraction from the raw data.
Binary encoding of the landing outcome the target variable required careful definition. A "success" is a booster recovery where the booster is confirmed intact and reusable. Failures include both soft crashes (the booster touched down but was damaged) and uncontrolled re-entries. The distinction matters for the classification problem: a near-miss that recovers a severely damaged booster is not equivalent to a clean landing.
Orbit type required one-hot encoding rather than ordinal encoding because orbit types have no inherent order LEO is not "less than" GTO in any meaningful numeric sense. Treating them ordinally would impose a false mathematical relationship.
Payload mass was normalized using StandardScaler before modeling. Tree-based methods like Decision Tree and KNN are sensitive to feature scale in different ways. While Decision Trees are theoretically scale-invariant in their splitting decisions, the normalization was applied consistently across all models to ensure fair comparison.
The Model Comparison
Four classification algorithms were evaluated: Logistic Regression, Support Vector Machine, Decision Tree, and K-Nearest Neighbors. All were tuned with GridSearchCV optimizing for accuracy on a stratified 80/20 train-test split.
The Decision Tree Classifier achieved the highest test accuracy at 94.44%, followed by SVM and KNN at 83.33%, with Logistic Regression providing a comparable baseline.
The Decision Tree's performance advantage reflects the nature of the data: recovery success is governed by relatively crisp decision boundaries (specific orbit types, launch sites, and booster versions have categorical effects on recovery probability) rather than smooth continuous relationships that would favor SVM or logistic regression.
The SQL Integration: Structuring Knowledge
The dataset was loaded into an IBM Db2 database and analyzed using structured SQL queries not because SQL was strictly necessary for a project of this scale, but because the discipline of structuring analytical questions as database queries reveals things that Pandas exploration does not.
SQL queries force you to be explicit about joins, aggregations, and filter conditions in a way that Pandas method chaining sometimes obscures. When you write a SQL query to find the success rate by launch site, you are explicitly naming the aggregation function, the grouping variable, and the filter condition. This explicitness is valuable for sharing analytical logic with teams that are not Python-native which, in enterprise contexts, is most of them.
The Interactive Dashboard
The Plotly Dash dashboard provided the analytical interface for exploring the dataset interactively filtering by launch site, adjusting payload mass ranges, and examining the relationships between mission parameters and landing outcomes through scatter plots and pie charts.
This component demonstrates something important about full-stack data science: the analysis and the communication of that analysis are not separate work. A dashboard that lets a non-technical stakeholder explore the data themselves, ask their own questions, and arrive at their own conclusions is more valuable than a static presentation of conclusions I selected for them.
Predictions as Intelligence
The project's final model a 94.44% accurate Decision Tree Classifier provides genuine predictive value for the stated business objective: estimating whether a Falcon 9 first stage will land successfully on a given mission.
The key features driving the prediction are exactly what domain expertise would predict: orbit type, launch site, payload mass, and booster version. The model has learned the same relationships that SpaceX's engineers understand from physics and operational experience but it has learned them from data alone, which means it can be applied to new mission profiles without requiring the physical intuition that underpins SpaceX's own flight planning.
What would a production version of this system add? Real-time telemetry integration, continuous learning on new launches, ensemble methods to improve robustness, and calibrated probability estimates rather than binary classification. Those are the directions the roadmap points to.
But the foundation a system that reasons from real launch data to landing probability estimates is what makes any of those extensions possible. You cannot build a production intelligence system without first building the data pipeline, the analytical understanding, and the validated predictive model that this project delivers.
Full source code, notebooks, and interactive dashboard are available on GitHub.