Beyond the latency drop: How migrating to Postgres upgraded more than just our database

In 2025, my team at Boozt pulled off a massive technical feat: we migrated our core Finance system from MySQL to PostgreSQL.

If you are interested in the raw engineering metrics — how we cut invoice approval latency to milliseconds or shrank our storage footprint from 2.5TB to 364GB — you should read the excellent breakdown by my manager, José Lorenzo Rodríguez.

But I want to tell a different story. I want to tell you about what happens to a team of 10 senior developers when you make a breaking change after years of stabilization. Two of our guys have been guarding the fort for nearly ten years, having built the entire system from the ground up!

Most of our development team

My story

I joined the team in 2020 as a Junior Developer. It was pretty tough. Everyone around was so knowledgeable and experienced. I felt small at that time, but thanks to a big effort and engagement I got more and more trust and became a Team Lead in one of sub-teams in 2023. Despite 5 years of experience here, I’m still one of less experienced guys in the team…

The “Noise” Before the Silence

Boom! As almost all e-commerces, our company hit a wall. In January we saw our workforce shrink by roughly 20%. It didn’t touch our development team, but something much less predictable happened: after 12 years of work, my manager, Niko, was gently nudged towards new adventures outside the company.

That was a shock for all of us. He was the one who built the concept of the whole Finance systems in the company. He knew everything about it. If he didn’t, he always knew where to grab information from.

Also, he was the one who always believed in me and gave all the support he could. I was pissed off. We were all pissed off and unsure about what’s coming next.

New Chapter: Fintech Branch

Two weeks of uncertainty passed before the white smoke finally appeared. The plan? Create a unified ‘Fintech Branch’ by merging us with Kronor, our internal payment gateway.

We actually knew their lead, José. He had given a guest presentation a few months prior, showcasing how Kronor operates. I remember listening to him back then with a raised eyebrow. His philosophy relied heavily on handling business logic inside the database.

Logic in the database? It sounded… wrong. We left that presentation with mixed feelings, to say the least. To us, a database was a bucket for storage — you put data in, you take data out. Logic belongs in the code, right? And the practical questions piled up: How do you test SQL logic? How do you ensure stability? It felt like trying to swim upstream.”

The ‘Sniffing Around’ Phase

The first few weeks with the new leadership felt a bit like dogs sniffing each other at the park. Cautious. Curious. A little tense. You have to understand: we aren’t a team of juniors who nod at everything the manager says. We are a group where people aren’t afraid to speak their minds. We have our habits, honed over years of keeping a complex system alive. Stability was our god, and change was the potential devil.

So when Jose started talking about moving logic to the database and changing our entire philosophy, we didn’t just clap. We debated.

It wasn’t a dictatorship, though. It was a campaign of persuasion. Jose didn’t just give orders; he gave us homework. He started bombarding us with books, articles, and his own manifestos. I remember looking at one of the PDFs he sent — a paper titled “Out of the Tar Pit” from 2006. My first thought? “Why on earth am I reading this archaic stuff?”

But I read it. And slowly, combined with other papers, something clicked. The paper makes a brilliant distinction between Essential Complexity and Accidental Complexity. It hit home. We started realizing how much of our daily struggle was just fighting “Accidental Complexity”. The philosophy was simple: Simplify. Cut the noise.

“Out of the Tar Pit” by Ben Moseley & Peter Marks, February 6, 2006

Slowly, the message sank in. The skepticism started to fade, replaced by a cautious optimism. What sealed the deal was a promise from leadership: “No rush.” We were assured that technical changes would take priority over business features for the year. The pressure to “just ship it” was lifted.

We started with what I call “untangling the knot.” For years, we had been focused on pushing the app forward, adding feature upon feature. We rarely looked back. Now, we hit the pause button. We opened Lucidchart and started mapping every process, every dependency, every connection to external systems. It was the first time in years we looked at our system from a bird’s eye view. We finally knew exactly what we had.

Postgres First: From Anxiety to “A-ha!” Moments

We all knew what was coming. Jose didn’t walk in wearing a “I Love Postgres” t-shirt on day one — he focused on building relationships first — but his reputation preceded him. When the time came to pick the tool for our revolution, the choice was simple: PostgreSQL.

It was 7 A4 pages of elaboration on why Postgres is a chood choice

I had zero experience with Postgres. Most of the team had very little. The anxiety was real. In one of our early meetings, someone asked the question that was on everyone’s mind: “Are you going to migrate us to this new tech and then leave us alone with the mess?” Jose laughed and promised he wasn’t going anywhere. Then he made a bold prediction: “Soon, you will be the experts.”

To make that happen, we went back to school. We started a Book Club based on “The Art of PostgreSQL”. Every two weeks, we met to share tips and discuss what we’d learned. It wasn’t just dry theory. It was discovery.

My biggest “A-ha!” moment came with LATERAL JOIN. We were already in a phase where we had parallel databases running. I was working on a query for a report that needed to fetch the currency exchange rate for a specific day for every single record. It was heavy. I rewrote it using LATERAL JOIN in Postgres. The result? It went from nearly a second down to 70 milliseconds. I felt like a wizard.

But here is the funny part — the kind of irony only developers appreciate. While digging into the documentation, I discovered that LATERAL JOIN is actually available in MySQL 8… which we had been using for quite some time! We had the power all along, but we were too busy "surviving" to explore our own tools.

While we were devouring the book, we were also rewriting the code. Our strategy was ambitious: modify our PHP application so it could run on both MySQL and Postgres simultaneously. We weren’t just flipping a switch. We were building a bridge, ensuring that when migration day came, the system would be bilingual.

Migration Time!

With the “book club” fueling our minds, we needed our hands to do the heavy lifting. We wrote a custom script to migrate both the schema and the data. The first dry run? A painful 10 hours to copy the database. It took trial, error, and many coffees before we optimized it enough to be viable for a production deployment.

We had initially set a vague deadline for the summer holidays. It sounded optimistic — especially when we looked at our CI pipeline, which was screaming red with over 700 failing tests. But week by week, as we fixed bugs and adapted the application, we gained momentum. The red turned to green.

Finally, we circled a date: a beautiful, early morning in August.

I cannot stress this enough: for a beast this big, you need a plan. Not a mental note, not a “we’ll figure it out” attitude. You need a Battle Plan. We created a Google Sheet where every single step was listed chronologically.

• Who: Every task had a specific owner.
• What: Exact commands or actions.
• Where: Direct links to the jobs, consoles, or dashboards involved.

My role? I was the “Communication Officer,” keeping the rest of the company informed so the devs could focus on surgery.

Our plan for the moment of migration

The 90-Minute Hour We aimed for a 1-hour downtime starting at 6:00 AM. Naturally, the universe threw a curveball. We hit unexpected issues — a blocked port here, a configuration glitched there. The downtime stretched to 1.5 hours. But because we had the plan, we didn’t panic. We just executed the next step.

By 7:30 AM, the system was up. It was breathing. It was running on Postgres. We did it.

But as the adrenaline faded, a new question arose: “Okay, we have this Ferrari engine, so where are we driving…?”

The Great Clean-Up

As my manager, José, wrote in his breakdown: “The lesson is simple: the right database does not just store data. It becomes a partner in building systems, shaping culture, and unlocking velocity. For us, PostgreSQL turned out to be that partner.”

He is right. But from my perspective, the biggest win wasn’t just velocity. It was simplicity. For years, we solved MySQL’s deficiencies by adding more tools. We had Redis for caching, Manticore for search, Rundeck for scheduling, MongoDB for flexible storage. It was a zoo. The migration gave us a chance to open the cage and let them go.

Take MongoDB, for example. We used it to cache heavy developer reports because MySQL choked on them. During the migration, we asked: “Do we really need this?” We tested the same workload on Postgres, and it handled it effortlessly. Result? We deleted MongoDB. One less dependency to maintain. One less point of failure.

Then there was the “Data Hoarding” monster. Our system is 9 years old. The General Ledger table alone — the holy grail of accounting — held 1.2 billion records. On MySQL, archiving or deleting old data was a nightmare of locking tables and downtime. Now? The problem is gone. I’d say 50% of the credit goes to Postgres’s raw performance and partitioning capabilities. But the other 50% goes to the fact that we finally had time to stop and think. We used the migration momentum to audit our data, decide what was trash, and actually delete what we could. We didn’t just get a faster car, we also dumped part of the heavy cargo.

The Real Upgrade: It Wasn’t About the Database

Looking back at the events since January, I realize this revolution was about much more than changing the engine under the hood. It was about changing the drivers.

Ultimately, Postgres is just a tool. It’s a fantastic tool, but it’s not the hero of this story. The hero is the change in philosophy. The shift from “patching” to simplicity. The active avoidance of accidental complexity.

This simplicity is what unlocks innovation. Here is a concrete example: We are currently automating how corporate expenses are booked. In the past, this would have required complex API glue code. Now? We are experimenting with an extension calledpg_ai. It allows us to build prompt contexts using SQL directly from our data and trigger LLM calls straight from the database. No glue code, no middleware. Just data and logic living together.

The stability we prized for so long had a side effect: stagnation. This migration forced us to move. Some of us even fell down the rabbit hole and are now diving deep into internals. But even the skeptics — those who still aren’t 100% convinced this was necessary — I believe have gained something. We all leveled up. We broke the routine. The spark that was lit in January is still burning. I truly believe we are a stronger team now.