Problem
GTBank’s operations teams frequently need to run schema changes and batch data updates against production databases, especially during migrations and reconciliations. Each request typically routed through the engineering team, who ran the SQL by hand. Engineers became a bottleneck for routine operations they were over-qualified to perform, and ad-hoc SQL is error-prone.
The Finacle core-banking migration was about to multiply this load by 10×. We needed a way for non-technical operators to run safe, repeatable database operations without writing SQL.
Approach
Built an internal Streamlit tool that wraps every database operation behind a config-driven UI.
- Configuration as data. Every operation is a JSON config. Schema change, batch update, post-deployment script: all expressed declaratively. Non-engineers fill out a form; the tool generates the SQL.
- Vectorised mapping engine. For the Finacle migration, a pandas-based mapping engine handled CIF and account translation across 4M+ records using vectorised lookups instead of row-by-row updates.
- Dynamic CASE-based SQL. Generated update statements use
CASE WHENblocks to apply per-row mappings in a single transaction, avoiding N+1 query problems. - Transaction-safe execution. Every operation runs in a transaction with rollback on any per-row failure. No partial state.
- Audit log. Every run captures the operator, the config, the affected rows, and the outcome. Compliance can reconstruct any change.
- Real-time progress visualisation. Streamlit progress bars and row counters give operators visibility into long-running operations.
Architecture
Every operation is expressed as a JSON config, rendered as a form in Streamlit, compiled to a single transactional SQL block, executed in one transaction with rollback on any per-row failure, then captured in an audit log compliance can read back. New operation types are added by writing a new JSON schema, not by writing code.
What it shipped
The tool was the safety net at cutover. The hundreds of scripts that ran against production all flowed through this one interface, every one of them transactional, auditable, and operator-driven. Engineering was off the critical path.
Reflections
- Config-driven UIs are a force-multiplier for ops teams. Once the JSON schema was solid, every new operation was a config file, not a code change.
- Transactions, plus vectorised pandas, plus dynamic CASE SQL beat orchestrating thousands of small queries. The single-transaction-per-run pattern made rollback trivial and let me reason about correctness one config at a time.
- Streamlit was the right call for an internal-only tool with a team of 5-10 daily users. A full SPA would have been overkill; raw SQL would have been frustrating and unsafe.
- The audit log was a quiet hero. Once compliance saw they could reconstruct any change, the tool moved from “thing the engineer built” to “trusted operations surface.”