Hi Chris, Max and YY,
They use PostgreSQL as database backend, yet their employee can work on their datasets offline, and perform delayed, asynchronous replication of the data they worked on (as well as data changed at the central database instance) using bucardo.
Bucardo looks interesting. They’re planning an implementation for MySQL too.
However, talking zodb, thing do become hugely slow and unwieldy after some time, and the only way to get up to speed again in the zodb world was to implement relstorage (with PostgreSQL), where the Zope database “pickles” are stored in a PostgreSQL database. Means, you have an objct-oriented (zodb-like) database structure, but an SQL database backend that, however, cannot be queried in the usual SQL fashion.
Yes, we’re never going that road. What I meant was that we access
records in frappe using our objects from our ORM, so migration of code
to any other database system would be a little more standard.
I am after standards compliance, robustness, behaviour under heavy load and easy of replication and synchronisation. I think it is in these areas, where PostgreSQL really shines, and what I have seen over and over again in big data setups. So, why not going for a database backend that behaves well under heavy load, is highly scalable and loves SQL standards?
+1. Having used Postgres in the past, I agree that the pg tools are
great. Although MySQL was in middle of the shared hosting boom and has
also seen very large deployments even in companies like GitHub and
Facebook as Rushabh mentioned.
I come only offer a light, yes it is possible to support other databases thanks to the goal structure of frappe, and best of all, maintain compatibility with legacy code.
I really like Max’s approach to the issue. Removing the SQL string
building and replacing it with something like DAL seems like a good
idea. Parsing existing sql and converting it to Postgres’ SQL is also
I agree with Yang on the part that most required things right now are
in terms of developer tools, documentation being the most important
from his list.
For us, to switch the db for Frappe isn’t much of issue but the real
challenge is maintaining the erpnext project. In the recent past we
took the version 4 project which got a little extended and took a few
months to reach production. A dbstore migration project would more
surgical than this. I am not sure if we (at Web Notes) have the energy
at the moment to go for a long such break from shipping everyday.
In my opinion, maximum effort has to be made in improving the product
and increase adoption. That would also result in growth of the
developer community and then maybe would be the right time go for
something like what Django project did with database migrations,
At the moment, this is highest amount of interest ever expressed on
this issue. It is no doubt that Postgresql could be the database that