ERPNext Just Proved It Can Handle Enterprise-Scale Data
One of the questions we hear most from growing SMEs weighing up ERPNext is some version of: "will this still work once we're bigger?" It's a fair question - nobody wants to migrate systems twice. Frappe's engineering team just published a case study that answers it in pretty convincing fashion, and it's worth walking through.
The problem: a report that stopped completing
A fintech customer running ERPNext was posting between 800,000 and 1 million ledger entries a day. By the time they'd accumulated around 300 million General Ledger entries, their Trial Balance report - one of the most basic and heavily used reports in any accounting system - simply stopped finishing. Not slow. Not finishing (Kumar, 2026).
The root cause is a familiar one in database engineering. ERPNext, like most business systems, runs on MariaDB, a row-based database built for transactional work: creating invoices, posting payments, updating stock. That's called OLTP - online transaction processing - and it's exactly the right tool for day-to-day operations. But asking a row-based OLTP database to aggregate and summarise hundreds of millions of rows for a report is a different kind of workload entirely, and it starts to buckle under that kind of volume (Kumar, 2026).
The fix: give reporting its own engine
Rather than trying to force more performance out of MariaDB, Frappe's engineers brought in DuckDB - an open-source, column-oriented database purpose-built for exactly this kind of analytical workload (MotherDuck, n.d.). Where MariaDB stores and reads data row by row, DuckDB stores it by column, which means a report that only needs to sum up a handful of fields doesn't have to plough through every field in every row to get there (MotherDuck, n.d.).
The team built what they call a "DuckDB Sync" doctype - a mechanism that replicates ERPNext's schema and syncs data snapshots into DuckDB, so financial reports can switch their source of truth between MariaDB and DuckDB with a simple toggle (Kumar, 2026). MariaDB stays exactly where it is for day-to-day transactions; DuckDB just takes over for the heavy reporting.
The results speak for themselves:
| Metric | MariaDB | DuckDB |
|---|---|---|
| GL entries | 700 million | 700 million |
| Storage size | 314 GB | 71 GB |
| Trial Balance runtime | Never completed | 2 minutes |
Same data, a quarter of the storage footprint, and a report that used to hang indefinitely now returns in two minutes (Kumar, 2026).
By pairing ERPNext's transactional database with a purpose-built analytical engine, reports that previously never completed now run in minutes - at more than double the data volume the original bottleneck appeared at (Kumar, 2026).
Why this matters beyond one fintech company
It's tempting to read this as a story about a single large customer with an unusual amount of data. That's missing the point. What it actually demonstrates is that ERPNext's architecture can be extended to handle enterprise-grade transaction volumes without a rip-and-replace migration to a different platform - the fix was an addition to the existing system, not a rebuild of it (Kumar, 2026).
That headroom matters more than it might seem for a smaller business today. ERPNext's own user base skews heavily toward smaller organisations: 61% of companies running it have fewer than 50 employees, and 81% generate under USD 50 million in annual revenue (Enlyft, 2026). Most SMEs adopting ERPNext will never come close to 300 million ledger entries. But knowing the platform has already been proven at that scale - and that scaling it further doesn't mean starting over - is exactly the kind of reassurance worth having before you commit years of financial data to a system.
What this means if you're evaluating ERPNext for your business
You don't need DuckDB on day one, and most SMEs won't need it for years, if ever. But the story is a useful data point in a broader evaluation: open-source ERP platforms are sometimes assumed to hit a ceiling that proprietary enterprise systems don't. This case study is a concrete example of that ceiling being pushed back, in production, for a real customer - not a benchmark run in a lab.
- If you're currently on spreadsheets or a lightweight accounting tool, this isn't a reason to over-engineer your first ERP rollout - start with the modules you need now.
- If you're already on ERPNext and reports are starting to slow down as your transaction volume grows, this is a sign there's a documented, production-tested path forward rather than a forced migration.
- Singapore SMEs adopting ERP or accounting systems can typically offset part of the implementation cost through the SMEs Go Digital grant, which covers up to 50% of eligible costs (30% for non-SMEs), capped at S$30,000 per company per financial year (Grants.sg, n.d.) - worth checking before you budget a project.
Weighing up ERPNext against other systems, or planning an implementation? We help Singapore SMEs scope, implement and grow into ERPNext without overbuilding on day one. Let's talk through what your setup should actually look like.
References
- Enlyft (2026) Companies using ERPNext. Available at: https://enlyft.com/tech/products/erpnext (Accessed: 12 September 2026).
- Grants.sg (n.d.) SMEs Go Digital. Available at: https://grants.sg/grants/smes-go-digital (Accessed: 12 September 2026).
- Kumar, R. (2026) Half a billion ledger entries. Frappe Blog, 3 September. Available at: https://frappe.io/blog/engineering/half-a-billion-ledger-entries (Accessed: 12 September 2026).
- MotherDuck (n.d.) What is DuckDB? Available at: https://motherduck.com/learn/what-is-duckdb/ (Accessed: 12 September 2026).