Data Lakehouse Platform Without Lock-In to a Single Compute Engine

Different posture. Databricks is engine-first - proprietary compute (Photon, ML runtime) with Delta Lake as the storage format. Logiciel is open-format-first; we manage Iceberg, Delta, and Hudi tables and federate access across multiple compute engines (Spark, Trino, Snowflake, Databricks, Athena). For customers committed to Databricks as the primary engine, we complement rather than replace. For customers wanting engine portability and avoiding lock-in to a single compute vendor, we replace the proprietary lakehouse layer while preserving Spark/Photon for workloads that benefit from it. Most US customers we serve run multi-engine architectures - Snowflake for SQL analytics, Databricks for ML, Trino for federated query - on shared open-format storage.

Native - Snowflake can read your Iceberg tables (managed by Logiciel or external) with full read performance. We manage the table maintenance (compaction, snapshot expiration, schema evolution); Snowflake handles SQL execution. This pattern is increasingly common for customers who want Snowflake's SQL ergonomics for analysts plus open-format storage for engineering flexibility. The architecture decouples storage decisions (where data lives, in what format) from compute decisions (what engine queries it), which is structurally valuable for long-term flexibility. For customers running both Snowflake and Databricks, the same Iceberg tables serve both engines without data duplication.

Yes - migration tooling for Hive, raw Parquet, ORC, and other lake formats into Iceberg, Delta, or Hudi. Migration includes: catalog conversion (Hive Metastore to Iceberg-compatible catalogs like Glue, Polaris, Nessie), file metadata generation (manifest files, snapshots), partition translation, and parity testing. Migration runs in parallel - the legacy lake stays queryable while the new lakehouse is populated and validated; cutover happens after parity is signed off. For Fortune 500 lakes (petabyte-scale), migration typically takes 3-9 months including parity validation. We've migrated lakes from Cloudera, EMR-based legacy stacks, and on-prem Hadoop to cloud lakehouses.

Per managed table plus storage volume - compute is your bill (we don't markup). Mid-market customers (50-200 managed tables, 1-50TB) typically pay $30-90K ARR. Enterprise tiers (1,000+ tables, multi-petabyte, multi-engine federation, dedicated TAM, US-citizen support) start at $200K ARR. Storage is your S3/ADLS/GCS bill at standard rates; we provide tiering recommendations and snapshot expiration policies that typically save 20-40% on storage cost. For customers comparing to Databricks Unity Catalog or vendor-managed lakehouses, we benchmark TCO at evaluation; Logiciel typically saves 30-50% at equivalent capability with engine-portable architecture.

Workload-dependent, and we'll run a workload-grounded comparison. Iceberg wins for engine portability and catalog flexibility (works equally well with Spark, Trino, Snowflake, Athena); choose it if engine-independence matters. Delta wins if you're Databricks-heavy and committed to that ecosystem; choose it if Photon-optimized performance is the priority. Hudi wins for streaming-heavy mutation patterns (CDC at high volume, incremental upserts); choose it for those workloads specifically. Most US customers in 2026 default to Iceberg for new builds because portability has become structurally important; existing Delta deployments are migrated only when there's a strategic reason. We support all three formats equally well at the platform layer.

Automated, workload-aware compaction with cost controls. Compaction strategies are configurable per table: bin-packing for write-heavy workloads, sort-based for query-optimization, tiered for hot/cold separation. Compaction triggers are configurable (file count thresholds, time-based, size-based) and execution is bounded to budget caps so a runaway compaction job can't surprise your finance team. Snapshot expiration policies are integrated for storage cost management. For customers running large Iceberg tables (multi-terabyte fact tables), compaction strategy materially affects query performance and storage cost; we provide reference compaction patterns and tune per-customer based on workload.

Open tables work for ML - Spark, Ray, Daft, Polars, and direct Arrow access all read directly from Iceberg/Delta/Hudi without intermediate materialization. ML feature pipelines integrate with the lakehouse for training data assembly with point-in-time correctness; vector indexes for RAG live alongside warehouse tables under unified governance. For US AI-native customers, the lakehouse-as-ML-foundation pattern is increasingly standard because it eliminates the typical 'copy data to ML platform, lose lineage' antipattern. Compute engines specialized for ML (Ray, Spark MLlib, distributed Polars) read open-format tables directly, so no engine lock-in for ML workloads.