History keeps repeating itself in data. And nobody seems to notice.

1996.

Ralph Kimball publishes The Data Warehouse Toolkit.

Structured data. Star schemas. Dimensional modeling.

Clean, disciplined, expensive to build, but when it worked, it worked.

Early 2000s.

NoSQL arrives. MongoDB, Cassandra, CouchDB.

“Relational databases are too rigid. Structure is holding us back.”

For document storage, real-time writes, flexible schemas, genuinely useful.

Then oversold for everything else.

2010s.

Data lakes. Hadoop. Snowflake. Databricks.

The pitch: store everything, analyze anything.

For exploration, ML pipelines, document workloads, genuinely powerful.

Then oversold for everything else.

Source-of-truth metrics built on top of data lakes became a reliability nightmare.

2020s.

LLMs arrive. “The AI will organize the chaos.”

RAG pipelines. Vector databases. Unstructured everything.

For exploration, summarization, edge cases, genuinely useful.

Then oversold for everything else.

Why it’s failing: tokens are expensive. $0.02 per token to normalize garbage adds up fast. And you can’t out-token bad modeling.

See the pattern?

Every wave was right for some workloads.

Every wave was oversold for the rest.

LLMs are just repeating it.

The mistake was never unstructured data.

The mistake was pretending one tool fits every job.

Here’s the framework that actually works:

• Entities, source-of-truth metrics, anything you’ll query a million times: structure it
• Document analysis, exploration, edge cases: use the model
• Anything you’ll report on, trust, or act on repeatedly: structure it

I’ve been running data infrastructure for platforms processing 100M+ monthly active users for over a decade. The companies that get this right aren’t picking a side. They’re asking the right question:

“Does this workload need precision or exploration?”

How can I help ?

We don’t sell you a platform and wish you luck.

We build and manage your entire data layer: structured where it pays, flexible where it doesn’t: and we own the outcomes.

The tools changed every decade. The question never did.

What does this data actually need to do?

• Which wave is your data stack still stuck in?

If you’re drowning in data but starving for insight, let’s talk: https://lnkd.in/dBZ8xjEa

The post You can’t out-token bad modeling ! appeared first on Elad Levy.

— Abraham Lincoln

My friend does remodeling and construction work.

I asked him once what the biggest lesson he’d learned in his line of work was.

“90% of the job is using the right tool for the right job.”

I think about that every time I open an audit.

Last week I found a MongoDB instance sitting inside a production platform.

Nothing wrong with MongoDB. But what was it being used for?

1. Session management.

Sessions are temporary. They expire. MongoDB has no native TTL enforcement – so someone wrote a cleanup job to delete expired sessions periodically. Which adds write stress. Which needs monitoring. Because if the job fails, data accumulates silently.

Redis exists for exactly this. TTL is built in. Session expires, it’s gone. Zero maintenance.

2. Analytical history tracking.

MongoDB storing historical data that gets queried for trends and reports. Querying document stores for OLAP workloads is painful. Slow. Expensive.

Kafka + a columnar data warehouse. Designed for exactly this. Faster queries, lower cost, scales properly.

3. Payment transaction records.

This one actually needed a proper relational database. ACID compliance. Foreign keys. Referential integrity. Things that matter when money is involved.

PostgreSQL. Or SQL Server. Or MySQL with InnoDB.

(If you’re still running MyISAM — we need to talk )

Three use cases. Three wrong tools. One database doing a job it was never designed for.

The result? Unnecessary complexity. Write stress. Slow queries. Cleanup jobs that needed babysitting.

We replaced MongoDB with three purpose-built tools.

Less infrastructure. Better performance. Lower cost.

My friend was right.

It’s not about using the best tool.

It’s about using the right one.

• What’s the most misused piece of technology you’ve seen in production?

If this sounds familiar, I do a free 30-minute sanity check. Book here: https://lnkd.in/dBZ8xjEa

The post Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” appeared first on Elad Levy.

One of the most common questions I’m asked almost every week is: Why is Dive different?

Let me start by saying: many off-the-shelf analytics tools work great at first. They help teams get quick dashboards, track events, and launch with confidence.

But here’s the catch: once your product scales, the way companies and data interact hasn’t really changed for decades — and that’s where things start to break.

• The Typical Journey

• Product launch. A team builds a product, launches a beta, and starts growing.
• Demand for insights. Product managers and marketing teams want deeper answers to drive traction, monetization, and campaigns.
• Hiring an analyst. Naturally, the company hires a data analyst. The first thing they ask for? SQL and Excel. That’s how analysts actually work.
• Reality check. With most off-the-shelf tools, there’s no direct SQL access. The analyst can’t do their job. Frustration builds.
• The workaround. The company extracts data, builds pipelines, adds a warehouse, and suddenly… an in-house data team is born.

The Spiral

Before you know it:

• You have data engineers, analysts, scientists, and devops maintaining layers of tools.
• Your “data stack” now costs hundreds of thousands, sometimes millions, per year.
• Instead of building features, you’re building plumbing.

It feels like progress, but really it’s waste. Money, time, and talent are tied up solving problems created by the very tools you started with.

• Why I Started Dive

This cycle is exactly why I built Dive.

We provide the whole data “circus” — ingestion, pipelines, analysis, and scale — for a flat, entry-level price of less than a part-time data analyst salary.

• No hidden costs

• No need for 5–10 extra hires

• No expensive warehouses or tool stacks piling up

Our clients grow revenue without ever needing to build an internal data team or chase every shiny new tool.

The Bigger Picture

As an industry, we’ve become wasteful. We keep raising money, buying tools, and hiring bigger teams — instead of investing directly into better products, better services, and better user experiences.

New tools will always appear. Each promises to solve the problems created by the last. But complexity isn’t innovation.Simplicity and efficiency are.

• Bottom Line

Off-the-shelf tools are fine early on.

But if you want to scale without scaling waste, you need something built for it.

• Curious — have you seen this spiral at your company?

book a call so we can talk about your data

https://lnkd.in/dBZ8xjEa

#Data #Analytics #DataStrategy #DataEngineering #StartupGrowth #ScaleWithoutWaste #Dive

The post Why Your Data Stack Costs 10x More Than It Should appeared first on Elad Levy.

Most companies approach data the wrong way.

At my data services company, Dive, I see it all the time:

1. Management needs a dashboard, insight, or report.

2. They ask the CTO or lead developer.

3. The developer Googles, hacks together a clunky report…

4. It’s often wrong, incomplete, or useless.

The root problem?

No one starts with the questions.

Wrong approaches I hear all the time:

• “We have a data guy.”

There’s no such thing. Data has multiple specialties: engineering, analytics, reporting, science, DevOps, and more.

• “We track everything.”

Wrong. Less is more. Track fewer, better events instead of dumping junk into a “data lake” (aka a pile of crap).

• “We use [insert trendy BI tool here].”

The tool is irrelevant until you know who needs the data, which teams, what type of data, and most importantly: What are their questions?

• The right way:

In 100% of the companies we fix, our first step is wiping the slate clean and starting with questions.

Clear questions lead to:

• Proper data modeling
• Useful events
• Accurate reporting
• Insights you can act on

Good questions:

• How many users installed yesterday?
• How many logged in? (New vs. returning)
• How much revenue did we make yesterday?
• How long until a new user becomes a subscriber?
• Why do users churn, and when?

Bad questions:

• “I want a 360° view of my users.” (What does that even mean?)
• “I want AI.” (AI for what?)
• “We want to track everything.” (Please don’t.)

If you remember one thing from this post:

• Data starts with questions.

Bad questions = bad data.

Good questions = better business.

Want to talk about your data challenges?

Book a call with me here: https://lnkd.in/ddk578gp

The post Better Questions + Better Data = Better Business appeared first on Elad Levy.

In the last years I have started to think whether the metrics we look at are actually relevant. I believe we should update that to modern data and games.

At Dive we always try to go one step further and look at deeper metrics for games like :

• progression system
• churn by
• “time to” FTD
• LTV by days
• rolling retention by segments

Etc

Feel free to contact me and talk data

The post Thanks for the shout ! appeared first on Elad Levy.

The post Shouts to Tammy Levy , Abhimanyu Kumar and the Naavik team. appeared first on Elad Levy.

The post Big shout to all the publishers out there looking for an enterprise grade BI & LiveOps service #analytics #liveops appeared first on Elad Levy.

Thanks guys it was super fun

The post Shouts to Martin Macmillan , Peggy Anne Salz and Pollen VC for this great conversation about #mobilegames #metaverse and… appeared first on Elad Levy.

Link can be found here:

https://lnkd.in/d-XTe9k

Joakim – keep up the quality content

#gamesindustry #mobilegames #analytics

The post Great retention graph example for a game of one of our clients. appeared first on Elad Levy.

Great job on the product guys

The post thank you 🙏🏻🙏🏻. One thing I can say about Greentube PRO – they do hashtag#analytics and hashtag#liveops right appeared first on Elad Levy.