Capturing everything used to be a strategy. For most of the last decade, the default was simple: store it cheaply, figure out what's valuable later. Storage was cheap. Cloud providers made procurement easy. The prevailing wisdom was that data appreciates - the more of it you hold, the more valuable your organisation becomes.
That logic is breaking.
The cost nobody budgeted for
The cost of storing data isn't the disk bill. It's everything that comes with it.
Every record you hold has to be governed, secured, discoverable for compliance audits, classifiable under GDPR, CCPA, or any regulation the next parliament writes - and deletable on demand, which means knowing where it lives, what it's connected to, and what breaks when it's removed. The cloud invoice is the visible tenth of this iceberg.
The data lake started as a strategic asset. For most organisations, it has quietly become a liability without a budget line. The compliance exposure, the security surface area, and the engineering effort to maintain defensible governance over a petabyte of "we might need this someday" are harder to see than the AWS bill. They're also substantially larger, and they're growing faster.
And here's the uncomfortable part: most of what's in the lake has never been queried. It was captured because the philosophy was to capture everything. It sits there accumulating cost, risk, and regulatory burden, generating little value.
The question CIOs are asking now
The serious conversations happening in boardrooms right now aren't about making the data lake faster. They're about what should be in the lake at all.
Which data is genuinely valuable for long-term analysis? Which data is operationally critical today but has no long-term retention case? And what was captured by default because "storage is cheap" that's now sitting there creating exposure nobody can justify to the audit committee?
These are hard questions because the entire analytics stack was built on the assumption that everything goes into the lake first, and analytics happens after. Spark, Polars, DuckDB, the batch ecosystem - these tools are designed to query stored data. They need a materialised dataset to exist before they can do anything with it.
That assumption forces an uncomfortable choice: retain everything and accept the compounding cost, or throw things away and hope you don't need them. Neither is acceptable as a long-term strategy.
The above options assume storage has to come first. It doesn't.
Stream, Compute, Act.
Data can be analysed as it flows - at the point of capture - with only the results worth keeping written to storage. Retention becomes a deliberate output of validation, enrichment, policy, and analysis, not the prerequisite for it. Three things changed:
History evolved. ETL and ELT were built around a real risk: a transformation failing mid-run, a schema mismatch between vendor systems, or a column that behaves differently once it crosses from an API into SQL or Python. Writing a raw copy first was the sensible hedge. But that hedge hardened into an operating model: extract everything, store everything, transform later. Lightning changes that. Pipelines are type-checked before deployment, and teams that still want the safety net can write to storage in the same pass they compute on the stream.
Compute got faster. The clusters that justified extract-first were born from the assumption that storage was cheap and compute was not. That assumption is no longer load-bearing. Modern Rust on commodity hardware now delivers throughput that required medium-sized Apache Spark clusters only a few years ago. When the data is tied to a live commercial decision, the question is no longer "where do we store this first?" It is "why are we waiting?"
Lightning does it upfront. Lightning can clean, enrich, tag, mask, validate, compute, and route on the stream as it moves. Data quality exceptions can go straight to Slack, Teams, a ticketing API, or a workflow system while there is still time to act. No separate batch job, orchestration layer or parsing types across an API, a SQL engine, and a Python environment. Nail it upfront, and let it run.
This is SCA: Stream. Compute. Act. The natural successor to ETL and ELT for the live era.
Live operational intelligence - trade signals, sensor readings, telemetry, customer actions, fraud signals, machine events - does not need to sit in a lake first. The value is in processing it as it arrives, influencing the outcome while there is still time.
The long-term analytical backlog becomes a decision about what is worth the compounding cost of keeping: trend analysis, model training, audit requirements, and regulatory retention. Clean and transform at the source, keep fewer raw copies. Everything has to earn its place.
This is no longer theoretical architecture. Lightning delivers it.
The Analytics Stack Tax
The same storage-first assumption also creates the broader analytics stack tax: additional tools, handoffs, integration work, and cost between event and outcome. You can read more about that here.
SpaceCell Lightning: It's Time to Act.
SpaceCell Lightning is the live computational engine for data manipulation, statistical modelling, and streaming execution. It lets teams process, enrich, validate, and act on data before raw copies become the default.
It acts at the source. Quality issues can be caught before they spread, sensitive fields can be masked before they become stored liabilities, and teams can work against one compute model instead of passing logic across tool boundaries.
In practical terms:
It replaces the batch pipeline for many workloads. The nightly extract, the hourly aggregation job, the "pipeline runs at 2am" workflow - those disappear. Data flows through Lightning continuously, results are produced as events happen, and the downstream systems your organisation actually runs on are acting on updated reality rather than yesterday's snapshot.
Execute on the signal. Trigger the alert. Update the dashboard. Route the human or agent workflow. Personalise the experience while the customer is still there. Remove the bottlenecks and rewrite the playbook.
It replaces the statistics stack. Regression, hypothesis testing, time-series analysis, 43 univariate and 24 multivariate distributions - built into the engine, running at native speed on the same pipeline as your aggregations. Your data science team and your data engineering team stop swapping files between two environments and start working as one.
It minimises the integration layer. When you run five tools, a conservative 30 to 40%+ of your engineering effort goes to the glue. Lightning is one tool. The integration layer shrinks considerably as data is modelled upfront.
It reduces your storage footprint. When analytics happens at the capture point, you don't need to store the entire raw feed to analyse it later. You store the outputs that have long-term value. The rest flows through and is processed without ever hitting disk. Your governance surface shrinks to what you've deliberately chosen to keep, and the regulator's question - "what do you hold and why?" - has an answer that starts with a policy rather than an apology.
What this means for the business
More Capital. One engine instead of five. The $40,000 to $80,000+ monthly ETL bill across multiple tools compresses considerably. Memory stays flat because the engine processes streams rather than materialising datasets - so there are no out-of-memory (OOM) errors pushing you to a bigger cloud instance every time data volume ticks up. The overhead that was going into plumbing redirects into work the organisation actually asked for.
Less Risk. Less data stored is less data to govern. Your compliance surface becomes what you choose to retain, not everything your systems ever produced. When a regulator asks what you hold and why, the answer is a deliberate retention policy rather than "everything since 2019 because our pipeline needed it." The governance burden shrinks in proportion to what is retained. On the security side, the exposure shrinks too - customer PII can be masked at the pipeline level before it is stored to disk, and Lightning's self-contained binary keeps the dependency footprint tightly constrained.
Faster action. The gap between event and intelligence compresses to the processing time of the function itself. A trading desk acts on a signal while it's still actionable, rather than reviewing it in tomorrow's report. A manufacturer catches sensor drift before the batch produces defective parts. A retailer intervenes while the customer is still engaging with the product, not in a next-day junk-routed email that arrives after they've churned.
Structural Edge. The organisations that act on information first are the ones that win. Not the ones with the biggest data lake, or the ones with the fastest batch engine - the ones whose analytical capability runs at the speed of their data, at the moment of the event. Lightning makes that structural rather than aspirational. While the rest of the market chases the next tool, you re-align around outcomes.
Why now
Four forces are converging.
Regulatory pressure is accelerating. GDPR set the direction; CCPA, the AI Act, and a growing set of sector-specific frameworks have followed. The cost of holding data is rising every year. "Store everything" is becoming harder to defend - not because storage became expensive, but because governance scales with it.
The way analytics code gets written has changed. Code is increasingly written by AI and checked by people. The challenge shifts from typing speed to verification: whether your tools surface structural errors before they reach production, or after. As AI writes more of the analytics path, the type system stops being a developer preference and becomes a governance control.
Security threats are evolving. Memory safety is moving from engineering preference to security imperative. Mozilla recently patched 271 Firefox vulnerabilities surfaced by Anthropic's Claude Mythos in a single evaluation pass, with thousands of additional high- and critical-severity findings across major open-source projects - the bulk tracing back to memory bugs that Rust prevents by construction. Supply-chain attacks are rising in parallel. Every dependency is another door. Lightning ships as a single binary, built from the ground up, with a highly constrained Rust dependency footprint.
The competitive window is narrowing. Real-time analytics used to be a luxury reserved for hedge funds. Now it is spreading across fraud, pricing, maintenance, customer engagement, grid operations, manufacturing, telemetry, and risk. The teams that build live capability now gain a structural advantage. Avoid the retrofit.
The bottom line
The data lake era solved a real problem: making large-scale analytics accessible. But the default to store first created costs that are now compounding - storage growth, compliance exposure, security surface area, and data workflows that duplicate, translate, and retain more data than the business needs.
Lightning changes the default. It analyses data at the point of capture, brings statistical computing into the live path, and turns storage into a deliberate, governed decision rather than the first place every event has to go.
The data that needs action must move while it still matters. The data that deserves retention must earn its place.
SpaceCell Lightning: Stream, Compute, Act.
Turn storage from a default into a decision.
Request a confidential walkthrough and see Lightning in action.
Request Access