ERPNext, HRMS & Frappe Framework v16 Release Dates

Announcements
, , ,
1

We are excited to share the official release dates for Version 16 of ERPNext, Frappe HRMS, and the Frappe Framework.

:test_tube: Beta Release: 15th November 2025

:rocket: Final Release: 6th December 2025 (at Frappeverse Egypt)

:sparkles: Feature Highlights

ERPNext

  • Customizable templates for financial statements

  • Inward subcontracting

  • MRP enhancements

  • Consolidated trial balance

  • Improved default print formats

  • Performance optimisation for accounting reports

  • Serial and batch traceability report

  • Landed cost for stock entries & subcontracting receipts

  • Stock reservation for subcontracting & production

  • Track semi-finished goods via Job Cards

  • POS improvements

  • Enhanced budgeting

  • Asset module refactoring

  • Refactored TDS

  • Stock accounting based on Item / Item Group

  • Separate COGS and Service expense accounting

HRMS

  • Overtime management

  • Arrears & loss-of-pay correction

  • Multi-currency expense claims

  • Employee benefits

  • Leave adjustments

  • Earned leave schedule

  • Holiday list enhancements

Frappe Framework

  • Completely redesigned Workspace (desktop, module cells, navigation)

  • ~2× faster performance

  • Enhanced List View: scrollable, resizable columns, unlimited fields, etc

  • Scrollable child tables with sticky columns

  • Custom print formats for reports

  • Role-based field masking

  • Chrome-based PDF converter

We invite all community members to explore the beta, try the new features, and share your feedback.
If you find any bugs, please create an issue in the respective GitHub repository.

Your feedback helps us ship the most stable and refined release possible :flexed_biceps:

Let’s make v16 the most stable and delightful release yet! :rocket:

98 Likes
3

Looking forward to the new look and feel of V16. Especially interested in the new chrome based PDF generator, Print formats for reports and the performance improvements.

2 Likes
4

Great news. Seams like this will be a huge one.

What does 2x speed really mean tho? I really only notice lag in reports, because Frappe Datatable is loading all the data all at once. So if it has 10k rows, it takes few minutes to generate the report. I wish there was a pagination for reports as well as there is for lists. Or at least server side caching. Its huge load for clients to generate after every filter update.

5

Check out Frappe’s PRs from the last year and a half, there you will find plenty of details about everything that has been optimized.

6

I am not aware of changes on 16. But I would like to know what is the memory available in your case ?

7

You’ll see on average a 2x speed up on most typical requests. It won’t address very specific things like a datatable architecture or some slowness attributable to a particular app’s design.

This was achieved by reducing overheads and speeding up all core utilities. E.g.

  1. Frequent Redis accesses are completely eliminated - Beating Redis with a Dictionary and Redis | Frappe Blog
  2. We use C library for the database connector instead of Python. This gives 3-5x speedup in DB query result parsing, especially on large data. Contributed by @snv feat: re-introduce `mysqlclient` 🚀 by sagarvora · Pull Request #31719 · frappe/frappe · GitHub
  3. Page rendering is faster by caching compiled templates.
  4. There’s an experimental no-fork worker type that gives ~5x-9x speed up when you have high-frequency background jobs. perf: Support running RQ worker without forking by ankush · Pull Request #31283 · frappe/frappe · GitHub
  5. We made threaded workers the default and found most multithreading bugs and addressed them. This allows Frappe deployments to be way more memory efficient by achieving concurrency using threads instead of processes. We run a forked version of gunicorn with multi-threading fixes specific to Frappe. GitHub - frappe/gunicorn: gunicorn 'Green Unicorn' is a WSGI HTTP Server for UNIX, fast clients and sleepy applications.
  6. There is a long, long tail of microoptimizations that fixed slowness in utility functions like…
    1. DB ORM functions - get_value/get_all (1.5x-3x), query builder (2x-5x), get_doc (7x), get_meta (180x).
    2. Page rendering (3x-5x)
    3. doc.save (2x)
    4. cache utils like site_cache (4x), redis_cache (30x)
    5. large SQL result sets (5x)
    6. date, data parsing utils now use C versions (2x-10x)
    7. Server script overheads (10x)
    8. Global search (O(n) → FTS)
    9. get_lazy_doc in internal functions, to not load entire document but load child tables on demand.
    10. background scheduler (2x)

Overall, there were ~200 PRs in Frappe + ERPNext + FC and nearly 100% of my time for ~4 months on this project :slight_smile:. The number 2x is validated with several benchmarks and load tests. You can find the code here: GitHub - frappe/caffeine: Performance Engineering @ Frappe

11 Likes
8

Thanks @ankush and frappe team for your great and hard dedicated work … we really do appreciate it … FOSS is the future :slight_smile:

1 Like
9

:grinning_face:Overall,get_lazy_doc in internal functions, to not load entire document but load child tables on demand.