Leading the Team That Rebuilt the Engine

Our predictive jobs took 24 to 48 hours to run. That was the problem. Not a theory, not a roadmap item. A job would start, and two days later you found out if it worked.

I was Chief Technology Officer (CTO) at MonitorBase from October 2015 to February 2025, then VP of Development until April 2026. We ran a credit monitoring platform for 10,000 clients, with more than 7 million queries a month. I led a team of 12 or more developers. When the engine underneath you is that slow, leadership is not motivational speeches. It is picking a better engine and getting the whole team through the swap without breaking the business.

Pick in the open

We evaluated SingleStore against Snowflake and a few other real options, including search tools and staying on MySQL. I did not want a vendor demo. I wanted our workload, our joins, our pain.

One test said a lot. A PHP process that handled 10 to 15 million records with 8 joins took 24 to 48 hours. In SQL on SingleStore it took under 10 minutes. Numbers like that end arguments.

We picked SingleStore in part because it fit Laravel, which was our stack. I have been in Laravel in production for more than 10 years. A database that fights your framework is a tax you pay every day. Simply put, fit matters.

Just as important, the team saw the tests. They ran them. When people help pick the tool, they do not spend the next year relitigating the choice.

Hold the lines that do not move

One rule never bent. Actual credit data was never cached. It was always pulled directly from the database, for compliance reasons.

Everything around it was cached. We ran a large Redis system for logged in clients, sessions, and the rest of the site, so dashboards loaded near instantly. That split was clear, and I kept it clear. The team never had to guess where the line was.

Leadership on a migration is mostly that. Say what will change. Say what will not change. Do not move the second list halfway through.

Roll it out and measure it

We moved to SingleStoreDB Cloud and used Pipelines to bring in 100 million records. The results were not subtle.

Predictive algorithms went from 24 to 48 hours down to 15 minutes, roughly 200 times faster. Throughput went from 60 requests per minute to 1,000 requests per minute on Columnstore. Dashboards stayed on top of that data for clients who needed answers fast.

I also published a Laravel package for SingleStore full text MATCH against indexes. You can see that work on my GitHub. It was not a side quest. If we were betting the platform on this database, we were going to understand it well enough to extend our own tools around it.

That is why I keep the packages public on GitHub. And it is why I point people to GitHub when they ask what the migration actually produced. Slides are easy. Working code and measured results are harder to fake.

What I learned leading it

1. Test with your real workload. Vendor benchmarks do not know your joins.
2. Let the team run the evaluation. A choice they tested is a choice they will defend in production.
3. Keep one or two rules absolute. For us, never cache credit data was that rule.
4. Measure before and after in plain numbers. Hours to minutes is a sentence anyone can understand.

I was not the smartest database person in the room, and I did not need to be. My job was to set the criteria, protect the team from churn while they did the work, and make the final call when the tests were done.

The takeaway

If you lead a migration, just do this. Pick the criteria in the open, test your ugliest real job first, hold your non negotiable rules firm, and publish the before and after numbers. The team does the rebuilding. Your job is to make sure they only have to rebuild it once.