• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

What’s up everyone, today we have the pleasure of sitting down with István Mészáros, Founder and CEO of Mitzu.io.

Summary: István built a warehouse-native analytics layer that lets teams define metrics once, query them directly, and skip the messy syncs across five tools trying to guess what “active user” means. Instead of fighting over numbers, teams walk through SQL together, clean up logic, and move faster. One customer dropped their bill from $500K to $1K just by switching to seat-based pricing. István shares how AI helps, but only if you still understand the data underneath. This conversation shows what happens when marketing, product, and data finally work off the same source without second-guessing every report.

In this Episode…

• How Warehouse Native Analytics Works
• BI vs Analytics vs Measurement vs Attribution
• Merging Web and Product Analytics With a Zero-Copy Architecture
• Feature or New Category? What Warehouse Native Really Means For Marketers
• How Decoupling Storage and Compute Lowers Analytics Costs
• How Composable CDPs Work with Lean Data Teams
• How Seat-Based Pricing Works in Warehouse Native Analytics
• What a Data Warehouse Does That Your CRM Never Will

About István

István is the Founder and CEO of Mitzu.io, a warehouse-native product analytics platform built for modern data stacks like Snowflake, Databricks, BigQuery, Redshift, Athena, Postgres, Clickhouse, and Trino. Before launching Mitzu.io in 2023, he spent over a decade leading high-scale data engineering efforts at companies like Shapr3D and Skyscanner. 

At Shapr3D, he defined the long-term data strategy and built self-serve analytics infrastructure. At Skyscanner, he progressed from building backend systems serving millions of users to leading data engineering and analytics teams. Earlier in his career, he developed real-time diagnostic and control systems for the Large Hadron Collider at CERN.

How Warehouse Native Analytics Works

Marketing tools like Mixpanel, Amplitude, and GA4 create their own versions of your customer. Each one captures data slightly differently, labels users in its own format, and forces you to guess how their identity stitching works. The warehouse-native model removes this overhead by putting all customer data into a central location before anything else happens. That means your data warehouse becomes the only source of truth, not just another system to reconcile.

István explained the difference in blunt terms. “The data you’re using is owned by you,” he said. That includes behavioral events, transactional logs, support tickets, email interactions, and product usage data. When everything lands in one place first (BigQuery, Redshift, Snowflake, Databricks) you get to define the logic. No more retrofitting vendor tools to work with messy exports or waiting for their UI to catch up with your question.

In smaller teams, especially B2C startups, the benefits hit early. Without a shared warehouse, you get five tools trying to guess what an active user means. With a warehouse-native setup, you define that metric once and reuse it everywhere. You can query it in SQL, schedule your campaigns off it, and sync it with downstream tools like Customer.io or Braze. That way you can work faster, align across functions, and stop arguing about whose numbers are right.

“You do most of the work in the warehouse for all the things you want to do in marketing,” István said. “That includes measurement, attribution, segmentation, everything starts from that central point.”

Centralizing your stack also changes how your data team operates. Instead of reacting to reporting issues or chasing down inconsistent UTM strings, they build shared models the whole org can trust. Marketing ops gets reliable metrics, product teams get context, and leadership gets reports that actually match what customers are doing. Nobody wins when your attribution logic lives in a fragile dashboard that breaks every other week.

Key takeaway: Warehouse native analytics gives you full control over customer data by letting you define core metrics once in your warehouse and reuse them everywhere else. That way you can avoid double-counting, reduce tool drift, and build a stable foundation that aligns marketing, product, and data teams. Store first, define once, activate wherever you want.

Back to the top ⬆️

BI vs Analytics vs Measurement vs Attribution

Business intelligence means static dashboards. Not flexible. Not exploratory. Just there, like laminated truth. István described it as the place where the data expert’s word becomes law. The dashboards are already built, the metrics are already defined, and any changes require a help ticket. BI exists to make sure everyone sees the same numbers, even if nobody knows exactly how they were calculated.

Analytics lives one level below that, and it behaves very differently. It is messy, curious, and closer to the raw data. Analytics splits into two tracks: the version done by data professionals who build robust models with SQL and dbt, and the version done by non-technical teams poking around in self-serve tools. Those non-technical users rarely want to define warehouse logic from scratch. They want fast answers from big datasets without calling in reinforcements.

“We used to call what we did self-service BI, because the word analytics didn’t resonate,” István said. “But everyone was using it for product and marketing analytics. So we changed the copy.”

The difference between analytics and BI has nothing to do with what the tool looks like. It has everything to do with who gets to use it and how. If only one person controls the dashboard, that is BI. If your whole team can dig into campaign performance, break down cohorts, and explore feature usage trends without waiting for data engineering, that is analytics. Attribution, ML, and forecasting live on top of both layers. They depend on the raw data underneath, and they are only useful if the definitions below them hold up.

Language often lags behind how tools are actually used. István saw this firsthand. The product stayed the same, but the positioning changed. People used Mitzu for product analytics and marketing performance, so that became the headline. Not because it was a trend, but because that is what users were doing anyway.

Key takeaway: BI centralizes truth through fixed dashboards, while analytics creates motion by giving more people access to raw data. When teams treat BI as the source of agreement and analytics as the source of discovery, they stop fighting over metrics and start asking better questions. That way you can maintain trusted dashboards for executive reporting and still empower teams to explore data without filing tickets or waiting days for answers.

Back to the top ⬆️

Merging Web and Product Analytics With a Zero-Copy Architecture

Most teams trying to replace GA4 end up layering more tools onto the same mess. They drop in Amplitude or Mixpanel for product analytics, keep something else for marketing attribution, and sync everything into a CDP that now needs babysitting. Eventually, they start building one-off pipelines just to feed the same events into six different systems, all chasing slightly different answers to the same question.

István sees this fragmentation as a byproduct of treating product and marketing analytics as separate functions. In categories like travel and ecommerce, that distinction quickly falls apart. A user visits a flight search engine, drops off, comes back six months later, runs another search, and finally books. The product needs to convert that journey efficiently. Marketing needs to bring in as many of those journeys as possible. Everything runs through the same funnel, even if different teams own different pieces.

“You want to maximize the number of visitors, but also how well they go through the application and exit positively,” István said.

That overlap becomes even more obvious when lifecycle teams start automating onboarding, or when sales teams try to prioritize leads based on what they’ve done in the product. Everyone needs access to the same event data, just filtered through a different lens. Most companies solve that by duplicating data. They create mirrored records in their CRM, CDP, product analytics platform, marketing automation tool, and warehouse. Then they spend the next 12 months chasing inconsistencies and paying for storage five times over.

Mitzu skips that entire loop. Instead of building yet another data silo, it queries the warehouse directly. Every funnel step, cohort calculation, or retention metric is defined in SQL and run against your actual data. That way you can skip the sync jobs, stop moving millions of rows around, and avoid the version control disaster that happens when everyone builds their own truth.

Key takeaway: Centralized data should stay centralized. Use a warehouse-native analytics layer that runs directly on your existing warehouse or data lake. That way you can: (1) Avoid redundant syncs between tools and reduce operational overhead (2) Give product, marketing, and lifecycle teams shared access to event data from a single source (3) Run real-time queries on your full dataset without exporting or reformatting and (4) Scale analytics without building fragile pipelines that duplicate logic and storage. Data works better when you stop copying it and start using it where it already lives.

Back to the top ⬆️

Feature or New Category? What Warehouse Native Really Means For Marketers

Warehouse-native analytics rewires how marketing teams interact with data. It hands control back to the people building infrastructure and reduces the trust gap between charts and reality. End users still get dashboards and funnels, but under the surface, the data stack looks completely different. István explained that from the user’s point of view, it feels familiar. From the builder’s side, it is a new category entirely.

When data lives in third-party tools, problems get locked in. Mistakes in tracking, outages, or schema changes create dead ends. Marketers are left annotating drop-offs with footnotes like, “Ignore this spike, it’s a tracking bug.” István described how teams switching to Mitzu often say, “Finally, the numbers in our funnel match what we see in our company-wide dashboards.” That kind of consistency is rare and powerful. It stops finger-pointing and starts actual decision-making.

Warehouse-native analytics brings three things that legacy systems can’t deliver:

• versioned control over your data models,
• the ability to fix bad data after the fact,
• and exact alignment between operational tools and business reporting.

That way you can track what matters, fix what breaks, and stop losing hours reconciling numbers. When everyone looks at the same source, the conversation shifts from “why is this number off?” to “what are we going to do about it?” People move faster when they trust the data. Marketing ops becomes a team that unblocks progress instead of one that explains inconsistencies.

Mitzu goes further by showing the SQL behind every chart. You can review it, reuse it, and even challenge it. István shared how some teams use those sessions to debate retention definitions or conversion logic. They walk through queries line by line. Everyone sees how metrics are built, not just what the final number is.

“We generate the SQL. You can copy it and paste it into your own BI tool. That way, nothing is hidden,” István said. “Now we can actually talk about how things are calculated.”

Key takeaway: Warehouse-native analytics gives marketers a way to validate numbers, trace logic, and fix mistakes without waiting on vendors. That way you can align with the data team, eliminate guesswork in reporting, and make faster decisions based on shared definitions. When marketing, analytics, and leadership all use the same data source, trust stops being a bottleneck and starts becoming an advantage.

Back to the top ⬆️

How Decoupling Storage and Compute Lowers Analytics Costs

Data warehouses are still new territory for many marketers, yet the industry has already moved on to louder buzzwords. Conversations now swirl around data lakes, meshes, fabrics, and real-time systems. The jargon piles up while the core concept gets buried. What matters is how your architecture handles scale, budget, and flexibility. That’s where the separation of storage and compute changes everything.

István puts it plainly. Most systems people call data warehouses are actually operating like data lakes. The label just makes them easier to explain in meetings. The key distinction is architectural. In a data lake setup, you store everything in cheap cloud storage, then fire up compute only when you need it. That’s a different mindset from older warehouse models where compute had to run constantly, even just to accept data.

“You collect data and forget about it. You don’t modify it much. It just sits there until you want to do something.”

This model works because it flips the cost profile. You:

• Store data passively, at low cost
• Activate compute only when needed
• Shut it off immediately after processing

That structure avoids the sunk cost of idle clusters. István shares a customer story where billions of rows come in monthly, but analysis happens just once a week. They generate a single chart. The storage costs are near zero, and compute is only charged for those brief bursts. In older models, ingesting that much data would mean keeping an expensive engine running constantly. Now, compute can scale down to zero.

Data teams no longer need to justify constant dashboard usage to keep their setup efficient. Collect freely, let the data sit quietly, and only pay when something needs to be calculated. That way you can operate lean, even with heavy pipelines.

Key takeaway: Decoupling storage from compute makes analytics dramatically cheaper. Store every event without worrying about budget, then run compute jobs only when needed. This setup works especially well for marketing teams that want to collect behavioral data now and explore it later. Instead of maintaining a bloated warehouse, use a lake-style architecture that waits quietly until you ask it to work. Pay for what you use, not for what you might use.

Back to the top ⬆️

How Composable CDPs Work with Lean Data Teams

Composable CDPs only work when someone in the organization knows how to make them work. That means understanding how marketing needs differ from product analytics needs, how to model data across both, and how to wrangle a warehouse without wrecking performance. István has seen companies pull it off with a single backend engineer handling the data stack in their spare time. It can function, but every piece of it leans on one person holding it together with context, intuition, and duct tape.

“You need at least one person who knows what they’re doing,” István said. “Most of our customers have one. Some have zero.”

Mitzu’s team steps in with informal guidance when needed. They don’t run full-service data projects, but they will Slack someone a quick fix when BigQuery queries stall out or event models drift off course. That level of support works for teams that know just enough to be dangerous. It also exposes a harsh truth. Composable stacks are fragile when there’s no one with the experience to maintain them. The tools aren’t self-driving. Someone has to steer.

Packaged CDPs and traditional BI tools keep working because they require fewer decisions. For early-stage teams without a dedicated data person, that simplicity matters. You plug them in, send events, and get dashboards. They may feel clunky or bloated later, but they keep the team moving without having to hire for edge-case problems. That tradeoff is often worth it while the business is still figuring out what matters.

A warehouse-native model starts to win when data scale and complexity get too heavy for point-and-click interfaces. Once teams start asking layered questions that cross product usage, marketing channels, and revenue models, the flexibility of working directly in the warehouse pays off. But that flexibility creates overhead:

• Someone needs to model data with stakeholders in mind
• Someone needs to maintain and debug joins across source systems
• Someone needs to translate business needs into warehouse logic

That person is rare. They understand systems, but they also speak marketing. They can tell when a schema decision will break a future dashboard or when an event name will confuse a lifecycle team. The composable CDP isn’t just a tooling decision. It’s a team readiness checkpoint.

Key takeaway: Composable CDPs only work when there is at least one person on the team who can model and maintain shared data across marketing, product, and analytics. If your team lacks that person, start with packaged tools that reduce complexity. If you have that person, lean into warehouse-native tools for more control, precision, and scale. The success of your data strategy depends more on who operates the system than which stack you choose.

Back to the top ⬆️

How Seat-Based Pricing Works in Warehouse Native Analytics

Event-based pricing has quietly become one of the worst-kept rackets in martech. Every tracked click, pageview, or custom event you send off to a traditional analytics vendor is one more reason for them to send you a bigger bill. This model scales your cost right alongside your data, not your actual usage. István thinks that’s broken, especially for companies that already pay to warehouse their data.

Mitzu flips that model with seat-based pricing. If you have 10 billion events in Snowflake, Mitzu doesn’t care. You don’t get charged more for having more data. You only pay for how many people actually use the analytics platform. That means no event counting, no back-and-forth with finance, and no surprise invoices. You can finally grow your data footprint without wondering what it’s going to cost to access your own product metrics.

“We don’t store your data. We don’t touch your data. We query it directly. Charging by volume wouldn’t even make sense,” István said. “That’s why we charge per seat. You’re already paying for your warehouse. We’re not going to charge you again for your own data.”

This hits especially hard for companies running large-scale operations. István has seen teams get quoted half a million dollars a month just to use product analytics tools that mirror what they already store internally. One customer with a lean 15-person team and tens of billions of events was facing exactly that. With Mitzu, their cost dropped to $1,000 a month. That kind of delta doesn’t just raise eyebrows, it blows up procurement assumptions.

Of course, this model isn’t for everyone. If you’re a small startup with a tiny event stream, traditional vendors might still undercut Mitzu’s pricing. But once you cross a certain threshold (think millions of events or more) seat-based pricing doesn’t just save money, it unlocks you from a billing model designed to penalize growth.

Key takeaway: Event-based pricing penalizes companies for growing their data, while seat-based pricing aligns cost with actual team usage. If you already have a modern data warehouse and a team ready to work with product analytics, switching to a warehouse-native, seat-priced tool like Mitzu can reduce your analytics bill by up to 90 percent. Stop paying to re-buy your own data. Let your data grow, and only pay for the humans using it.

Back to the top ⬆️

What a Data Warehouse Does That Your CRM Never Will

CRMs make it too easy to lie to yourself. Change a lead status, bulk upload a list, or manually tweak a lifecycle stage and nobody questions it. The data looks clean on the surface, but nobody remembers who made the change or why. Mistakes compound quietly, and decisions keep getting made on assumptions that were broken weeks ago. István compared CRMs to glorified Excel sheets, and he meant it literally. They offer too much freedom without accountability.

Data warehouses demand structure. Updates happen through scheduled jobs, written in code, reviewed by humans, version-controlled, and deployed with intention. Errors can still happen, but they are easier to detect. If a job fails, it fails loudly. You can’t quietly override a million rows with a mouse click. That friction protects the integrity of your models, which matters when you’re calculating LTV, building conversion funnels, or segmenting customers by behavior.

“In the data warehouse, it’s slightly harder to make a mistake,” István said. “You need a job that updates the table every day. Someone can review that job. If you mess up, it’s easier to catch.”

Marketers still hesitate to embrace this system. Many see the warehouse as something owned by engineering, irrelevant to their workflows. So they stay in their CRM bubble, relying on point-and-click reporting, unaware of how much underlying logic is broken. This isolation keeps marketing teams from seeing the full picture and erodes trust in the numbers they report.

That mindset costs teams real revenue. It prevents alignment across departments and leads to conflicting dashboards and fractured decision-making. Warehouses are not aspirational tech. They are the standard for any team serious about knowing what is actually happening in their business. Treating them as optional only ensures that marketing continues flying blind.

Key takeaway: CRMs let errors hide in plain sight. Warehouses make those errors visible, traceable, and fixable. If you care about making accurate decisions at scale, stop treating the warehouse like someone else’s problem. Start treating it like the only source that can be trusted across your entire business.

Back to the top ⬆️

How AI-Assisted SQL Generation Works Without Breaking Trust

Analysts who rely on AI to build dashboards faster still need to know what their data means. When a stakeholder asks for sales figures in a boardroom, no one wants a chatbot to guess. István uses AI tools daily. He leans on GPT to clean up blog drafts and Copilot to scaffold code. But he does not hand over decision-making to a model. He tests it, reruns it, and watches closely when the outputs drift.

“Ask the same question twice. If the AI gives you two different answers, that’s a red flag,” he said. “Even with the newest models, it still happens more than it should.”

Large language models remain unreliable for granular, trust-sensitive work. They invent things. They trip over syntax. They provide plausible answers that can fall apart under scrutiny. When that happens in analytics, the cost is higher than in code. Business decisions run on those numbers. Someone needs to trace the logic, not just read the result.

AI works better when the unit of work is bigger. Instead of generating SQL line by line, István wants models to reuse full logic blocks. These are not mysteries. They are established patterns across product analytics teams:

• Funnel queries built from event timestamps
• Retention calculations using session identifiers
• Attribution windows based on campaign touchpoints
• Conversion stages joined by user or account IDs

The industry already knows what these patterns look like. Most of them fall into two or three common query structures. Reinventing them every time adds friction and risk. István’s team is building toward a future where models don’t hallucinate these from scratch. Instead, they fetch proven building blocks, assemble them reliably, and reduce variance across use cases.

“For product analytics, calculating a funnel should look roughly the same in every company,” he said. “It’s not black magic. It’s solved logic.”

Key takeaway: AI can speed up SQL generation, but only when it leans on reusable logic blocks. Analysts should learn to recognize standard query structures and treat AI as a way to move faster through known terrain. That way you can avoid hallucinated syntax, ensure trust in your numbers, and spend more time interpreting results instead of rewriting the same query 50 different ways.

Back to the top ⬆️

How to Future-Proof a Career in Marketing Data Analytics

AI tools are doing more than accelerating workflows. They are rewiring how junior marketers and analysts think, or stop thinking. When every query can be generated by ChatGPT, it becomes easy to skip learning the logic behind the output. That pattern is becoming a liability, especially in data-adjacent roles where decisions rely on more than copy-pasted syntax.

“They turn to AI with much more confidence than they should,” István explained. “They don’t take the time to understand the fundamentals.”

You cannot debug a broken dashboard if you never understood the data model. You cannot suggest a fix for a faulty conversion rate if you never learned what qualifies a customer. These aren’t soft skills. These are table stakes for having a point of view in a meeting where data drives decisions. Analysts who lean too hard on shortcuts often struggle to explain how things work or why certain patterns matter. That loss of credibility compounds quickly.

Using AI should feel like adding gears to your bike, not like switching to an escalator. István encourages new analysts to do the slow work early. Run the AI-generated query, then rewrite it yourself. Read the documentation, even when the tool spits out a shortcut. Use the tech, but only after your brain has done its own pass. The best way to stay useful in a company is to become the person who can actually explain what the tool got wrong.

The best marketing analysts can read a schema like a story. They understand which behaviors indicate intent and which signals are noise. They do not wait for a dashboard to tell them what to think. They dig, question, and pressure-test ideas before packaging them for others. That work is harder than prompting ChatGPT, but it builds the kind of professional instinct that AI still cannot fake.

Key takeaway: Relying on text-to-SQL too early blocks real learning. If you work in marketing ops or analytics, you need to understand how data behaves, not just how to extract it. Use AI to extend your thinking, not to replace it. That way you can stay sharp, stay credible, and stay employed.

Back to the top ⬆️

How To Navigate Founder Burnout While Raising Kids

Startup founders live in a pressure cooker. Add a toddler to the mix and the temperature spikes. István manages both by drawing a hard line around family time. He spends every free moment with his three-year-old, usually building Lego trucks and towers on the floor. That time is sacred. He doesn’t treat it as recovery or productivity. It is presence. It is play. It is the only part of his day where the KPIs are joy and connection.

Work operates on an entirely different rhythm. Shifting from individual contributor to founder forced István to change how he makes decisions. He used to agonize over things like buying a car, researching every option until it became exhausting. Now he gives himself thirty minutes, picks something solid, and moves on. The stress of constant judgment calls never disappears. It just starts to lose its grip.

“Now I just don’t care anymore about significant decisions like that. It’s amazing,” he said.

The mental bandwidth goes toward scaling a six-person company into deals with firms 100 times their size. That takes nerve. It also takes unlearning the habits of being a service-minded IC. As a founder, István pushes himself to ask for more, take bigger swings, and accept that missed deals are part of the job. The thrill of seeing enterprise companies say yes to Mitzu.io still gives him a high. He admits that when it works, it feels unreal. When it doesn’t, he moves on quickly, because there’s no time to dwell.

He keeps his sanity by surrounding himself with other founders who get it. Coffee chats turn into venting sessions. Casual catch-ups become group therapy. There is no silver bullet. There are just a few hard-won boundaries, a high tolerance for chaos, and a commitment to making space for joy, especially the kind found in a pile of mismatched Lego bricks.

Key takeaway: Let go of perfection. Protect your energy for what matters. Make faster decisions when the stakes are low so you can focus fully when they are high. Build a circle of founders who keep you grounded, and make time for the parts of life that remind you why you are building anything at all.

Back to the top ⬆️

Episode Recap

Broken dashboards slow down teams. They create doubt, stall decisions, and leave marketing and data leads chasing inconsistencies no one can explain. István has spent years watching that play out inside large organizations. He built backend systems at Skyscanner and led analytics teams at Shapr3D. Today, he runs Mitzu to fix the root cause.

Mitzu runs directly on top of your warehouse. That means no data gets duplicated or reshaped across multiple platforms. Instead of syncing events into five tools, teams define metrics once in SQL and use them across campaigns, dashboards, and product reports. That consistency builds trust across functions and saves time spent revalidating numbers.

One customer moved from paying $500,000 a month in analytics fees to $1,000 by switching to seat-based pricing. Mitzu charges based on the number of users, not the volume of data. Teams already pay to store their own data. Mitzu lets them analyze it without paying again to access it. When everyone can review the SQL behind a funnel chart, conversations become more productive. People argue less about whether a metric is accurate and spend more time improving the queries that define it. Visibility into logic drives alignment.

Mitzu works especially well for companies with someone who understands data modeling. That person connects business goals with technical structure. They recognize when an event name will confuse a lifecycle team or when a join will break future reports. When that knowledge is missing, simpler packaged tools often make more sense.

AI can help, but only when used carefully. István uses GPT and Copilot daily, but he reviews everything. He runs the same prompt twice to test for consistency. When the output changes, he rewrites the query by hand. Junior analysts who rely too heavily on AI often lose the chance to understand how data behaves. That gap makes it harder to troubleshoot, explain logic, or lead conversations in the room.

The entire conversation focused on giving teams control over their data. When metrics stay consistent and logic is visible, people stop guessing. They make faster decisions with more confidence. They stop feeling uncertain when opening a dashboard. That clarity lets them focus on what actually matters.

Listen to the full episode ⬇️ or Back to the top ⬆️

Follow István and Mitzu 👇

• LinkedIn
• Mitzu.io

✌️

—
Intro music by Wowa via Unminus
Cover art created with Midjourney (check out how)

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

Related tags

See all episodes

Future-proofing the humans behind the tech

Apple •Pocket Casts•Google •Overcast •Spotify •Breaker •Castro •RSS

• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed