Part 1 of 2: Solutions Engineering: Input & Insights
Solutions Engineering & the 3I Framework
Translating Business Pain into Technical Confidence
What a Solutions Engineer Actually Does
Ask ten people what a Solutions Engineer (SE) does, and you’ll get ten different answers. To sales, SEs are the technical wizards who make software feel like magic. To product teams, they’re the voice of customer reality. To clients, they’re trusted advisors who prevent costly architectural mistakes.
At its core, solution engineering isn’t about demos or slide decks, it’s about bridging the gap between a prospect’s real-world problems and technical capability. Nowhere is that bridge more critical than in a large-scale database migration, where a single dropped transaction or an unannounced maintenance window can quietly erode years of customer trust.
At OpenSource DB, we run every migration through the 3I Framework, Input/Information, Insight, Intelligence, the operating model that keeps customer experience (CX) at the center of even the most technically demanding migration. The SE owns the first two letters of that framework: Input and Insight. (Intelligence, the execution and assurance layer, is where the Technical Account Manager takes over, and that’s the subject of Part 2 of this series.)
We’ll walk through both using a real-world example, a regional digital wallet and merchant payment gateway that migrated its core ledger from a legacy commercial database to PostgreSQL.
Input: Capturing the Full Picture Before Touching a Single Table
Every strong migration begins with disciplined input-gathering, not just about the database, but about the business it serves. The SE leads this stage through technical discovery, treating the discovery call as a diagnostic session rather than a checklist.
Core discovery questions:
- Current Architecture & Sizing: “What’s the total DB size, TPS, and peak IOPS?”
- Downtime Tolerance: “Is this a near-zero-downtime CDC requirement or an offline migration?”
- Security & Compliance: “Do you have specific PII/PHI encryption requirements?”
Customer’s input signals
As transaction volume grew 300% year-over-year on a legacy commercial database, two failure modes surfaced, ballooning licensing costs consuming a disproportionate share of the engineering budget, and performance issues (unused indexes, lock contention during settlement runs, connection limits) causing payment timeouts during peak hours. The mandate that emerged from this input stage was unambiguous: migrate to PostgreSQL with zero data loss and near-zero downtime, without breaking CX SLAs.
Diagnosing the Starting Point: The Database Maturity Model
Input-gathering isn’t just about the next project, it’s about placing the customer accurately on OpenSource DB’s Database Maturity Model, the framework we use internally (and share with customers) to describe where a database practice stands today and where it needs to go.
| Stage | What it looks like |
| Stage 1: Reactive | Firefighting: manual backups, no proactive monitoring, downtime treated as inevitable, costs uncontrolled. |
| Stage 2: Stable | Monitoring, alerting, and DR policies exist, but capacity planning and performance work are still reactive. |
| Stage 3: Optimized | Proactive performance engineering: index hygiene, pooling, read/write splitting, query-level SLAs, visible cost/capacity. |
| Stage 4: Autonomous | Continuous automated verification and self-healing; database reliability becomes invisible to the business. |
The Customer walked in squarely at Stage 1.
Reactive: uncontrolled licensing costs, performance issues patched under pressure rather than engineered away, and no headroom left before the next traffic spike caused an outage. Naming the stage explicitly, rather than just listing symptoms, gives both the SE and the customer’s leadership a shared, non-technical vocabulary for how much ground the migration actually needs to cover.
Insights: Turning Technical Data into Customer-Centered Direction
Raw input only becomes valuable once it’s translated into insight. In fintech migrations, the critical insight is this: CX isn’t just UI/UX, it’s API latency, transaction idempotency, and system availability. The SE must architect the target environment backward from customer-facing SLAs, not forward from database convenience.
For Customer, this insights shaped three architectural decisions:
- Connection Pooling via PgBouncer, eliminating latency spikes from connection overhead during high concurrency by managing thousands of active microservice connections efficiently.
- Read/Write Splitting, routing high-volume reads (balance checks, transaction history) to multi-AZ read replicas, leaving the primary node dedicated to atomic writes.
- Log-based Change Data Capture (CDC), using Debezium/Kafka to replicate data in real time from the legacy system to PostgreSQL, avoiding a high-risk “big bang” cutover in favor of continuous sync.
Key management insights:
Technical managers often over-index on database-specific metrics (IOPS, CPU usage, replication lag). While necessary, leadership must anchor the migration on user-facing metrics, Payment Gateway Success Rate, P99 API Latency, and Merchant Checkout Drop-off Rate, because these are what customers actually experience.
Designing for the Target Stage, Not Just a Like-for-Like Swap
A common mistake in migrations is replatforming into an equivalent maturity stage, swapping one Reactive database for another, just cheaper. The insight stage is where the SE deliberately designs past that trap.
For Customer, the target architecture, pooled connections, split read/write paths, real-time CDC, was designed to land the customer directly at Stage 3, Optimized on day one, rather than a Stage 2 setup that would need a second overhaul in eighteen months. That distinction, designing for where the customer needs to be, not just where the legacy system was, is the difference between a migration and a fix.
The Handoff: Where SE Ends and TAM Begins
Once the SE completes discovery, resolves the open technical questions, and locks in the target architecture and maturity goal, the Technical Account Manager (TAM) takes ownership of the entire ongoing process. This isn’t a loose handover of notes, it’s a structured transfer of the baseline: the discovery findings, the architectural decisions, the customer-facing SLAs, and the maturity-stage target the whole engagement is now accountable to.
That handoff is where Input and Insight end and Intelligence begins, the automated systems, cross-functional coordination, and real-time verification that turn PayPulse’s design on paper into a migration its customers never notice happening.
In Part 2 of this series, we follow the TAM’s ownership of Intelligence, from shadow-read replay and automated reconciliation through a phased, feature-flagged cutover, and see PayPulse climb from Stage 3 to Stage 4 on the Database Maturity Model.