Rails Wasn’t Our Bottleneck. PostgreSQL I/O Was.

victor perez — Sun, 19 Jul 2026 12:25:42 +0000

Tansa is a Rails application that transforms Bitcoin data into structured, verifiable information.

Its processing pipeline uses PostgreSQL and Sidekiq:

Bitcoin Core → Layer1 → Cluster → ActorProfile → ActorBehavior → ActorLabels

When one module started falling behind, Rails and Sidekiq looked like the obvious suspects. The processing ran through background jobs, with several large writes going through Active Record.

We could have immediately added more workers.

That would probably have made the problem worse.

What the Measurements Revealed

We waited for the query responsible for inserting data into cluster_inputs, then observed its behavior inside PostgreSQL.

One execution took 114.39 seconds.

During our sampling, almost all the observed wait time was:

IO/DataFileRead

The query accessed approximately:

55 MB from storage
1.6 GB from PostgreSQL’s shared cache

The Rails job was running. Sidekiq was doing exactly what we had asked it to do. Ruby CPU execution was not the main issue.

The pipeline’s throughput was being limited by PostgreSQL reads and the characteristics of the underlying storage.

Why More Workers Would Have Been Dangerous

An additional worker would not have made the disk faster.

It would have sent more concurrent queries to an already constrained database, increased contention, and made the problem harder to diagnose.

We focused on the actual constraint instead:

measuring the exact SQL query;
inspecting PostgreSQL wait events;
increasing shared_buffers from 4 GB to 8 GB;
improving the insertion and flushing path;
controlling the number of concurrent jobs.

During an initial tuning phase, one representative insertion dropped from 252 to 156 seconds. After further improvements, another measured execution completed in 114 seconds.

These are production observations, not controlled laboratory benchmarks. But they gave us the evidence needed to move in the right direction.

The Real Lesson

Saying that a Rails application is slow is not a diagnosis.

Rails was orchestrating the pipeline correctly. Sidekiq was executing the jobs correctly. But PostgreSQL and the storage layer determined the actual throughput.

Before adding workers, replacing a framework, or rewriting a service, ask a much simpler question:

What is the system actually waiting for?

In our case, the answer was not Ruby.

It was the disk.

I document these real engineering decisions and incidents in Building Tansa with AI, a book about the architecture of an application built with artificial intelligence.

Have you ever discovered that a performance problem blamed on your framework was actually caused by the database or storage layer?

A Git Cleanup Left Me With an Application I No Longer Recognized

victor perez — Sun, 19 Jul 2026 11:04:50 +0000

I am building Tansa, a large Bitcoin analysis application using Rails, PostgreSQL, Sidekiq, and AI coding agents.

After months of development, the Git repository had accumulated many commits, branches, recovery points, and AI-generated changes. We decided to clean it up and make the history easier to understand.

The operation appeared successful. The repository looked coherent, the main branch was clean, and the important Git references had been preserved.

Then I restarted the application.

I no longer recognized it.

Recent features were missing, and parts of the application had returned to an older state. Git itself had not failed. The problem was more subtle:

We had produced a cleaner repository without first proving that it contained the correct application.

We had focused on commits, branches, and history. We should have started with a different question:

Which exact functional state are we trying to preserve?

Recovery required us to stop making changes, preserve every available reference, compare candidate versions, and verify the actual application—not only the commit graph.

This incident changed the way I manage Git with AI agents:

Define the functional reference before modifying history.
Create a remote recovery branch and tag first.
Give one person or agent ownership of Git operations.
Require a diff and human approval before destructive commands.
Validate the running application, not only the test suite.
Never delete a recovery reference too early.

A clean Git history is not proof that you preserved the right software.

AI makes development faster, but it can also execute a poorly defined Git decision at remarkable speed. The more agents you use, the more explicit Git ownership and recovery rules must become.

I have documented these lessons in a book about Git and AI-assisted development. The English edition is now published and available on Leanpub: https://leanpub.com/git-in-the-age-of-ai-agents

Have you ever ended up with a technically clean repository that no longer represented the application you intended to preserve?

DEV Community: victor perez

Rails Wasn’t Our Bottleneck. PostgreSQL I/O Was.

What the Measurements Revealed

Why More Workers Would Have Been Dangerous

The Real Lesson

A Git Cleanup Left Me With an Application I No Longer Recognized