Granica Crunch FAQ

Compression and data integrity

Is Crunch lossless?

Yes. Crunch uses lossless compression optimization. Every byte of your original data is preserved and recoverable. Pre- and post-crunch are compared and validated automatically.

What are recipes? Does the recipe generator use AI?

A recipe is a data-specific compression and encoding configuration that Granica derives by analyzing the statistical properties of your files — column cardinality, value distributions, sort order, and co-occurrence patterns. The recipe generator uses ML models trained on your actual data to determine the optimal compression codec, encoding strategy, and sort key for each column in each table.

Recipes are stored in the recipe store and applied automatically during Crunch runs. As your data evolves, Granica re-analyzes files and updates recipes — for example, when a schema change is detected. This continuous learning is what allows Crunch to achieve higher DRRs than static, one-size-fits-all compression.

How to maintain the Data Reduction Rate (DRR) after data is crunched?

DRR is maintained by keeping your Crunch policy active. Background Crunch runs on a configurable schedule (daily or weekly) and processes new partitions as they arrive, so incoming data is compressed with the same recipes applied to historical data. If your historical data changes after it has been Crunched, for instance, due to late-arriving data or backfilling an ETL job, historical data needs to be recrunched. For late-arriving data patterns, you can simply configure Crunch to process a rolling window of "Today-10 to Today-1", for example, to ensure that all your late arriving data are fully optimized. Crunch is smart to not reprocess files that were not changed in this process, and only focus on changed or newly added files.

What happens if Crunch encounters a corrupted file?

Crunch validates every file before and after processing. If any integrity check fails, Crunch stops processing that bucket and alerts the operations team. No corrupted data is ever written.

Query and workload impact

Does Crunch affect query performance?

Smaller files generally improve query performance because less data needs to be read from storage. Benchmarks shows that Crunch improves query speed by 10% to 20%. Queries that are IO bounded benefits the most from Crunch. The query acceleration feature further improve query speed by improving file pruning, using techniques such as sorting, z-ordering, stats, and right-sizing files and row groups.

How does Crunch affect query stats?

Crunch reduces physical file sizes by 15–60% without changing logical row counts or column values. Query engines that rely on file-level statistics (row counts, min/max values, null counts) embedded in Parquet footers will see those statistics preserved — Crunch does not alter them. Smaller file sizes mean less data is scanned from storage per query, which typically reduces scan times and lowers cloud storage egress costs.

Is there any impact on data ops when accessing data during crunch time?

No. Crunch is entirely out of the read and write path. While a Crunch job is running on a table, your applications can continue reading and writing normally — Crunch does not hold locks or block queries. For Iceberg and Delta Lake tables, Crunch commits optimized files using the table format's native snapshot commit protocol, so concurrent readers always see a consistent snapshot. For Hive tables, Crunch performs atomic object replacement. In all cases, there is no downtime and no coordination required from your data ops team.

How does Crunch handle files and objects that are shared by multiple tables?

Crunch tracks objects at the table level using catalog metadata. When a Crunch policy is applied to a table, only the files belonging to that table's current snapshot (as recorded in the table's metadata) are processed. Shared objects — for example, files referenced by multiple Delta Lake or Iceberg table versions simultaneously — are not blindly replaced. Crunch uses the table format's native commit protocol to introduce new optimized files as part of a new snapshot, leaving existing shared references intact. Contact your Granica account team if you have a specific shared-storage topology to evaluate.

Compatibility

Does Crunch work with my existing tools?

Yes. Crunch produces standard, format-compliant files. Any tool that reads Parquet today (Spark, Trino, Presto, Athena, BigQuery, Databricks, etc.) can read Crunched files without modification.

Does Crunch support Liquid Clustering?

Liquid Clustering is a Delta Lake feature that organizes data using clustering keys rather than partition directories. Crunch's Background mode is compatible with Liquid Clustered tables — it compresses and re-encodes files while preserving the clustering layout and committing changes via Delta's standard commit protocol. Runtime Crunch compatibility with Liquid Clustering, for both Delta tables and Iceberg Tables, is on the roadmap. Contact sales@granica.ai for the latest status.

Can Granica operate on Databricks' Spark engine such as Photon?

Granica's Runtime Crunch JAR integrates at the Apache Spark / Parquet writer layer. Photon is Databricks' proprietary native execution engine and does not expose the same integration points as open-source Spark. Runtime Crunch is therefore not currently supported on Photon. Background Crunch, which operates independently of the query engine by reading and writing objects directly in cloud storage, is compatible with tables written by Databricks and Photon. Contact sales@granica.ai for details on Databricks compatibility.

Will Granica support new features developed by Databricks?

Granica tracks the Databricks and Delta Lake ecosystem actively. Features that affect the table format's commit protocol or file layout (such as new clustering strategies, column mapping modes, or deletion vectors) are evaluated for compatibility as they reach general availability. Granica's goal is to remain compatible with the evolving open table format ecosystem. Reach out to sales@granica.ai for roadmap questions about specific Databricks features.

What can Granica offer customers migrating between different table formats, such as Hive to Iceberg?

Crunch's primary focus is compression optimization, not format conversion. However, Granica supports all three major table formats — Hive, Iceberg, and Delta Lake — so you can apply Crunch policies before, during, and after a migration. If your migration pipeline produces Iceberg or Delta Lake output, Crunch can begin optimizing the new format immediately as partitions are written. For customers actively migrating, contact your Granica account team to plan the policy transition to avoid redundant work on partitions that will be rewritten.

Deployment and infrastructure

What components are deployed?

Granica deploys a data plane and, depending on your deployment model, a control plane:

• Data plane (always in your cloud): Granica Worker pods (compression optimizers), Spark clusters, and the Tunnel Agent that maintains a secure outbound connection to the control plane.
• Control plane (in Granica's cloud for Hybrid; in your cloud for On-Premises): Granica Console and API, Airflow scheduler, Log and Metrics stores, and a PostgreSQL state store.

All data plane components run as Kubernetes pods on an EKS (AWS) or GKE (GCP) cluster inside your cloud account. See Architecture for details.

Can we use existing infrastructure such as an EKS cluster? What are the requirements?

Granica provisions and manages its own dedicated EKS (AWS) or GKE (GCP) cluster inside your cloud account. It does not share an existing cluster with your workloads. This ensures Granica can control node configuration, autoscaling, pod scheduling, and upgrade rollouts independently without affecting your existing workloads. If you prefer to use your existing Infra, this can usually be supported. Contact sales@granica.ai for minimum infrastructure requirements for your environment.

Does my data leave my environment?

It depends on your deployment model. In the Hybrid model (most common), the data plane runs in your cloud — your actual table data never leaves your environment. Only control plane signals and aggregated metrics (job status, table names, partition counts) flow to Granica's cloud. In the On-Premises model, nothing leaves your cloud. In the Granica Hosted model, Granica manages all infrastructure including data processing.

How do I integrate Granica into my environment?

Granica typically processes your data in the background, reading from and writing to cloud storage without requiring any application integration. You can control Crunch through its APIs to set table policies, trigger actions, and check job status. For more, see how Granica Crunch works.

How much time and effort is required from the customer's data infra/platform team?

Initial deployment typically requires a few days of collaboration between your cloud infrastructure team and Granica's onboarding team — primarily to set up the necessary IAM roles, VPC networking, and cloud account permissions. Once deployed, Granica is self-managed and self-upgrading (in the Hybrid model). Ongoing operational overhead is minimal: administrators configure policies through the Granica Console and monitor progress through the built-in dashboards. No ongoing code changes or pipeline modifications are required for Background Crunch.

How do you achieve exabyte-level scale?

Granica automatically scales out additional nodes to dynamically handle arbitrarily large data volumes. Scaling is completely elastic — as load decreases, Granica automatically shuts down unneeded nodes. This minimizes operational costs and maximizes your savings from Crunch.

How do you ensure my deployment is a success?

Your Granica instance generates usage, system health, and performance telemetry data to enable predictive analysis, alerting, troubleshooting, and overall success. Telemetry data is stored in a cloud storage bucket unique to each customer and deployment, entirely separate from customer data. No customer data is ever collected or analyzed.

How do I undo a Granica deployment?

At any time you can uncrunch any data already processed by Granica Crunch to return it to its original form, by simply rewriting the data using the default Parquet writer. However this is not needed because data processed by Crunch follows open standards and are readable by all engines. You can then teardown your deployment to return your environment to its pre-Granica state.

Savings and pricing

How long does it take to see savings?

You can start seeing storage and compute cost reductions within hours of enabling a Crunch policy on your first table or bucket. The exact timeline depends on the volume of data being processed, which is typically limited by the size of the compute pool that is given to Crunch.

How is Crunch priced?

Crunch pricing is outcome-based. We make sure the customers always achieve a high ROI by using Crunch. Contact sales@granica.ai for details.

What is the estimated cost to crunch per PB?

Crunch pricing scales with the savings it generates, not the volume processed. Because DRR varies by dataset, per-PB cost estimates depend on your specific data characteristics. Contact sales@granica.ai for a tailored estimate based on your data profile.