I am confused as why Frappe is going in the opposite direction and actively trying to add SQLite support. There’s no public ticket that describes why the requirements or use case for this would be. SQLite is single threaded but fast, so it should be able to support more than one concurrent user, but who knows how many. There are no load tests in the existing test suite.
1 Like
The intersection of businesses large enough to need an online/hosted ERP but small enough to be satisfied with a single threaded database is for practical purposes, zero.
Definitely, I can’t imagine wanting to run a full ERP on SQLite. But, as a framework, Frappe is quite useful for much more modest applications.
1 Like
Yes and I think that it could be a meaningful and adequate replacement for Redis and that licensing debacle, but still has less-than-ideal locking issues in that context.
General comment on influencing direction in open source projects (not limited to postgres)
Its been more than a decade since we have been running this project and we often see people complaining that they are unable to influence the direction of the project. Here is what they don’t get - influencing is a longer path. The goal should be to become a maintainer. They first have to make regular small contributions and help the existing maintainers. Then become part of the team that maintains. Be a good citizen, don’t break stuff, maitain the CI, help users. Then you get to have a say in the direction of the project
Yes you can say maintainers / Frappe should do this or that, but you don’t really know what every maintainer is doing. We have clearly said that it is really upto the maintainers to do what they think best. There are also several non-Frappe folks with maintainer rights - @snv, @revant_one @rmeyer
Then I see folks like @brian_pond @tmatteson who are very active, but choose not to help the maintainers and expect some kind of obligatory attention to their priorities. True, its open source and forking is always a good choice. Its sad though. Would have been great if they had chosen a different path.
3 Likes
Just a few corrections.
Well, I cannot speak for every person who has ever complained on these forums.
But I can speak for myself and @tmatteson. We definitely do “get it”. This is not the first time you’ve shared your requirements and thoughts about contributions. We are -definitely- aware of your positions on this matter, Rushabh. They have been crystal clear.
… and expect some kind of obligatory attention to their priorities
This is untrue. We certainly don’t -expect- anything from you or the maintainers. Believe me, if there’s one thing I’ve learned? It’s to not expect anything from the project and its stewards.
Certainly I have frequently expressed disagreement, disappointment, and dissent. However, I definitely do not expect my words to have any influence or impact. That is not one of my goals when writing them.
Its sad though. Would have been great if they had chosen a different path.
I do agree, this is very sad indeed. I wonder if they have reasons? 
3 Likes
Some of the problems with MariaDB actually stem from the pure-Python client we’ve been using.
With help from @ankush, I recently re-introduced mysqlclient. It is upto 4x faster in read queries.
We are expecting to make the switch in v16.
8 Likes
Thank you very much @snv
I am sure this will benefit many v15 ERPNext users who would have to wait till v16 is available.
@brian_pond in our experience of having many types of customers, we have yet to find a reason to maintain a fork. Almost all of our customers are on frappecloud and custom apps with monkey patching always works out. This avoids maintaining code.
Would like to know some insights from you on why the forks are needed. There maybe something in there for us to learn from.
2 Likes
I don’t think fork of frappe is available for installation on Frappecloud. postgres as db on Frappecloud may not be available.
99% don’t need it. Whoever needs it, now knows whom to connect to!
If someone is forking I don’t think they’re using frappecloud.
I assume whoever was ready for the hard fork had done everything that they could to avoid it.
3 Likes
Who here is deploying ERPNext on k8s?
Who hear is using the CloudNative PG operator for PostgreSQL?
The traction and performance of the postresql kubernetes operators is huge reason to use it over other SQL options. I prefer to only have a single SQL operator on my clusters; less overhead and complexity…
PostreSQL is best option all around IMHO. It can be used to simplify a stack significantly, especially if you leverage the advanced features and extensions.
To conclude,
ERPNext may not support postgresql. That’s why the hard fork happened.
this topic needs to be broken down in many other. Example:
- things to try before hard fork.
- why hard fork?
- rethink postgresql and frappe
- why postgres is better choice for FOSS DB over any other DB in general. Not related to frappe or erpnext.
- why mariadb is better choice for ERPNext.
Please open new relevant topics to organise discussions.
3 Likes