Easy migration from docker compose to LXC
Is your feature request related to a problem? Please describe.
I'm trying to move away from Docker Compose towards LXC for better performance, resource management, and integration with my Proxmox-based infrastructure. However, PartDB currently lacks official guidance or tooling for setting it up in an LXC container environment. This makes the migration more time-consuming and error-prone.
In addition, I’d like to switch from MySQL to PostgreSQL for better performance and scalability, but there’s no documented path or tool to assist with this database migration.
Describe the solution you'd like
I'd like to see official documentation or a migration guide for both:
-
LXC Deployment:
- System dependencies and packages required for LXC environments
- Configuration examples (e.g., using systemd or supervisord instead of Docker)
- Persistent storage and volume mapping instructions
- Networking recommendations (bridged, NAT, etc.)
- Security considerations
-
MySQL to PostgreSQL Migration:
- A supported migration path or script to convert MySQL databases used by PartDB into PostgreSQL-compatible format
- Compatibility information (e.g., any feature differences or config adjustments required)
- Update instructions for environment variables or settings within PartDB
Describe alternatives you've considered
- Manually reverse-engineering the Docker Compose setup to replicate it in LXC
- Running Docker inside LXC, which adds unnecessary complexity
- Using generic database migration tools like
pgloader, which may not handle all edge cases specific to PartDB's schema - Sticking with MySQL but losing out on PostgreSQL advantages
Additional context
Support for both LXC deployment and database backend migration would make PartDB more flexible and appealing to users with varied infrastructure preferences. This could also improve integration into enterprise or performance-sensitive environments.
Happy to contribute testing feedback or help validate LXC or PostgreSQL setups if community support or guidance is provided!
Also would really appreciate such a feature
Part-DBs data is completly contained in its database, the uploads and env variables. You just have to backup it on the first instance, and import/copy the data into the right place in the new instance: https://docs.part-db.de/usage/backup_restore.html
However you cannot use this to switch between different databases, as the SQL code is dependent on the database.
Would an export function that exports a zip file and imports the same not solve that issue? If the database is not directly exported as a SQL file, it would be decoupled from the database engine, no?
The only reason I am asking is that I would be willing to implement it myself via pull request, but I don't have the insights needed for structural planning.