Hi Radoslaw, thanks for your mail.
I would understand that if the developers say that they don't want to support SQLite because of the extra work it creates for them to support it. But this would be more or less the only reason I could accept ;-) SQLite is a good solution for an embedded RDBMS. If it just comes to some CRUD operation for a single application it is the easiest solution when it comes to maintenance and complexity of systems. You should know, that with each piece you add to your landscape, the complexity gains and the reliability as well as the availability goes down. So - SQLite is perfect here for me. It is just a library. No server which needs to be up and monitored for correct working. No configuration. Easy upgradeable. Of course in big installations which trillions of files and where performance really matters - SQLite is no alternative. In this environment, you probably have already an RDBMS sitting around which is activly monitored, and tweaked anyway. You will always use this instead of bringing another solution which does "the same" on-line. But in small installations, why would someone wants to setup and maintain a RDBMS for just a backup solution? When it comes to limits: https://www.sqlite.org/limits.html Of course there might be some SQL syntax which is not supported by SQLite - this could be a criteria. But let me tell you - if it is just "get the work done" and not caring about best performance - every SQL compatibily issue can be worked around. Says the since-2003-database-developer. I definitly like to have small units of systems with the least possible dependencies between each other. Performance together with bacula is not a matter for me. A Full-Backup of my Samba node handles 620k files with a Transfer rate of 66.89 MB/sec at a Image size of 1.874 TB. It takes around 7:47 hours for this backup. Running with SQLite. If it might speed up to 7 hours is not crucial for me. System simplicity is more important to me for a backup solution than performance. The while SQLite DB-file is 310MB in size. I just back this up instead of dumping the content and save the dump. This is also perfect in case of disaster recovery. You just need to get the DB file back and are back working in some seconds. No need to install and configure a RDBMS.... Just my two cents. I guess the decision is already made anyway and not open to discussion any more. I just wanted to state that I'm sad with this decision - but this is my problem ;) Best regards, Oliver _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
