Author – Sameer Shaikh

If you’ve ever run a General Ledger or Trial Balance for a client with years of transaction history, you probably know the routine.

Set the date → Click Generate Report → Wait… → Wait some more.

For businesses with hundreds of thousands or even millions of GL entries, that wait can get frustrating. Sometimes, the report may even time out.

At Frappeverse 2026, the Frappe core team shared how ERPNext v16 is approaching this problem.

And the answer wasn’t simply to throw more resources at the server.

It was DuckDB.

Why Does This Happen?

ERPNext primarily uses MariaDB, a row-oriented relational database. It works well for the everyday work an ERP needs to handle:

• Sales Invoices
• Purchase Orders
• Stock Transactions
• Payments
• Customer & Supplier records

But a General Ledger works differently.

When you run a GL for a business with years of transaction history, the system may need to go through hundreds of thousands or even millions of entries, filter them, group them and perform calculations on them.

The same applies to Trial Balance, where accounting data needs to be brought together for a particular period.

And when multiple companies are involved, a Consolidated Trial Balance can mean even more data to process.

As the business grows, these reports have more and more data to work through.

At some point, adding more indexes or increasing server resources may not be enough. The workload itself is different.

You’re asking a transactional database to handle a lot of analytical work.

That’s the problem ERPNext v16 is looking to address.

Why DuckDB Makes Sense Here

DuckDB is an open-source, column-oriented analytical database engine.

It is designed for workloads that involve things like:

• Aggregations
• Grouping
• Filtering large datasets
• Financial calculations
• Analytical reporting

The basic idea is quite simple:

MariaDB → Transactional workloads
DuckDB → Analytical workloads

DuckDB is also embedded, so it doesn’t require managing another traditional database server.

Frappe is already using DuckDB in areas such as Frappe Insights and the Datastore layer.

With ERPNext v16, this approach is coming closer to core ERPNext accounting reports.

Why General Ledger and Trial Balance?

Once you look at how these reports work, the choice makes sense.

• General Ledger

The GL keeps growing as transactions are posted.

A company that has been running ERPNext for several years can easily accumulate hundreds of thousands or millions of entries.

Every time someone runs the GL across a large date range, the system has a lot of history to process.

• Trial Balance

Trial Balance has a similar challenge.

It needs to aggregate accounting data across accounts for a specific period.

And with Consolidated Trial Balance, the workload can become even larger when multiple companies are involved.

That makes GL and Trial Balance two practical places to introduce an analytical engine.

Why Does This Matter for ERPNext Implementations?

For implementation teams, reporting performance isn’t just a technical issue.

Finance teams use GL and Trial Balance during:

• Month-end closing
• Audits
• Reconciliation
• Financial analysis
• Management reporting

If a report takes 30–40 seconds to load, users notice it.

If it times out, they notice that even more.

And when this keeps happening, people can start losing confidence in the system when they need it for important financial work.

So improving reporting performance isn’t only about making a report faster.

ERPNext also needs to keep up as the business and its data grow.

What Are We Watching in ERPNext v16?

There are a few practical questions that are worth watching as this develops.

1. Sync Frequency

How quickly will DuckDB reflect newly posted GL entries?

2. Self-Hosted Impact

What additional CPU, RAM, and storage requirements will this introduce for smaller ERPNext installations?

3. Future Scope

Will this approach eventually expand to other heavy reports such as:

Accounts Receivable / Payable
Stock Ledger
Stock Balance
Other financial analytics

These are some of the areas that will be interesting to follow as ERPNext v16 develops.

If you’re also interested in what’s changing around payroll in V16, take a look at our article on India Payroll V16 and open-source payroll compliance in India.

My Take

For me, the important part isn’t just that ERPNext is using DuckDB.

It’s the thinking behind it.

Transactional workloads and analytical workloads don’t necessarily need to use the same database engine.

As ERPNext implementations grow from thousands to millions of transactions, that difference starts to matter.

If DuckDB can take some of the heavy reporting work away from the transactional database, it could make a real difference for businesses working with large volumes of data.

There are still things to watch: how often the data syncs, what this means for self-hosted setups, and whether the approach eventually makes its way into other heavy reports.

But that’s exactly what makes ERPNext v16 interesting to watch.

For teams working with large ERPNext databases, the real question is How much faster will those reports actually become?

One Question for ERPNext Users

If you’re working with a large ERPNext database, is the general ledger or trial balance already becoming a performance bottleneck for you?

We’d like to hear what you’re seeing in your implementations.

Looking to Get More From Your ERPNext Setup?

As your business grows, your ERPNext database grows with it. If reporting is becoming slow or you’re facing performance challenges, our team can help you look at the bigger picture from your ERPNext setup to reporting and database performance.

Want to talk about your ERPNext performance?

Talk to Our ERPNext Experts!

Don’t forget to follow us on LinkedIn!