SQL where it makes sense. Python where it has to. One orchestrator. One lineage graph.
Modern data transformation isn't pure SQL anymore. You need dbt for analytics, Python for ML feature engineering, Spark for big data - and they all need to live in the same lineage. Logiciel runs them as one orchestrated layer with shared testing, observability, and asset-level lineage.
What it really looks like in most teams:
Teams searching this typically need:
Multi-language transformation in one orchestrator. Multi-language transformation in one orchestrator eliminates a class of operational complexity that hurts mid-stage data teams disproportionately.
Asset-level lineage that crosses dbt, Python, and Spark. Asset-level lineage across SQL, Python, and Spark makes impact analysis and change management work the same way regardless of the underlying transformation engine.
Shared testing and observability - no duplicating quality logic. Shared testing across transformation languages eliminates the duplicate quality logic that's a leading source of inconsistency at scale.
Transformation that respects engineers' tools.
Trading data, risk models, regulatory reporting - sub-second SLAs and audit-ready governance.
Listing data, transaction pipelines, geospatial analytics - multi-source consolidation.
EHR integration, claims pipelines, clinical analytics - HIPAA-aware infrastructure.
Product analytics, customer 360, usage-based billing - embedded and operational data.
Inventory, pricing, order, and customer pipelines - real-time and high-throughput.
IoT, project, and supply-chain data - operational analytics on hybrid stacks.
| Dedicated Pod | Staff Augmentation | Project-Based Delivery |
|---|---|---|
| Embedded data engineering pod aligned to your sprint cadence - typically 3–6 engineers + a US lead. | Senior data engineers, architects, and SMEs slotted into your team to unblock specific work. | Fixed-scope, milestone-driven engagements with clear deliverables and outcomes. |
We map your stack, workloads, team, and constraints in a working session - not an RFP response.
Reference architecture grounded in your reality, with capacity, cost, and migration plans.
Iterative implementation with weekly demos, code reviews, and your team in the loop.
Managed operations or knowledge transfer - your choice. Both with US-aligned coverage.
Continuous tuning of cost, performance, and reliability against measurable SLAs.
Native dbt runs with shared lineage, testing, observability.
First-class Python tasks with package management and isolation.
EMR, Databricks, Glue, on-prem - orchestrated and observed.
Reusable feature definitions across analytics and ML.
Schema, row-level, custom SQL, and anomaly tests in one framework.
Cross-language, asset-level lineage with impact analysis.
Yes - drop your existing dbt project into Logiciel as-is and we add observability, testing, cross-language lineage, and unified orchestration without changing your dbt structure or how your team writes SQL. dbt Core and dbt Cloud projects both work; you can keep dbt Cloud for development workflows and use Logiciel for production orchestration if your team prefers that split. Migration is reversible - Logiciel doesn't change dbt files, just orchestrates and observes them. Most customers report Logiciel makes their dbt practice more reliable at scale (faster CI, better lineage, fewer schema-drift incidents) without any retraining. About 80% of our customer base runs dbt.
Per-task isolation with reproducible builds - each Python task runs in its own dependency environment defined in a lockfile (pyproject.toml + poetry.lock or requirements.txt). No more 'works on my machine' - and no more accidentally upgrading numpy in one pipeline and breaking 12 others. Custom dependencies are versioned in Git, built in CI, and cached for fast cold starts. For ML workloads, GPU-enabled environments and CUDA versions are managed similarly. We support Conda environments for data-science workflows that need them, plus container-based isolation for the most sensitive workloads. Reproducibility is a first-class concern, not a documentation problem.
Declarative - schema, freshness, row-level, anomaly detection, and custom SQL - all in one framework regardless of transformation language. Tests are versioned in Git alongside transformation code, reviewed in PRs, executed in CI on ephemeral environments, and run continuously in production with severity-based routing. Unlike rule-only frameworks (Great Expectations, Soda), we layer ML-based anomaly detection on top of rules, catching the issues nobody thought to test for. Test results integrate with the platform's incident management so a failed test routes through the same lineage-aware alerting as any other pipeline failure. Customers typically eliminate 60-80% of 'is the data right?' Slack threads within a month.
Per-asset pricing regardless of language - a Python feature pipeline, a dbt model, and a Spark job all count as one asset each. Compute is your cloud bill (AWS, Azure, GCP), passed through at cost; we don't markup compute. Logiciel adds platform fees on top: $40-90K ARR for mid-market (200-500 assets), $200K+ for enterprise (1,000+ assets, advanced governance, dedicated TAM). For Spark-heavy customers, we publish a TCO comparison against Databricks Workflows + Jobs pricing - Logiciel typically saves 20-40% by giving you finer-grained workload control and better cost telemetry. Pricing is transparent and contractually capped.
We're a superset, not a replacement. dbt Cloud is excellent for SQL-only teams who want dbt with managed scheduling and a developer IDE. Logiciel handles SQL (via dbt) plus Python, Spark, shell, and custom transformation engines - so when your data scientists want feature engineering in Pandas or your ML team needs Spark, you don't bolt on a second orchestrator. We also include observability (anomaly detection, lineage-aware alerting), governance (catalog, access control, policy enforcement), and cost telemetry that dbt Cloud doesn't offer at any tier. Many customers run dbt Cloud + Monte Carlo + Airflow today; Logiciel typically replaces all three.
Yes - dedicated workflows for ML feature engineering with versioned feature definitions, point-in-time-correct training data assembly, and a lightweight notebook-to-production path. Data scientists write feature definitions in Python or SQL, version them alongside model training code, and Logiciel handles batch and online serving. Feature reuse across models is first-class - define 'customer LTV' once and use it in churn, fraud, and personalization models. For US AI-native scale-ups, this is often the killer use case: replacing 3-4 ad-hoc notebook pipelines with versioned, observed, governed feature pipelines that data scientists author themselves without engineering bottlenecks.
Yes - we manage execution (compute provisioning, dependency resolution, isolation, monitoring); you manage code (feature logic, transformations, model serving). Compute scales automatically based on workload, capped to your budget. Custom Docker images are supported for teams with specialized environments. Cold starts are <30 seconds for typical workloads. For long-running ML training, we provide GPU-enabled compute on AWS, Azure, or GCP with automatic checkpoint and resume. The runtime is optimized for data and ML workloads specifically - not a generic Lambda or K8s wrapper. Customers report 30-50% reduction in DevOps overhead versus self-managed runtimes.
Drop your dbt project into Logiciel in a 30-minute working session. See it running with added Python, Spark, and unified lineage in one place.