Fund flows between ~6,000 depositors and 1,000+ banks generate millions of new transaction records a month and hundreds of millions of rows in total. StoneCastle rebuilt the stack on MOI in two phases: an HTAP engine replacing MySQL, then natural-language querying on top.
StoneCastle, founded in 2003, is a U.S. financial services firm specializing in FDIC-insured cash deposit management. It helps clients distribute large deposits across a network of 1,000+ partner banks, ensuring every dollar is protected under the $250,000 FDIC insurance limit per institution. The firm manages over $170 billion for its clients.
StoneCastle's client accounting system tracks how depositor funds move across banks. It ran on self-managed MySQL on AWS EC2, and when the business expanded from institutional to individual depositors the data volume changed character.
The system records fund flows between N depositors and M banks: over 1,000 banks and roughly 6,000 depositors. That network adds several million transactions a month and has accumulated into the hundreds of millions of rows — a scale that MySQL struggled to query. To relieve the pressure, only one year of data was kept online and the rest archived, which eased the primary database but made historical query and analysis awkward. As growth accelerated, the retention window could only get shorter.
The queries themselves are aggregate analyses for internal and external users, and they matter: accurate financial reporting, transaction monitoring, decision support. Under MySQL, queries involving heavy aggregation, multi-table joins and complex computation stretched out badly — a summary report across accounts and periods, or a financial trend analysis, could take fifteen minutes or more. A representative slow query grouping transactions by client, client account, bank and bank account took over ten minutes at ten-million-row scale.
MatrixOne is an HTAP database with high MySQL protocol compatibility, which addresses both the data-volume and the query-performance side of the problem.
Where MySQL is suited to OLTP, MatrixOne combines transactional and analytical processing, handling large volumes of real-time transaction data while supporting complex query and analysis. Transactional performance was preserved while aggregation and multi-table join queries dropped from 10–30 minutes to 5–10 seconds — which in turn widens how many years of data can stay online and queryable, rather than being capped by what the engine can scan.
MatrixOne supports private deployment on cloud servers with one-click deployment and operations tooling, meeting the customer's data security requirements, and a primary-standby log replication architecture provides availability equivalent to what they had.
Compatibility covers connection protocol, SQL syntax and application ORM frameworks, so engineers migrated using familiar tools and statements — the application required essentially no modification. To keep the cutover safe, MatrixOne read MySQL binlog to synchronize data and both systems ran in parallel for a period before the switch.
Query time fell sharply, decision cycles shortened, and the volume of data the online system can carry increased — so users reach further back in history, and the platform can take on more clients without hitting the same wall.
The underlying pattern is common across financial services: as data volumes grow, a database has to serve both day-to-day online transactions and increasingly heavy analytical work — real-time risk assessment, transaction monitoring, BI reporting, visualization, large-scale analysis. Those are exactly where a traditional MySQL architecture reaches its limits.