DATA ENGINEERING · ETL · ANALYTICS · BI
ORBITPME DATA CORE
From fragmented data to reliable business decisions.
Sales, inventory and finance, brought into one validated view. Orbit demonstrates a complete data engineering stack — and lets you explore its synthetic business data right here.
01 / THE PROBLEM
One business. Too many versions of the truth.
Small and medium-sized businesses often operate with disconnected sales, inventory, CRM and financial systems. Reporting becomes inconsistent, time-consuming and difficult to trust.
Orbit consolidates exports, transforms them into analytical models and checks their consistency before presenting business metrics.
A shared view of sales and margins, a clear picture of inventory shortages, and an actionable list of overdue invoices.
02 / INTERACTIVE DEMO
Your questions. The actual data.
Change a region, channel or period. Sales, customers and related invoices update together. Every number comes from the project's synthetic fixtures and business definitions.
This browser-side showcase does not run PostgreSQL, dbt or Dagster. The complete engineering stack is reproducible locally from GitHub. Inventory and quality describe the full dataset, not a region or sales period. Inspect the fixtures ↗
03 / WALKTHROUGH
See the full stack in motion.
78-second walkthrough: business context, the ingestion architecture, an actual Dagster run, documented test results and the Streamlit analytics interface. All business data is synthetic. English on-screen captions; no narration required.
04 / ARCHITECTURE
From exports to decisions.
Select a stage to see its role. Dagster orchestrates ingestion, transformations and business validation.
Orchestrates processing and validation
01CRM / ERP / FinanceFive synthetic CSV exports+
Customer, order, order-line, inventory and invoice exports represent disconnected operational systems.
02PythonIncremental ingestion+
Column contracts, strict updated_at watermarks and idempotent upserts load only new or changed source rows.
03PostgreSQLCentral storage+
Separate raw, metadata, staging, marts and observability schemas keep source data, transformations and checks traceable.
04SQL / dbtStaging & analytical marts+
Five staging views and five business models turn operational records into consistent sales, inventory and receivables definitions.
05ValidationTested business metrics+
dbt tests check keys and relationships. Five business checks validate integrity, amounts, margins and ingestion freshness.
06Streamlit / PlotlyBusiness analytics+
The local dashboard reads analytical marts to display sales, margins, inventory alerts, overdue invoices and quality results.
05 / VERIFICATION
Engineering, with evidence.
Documented local verification: 17 October 2026. These are engineering checks, not customer outcomes or performance benchmarks.
- Python tests
- 4 / 4
- dbt models built
- 10
- dbt tests
- 23 / 23
- Business checks
- 5 / 5
- New rows on unchanged replay
- 0
- GitHub Actions CI
- Passed
06 / THE APPLICATION
The actual application.
Original project screenshots, optimized for the web. The recorded desktop demo and fixture export may use different reference dates.
07 / STACK
A deliberate stack.
- Ingestion
- Python
- Database
- PostgreSQL
- Transformations
- SQL / dbt
- Orchestration
- Dagster
- Analytics
- Streamlit / Plotly
- Testing
- pytest / dbt tests / business validation
- Infrastructure
- Docker Compose / GitHub Actions
08 / VALUE & DECISIONS
Built around operating questions.
- Consolidate reporting sources
- Track sales and gross margins
- Find inventory shortages
- Prioritize overdue invoices
- Check data consistency
- Reproduce reporting processes
Demonstrated here with synthetic exports. Real connectors, custom KPIs and company-specific workflows are possible adaptations that require their own implementation and validation.
Why PostgreSQL + dbt?
PostgreSQL provides durable relational storage; dbt makes transformations, relationships and tests explicit in versioned SQL.
Why incremental and idempotent?
Watermarks skip unchanged source rows. Key-based upserts make a replay safe without duplicating records; an unchanged replay ingested zero new rows in the documented run.
Why a browser-side public demo?
It exposes only synthetic data and derived calculations. There is no public database-owner connection, Dagster endpoint, credential or write access to the local stack.
How can it become a client system?
Connect real sources, agree business definitions, then add least-privilege access, authentication, backups, monitoring and deployment operations. Production readiness requires separate verification.
09 / YOUR NEXT MOVE