Firebolt's Microservices Rollback: Lessons on Deployment, Coordination & Fault Isolation

What Firebolt Brought Back Into the Core Process

In a 2026 SAO Workshop paper, Firebolt — an analytical database company — described moving previously shared services (metadata, identity, garbage collection) back into the main database process. The old architecture isolated tenant compute engines but shared metadata, identity, and GC services across tenants. This organization eased team division of labor but added coordination overhead and made delivering the system to other environments more costly.

The new direction merges several subsystems into the core database program while still using PostgreSQL for metadata and relying on object storage. The term "monolith" here refers to software organization and delivery, not a single machine; the database, storage, and scheduler remain external dependencies.

Module boundaries (who calls what interfaces, who owns state) and process boundaries (independent startup, resource allocation, failure handling) are distinct. Modules can keep clear interfaces inside one process, while multiple processes can become tightly coupled through shared tables, circular calls, and simultaneous releases. The article uses a toolbox analogy: several tools once packed in separate boxes are now placed in one compartmentalized box — easier to transport and inventory, but the compartments (module boundaries) may still be needed to prevent tools from damaging each other.

Fewer Network Calls, But the Real Savings Are Elsewhere

Merging reduces some remote-call serialization, network round-trips, and cross-service error handling, but this is not a guaranteed performance win. If the original latency came mainly from disk scans or external data access, cutting internal calls may not change user-visible latency; new in-process resource contention could offset gains.

The more important factor is how many runtime conditions must be satisfied when replicating the system to another environment. Each independent service brings its own startup config, connection credentials, version compatibility matrix, monitoring, and upgrade sequence. Individually simple, together they multiply the conditions that must hold simultaneously at deploy time. For software that must be repeatedly deployed into different customer environments, this deployment cost can outweigh microseconds saved per request. Firebolt's case re-evaluated this organization after deployment constraints changed.

On day-to-day changes: if a business field requires three services to process and every change demands a simultaneous three-way release, the service count hasn't enabled independent evolution — it has increased protocol-change and release-coordination overhead. Pulling related logic together can shrink the scope a single change spans.

However, "changes together" needs diagnosis. Sometimes the domain boundary was drawn wrong; sometimes the interface simply lacked a compatibility strategy. The latter may not require process merging — adding a compatibility window or changing release order might solve the main problem. Blaming all coordination cost on microservices skips smaller fixes.

Therefore, evaluation should pick one real change and one real environment delivery, count the services that must collaborate, the steps that must wait, and the dependencies that must be co-debugged during failures. The total service count alone cannot answer these questions.

After the Merge: Which Failures Now Happen Together

Process boundaries are not free complexity. An independent service can have its own memory limit and restart cycle; once merged, a memory leak, crash, or long pause in one module can affect modules that were previously isolated. Reducing network failures changes the failure-propagation mode.

Module interfaces constrain code dependencies but do not inherently provide process-level resource isolation. If compute tasks regularly exhaust memory while the control plane must stay responsive, "code is modularized" is insufficient to justify safe merging. An alternative is to keep modules in the same codebase but deploy them as separate instances per runtime role, preserving necessary resource and fault boundaries.

There is also the tenant dimension. Turning shared services into per-tenant components may reduce the blast radius of a single failure, but increases the number of instances, upgrades, and capacity-management tasks; keeping a shared external metadata store retains a common dependency. Judging isolation requires looking at the final deployment topology, not inferring from the labels "monolith" or "microservices."

If a component truly has different scaling rhythms, independent release needs, or strong isolation requirements, keeping a process boundary has verifiable justification. Conversely, if several components have long been released together, share load patterns, and their main pain points are environment delivery and coordination, a more compact deployment is worth piloting.

Piloting the Change

A pilot need not start with a full-system merge. Select a group of clearly related components, preserve their interfaces and state ownership, then compare change cycle time, environment setup effort, tail latency, and failure recovery. Simultaneously test what happens when one module exhausts its resources — who else is affected? If the migration involves metadata schema changes, verify how old versions continue to read or roll back; keeping a single old install package is not a sufficient rollback plan.

Conclusion: Re-evaluating Every Process Boundary

Firebolt's refactor offers a chance to reframe the architectural review. Next time, take the hardest-to-deliver service group and explicitly list the independent capabilities each process boundary provides. Boundaries that prove isolation and independent-evolution value stay; boundaries that only prove a historical team division are the ones worth re-discussing.