When One Database Isn’t Enough: A Coffee Brand’s Journey from MySQL to MySQL + Iceberg

A real-world story of growing pains, and why “MySQL vs. Iceberg” is the wrong first question to ask

It started with a simple complaint from the analytics team: “The dashboard keeps timing out.”

The client is a subscription coffee brand — customers sign up online, get curated coffee gear and beans delivered every month, and the business runs entirely on data: orders, payments, inventory, and a growing pile of customer behavior. For three years, a single MySQL database quietly ran the whole operation. It handled checkout, inventory, and customer accounts without complaint.

But as the brand grew from a few thousand orders a month to hundreds of thousands, things started to strain. Marketing wanted to know which customers were likely to cancel their subscriptions. Finance wanted years of transaction history sliced a dozen different ways. The data team wanted to run models over the brand’s entire order history to personalize recommendations.

Every time someone ran a big analytical query, the checkout page slowed down. Real customers, trying to buy real coffee, were stuck watching a loading spinner because someone else was pulling a quarterly report. That’s the moment it became clear: MySQL was never built to do both jobs at once.

The Job MySQL Was Built For

MySQL, like most traditional databases, is what’s called an OLTP system — Online Transaction Processing. Think of it as a fast, reliable cashier. It’s built to do one thing at a time, correctly and instantly: check if an item is in stock, charge a card, update an order status. It shines when you need to read or write a small amount of data right now, and it needs to be accurate down to the last cent.

That’s exactly why it powered the brand’s checkout page so well for years. A customer places an order, MySQL locks the row, deducts inventory, confirms payment, and moves on — all in milliseconds. It was never designed to scan five years of order history looking for seasonal buying patterns. Ask it to do that while also running checkout, and it starts to choke — which is exactly what happened here.

A Different Kind of Question Needs a Different Kind of Tool

When Lucent Innovation stepped in to look at the problem, the first observation was simple: the database wasn’t broken — it was being asked to do two very different jobs.

The kind of question marketing and finance were asking — look across millions of rows and summarize them — is called OLAP: Online Analytical Processing. It’s a completely different shape of problem, and it calls for a different kind of tool.

That’s where Apache Iceberg came in.

Iceberg isn’t a database in the way MySQL is. It’s a table format — a smart way of organizing huge amounts of data (often sitting in low-cost cloud storage like Amazon S3) so that powerful query engines like Spark, Trino, or Snowflake can read it fast, even across billions of rows. Think of it less like a cashier and more like a massive, perfectly organized warehouse with a detailed inventory map. You’re not looking for one item quickly — you’re counting everything on every shelf, and Iceberg makes that counting fast and affordable, even at huge scale.

Iceberg also handles something MySQL was never built to do well: schema changes and historical snapshots. The team could add a new column, rename an old one, or ask “what did this table look like exactly a month ago?” — all without downtime or risk. That flexibility matters when a growing brand’s data keeps changing shape. (For a deeper technical look at why teams are making this shift, Yingjun Wu’s piece on when to choose Iceberg is a good next read.)

So Which One Do You Actually Need?

Here’s the simple breakdown that guided the decision:

Use MySQL when:

• You need instant, accurate answers about one specific thing (a customer, an order, a payment).
• Many people are reading and writing small amounts of data at the same time.
• You need strict guarantees that data won’t get corrupted or duplicated (ACID transactions).
• Your data size is in the gigabytes-to-low-terabytes range and mostly reflects “right now.”

Use Iceberg when:

• You need to analyze huge volumes of historical data — millions or billions of rows.
• You care more about big-picture trends than instant single-record lookups.
• You want cheap, scalable storage instead of an expensive always-on server.
• Your schema changes often, or you need to look back at what the data looked like in the past.
• Multiple analytical tools need to read the same data without stepping on each other.

What the Brand Actually Did

The brand didn’t throw away MySQL — and most businesses in this position shouldn’t. Instead, MySQL stayed exactly where it was strongest: running checkout, inventory, and customer accounts. Lucent Innovation then built a simple pipeline that copies the transactional data out of MySQL every night into Iceberg tables sitting on low-cost cloud storage.

Now, when the analytics team builds a dashboard or the data team trains a churn model, they query Iceberg — a system built for exactly that kind of heavy lifting. Meanwhile, the checkout page never slows down, because MySQL only handles what it does best: fast, small, precise transactions.

Within a few months, page load times were back to normal, reports that used to time out now ran in minutes, and nobody on the engineering team got paged at 2 a.m. because a quarterly report locked up the orders table.

The Real Lesson

The question was never really “MySQL or Iceberg.” It was “what job is each tool actually doing?” A cashier and a warehouse manager both matter to a growing business — they just don’t do each other’s jobs. The moment the brand stopped trying to make one tool do both, everything got simpler, faster, and a lot less stressful.

If an app is starting to feel slow and the analytics team is starting to feel starved at the same time, that’s usually the sign: the answer isn’t a better database. It’s having both a cashier and a warehouse — each doing what it’s built for.

It is a Lucent Innovation as a case study on modern data architecture for growing e-commerce and subscription brands. Need help deciding whether your business needs a similar setup? Talk to our data engineering team.