Using JSON file and in-memory cache since we have so little config info to keep track of - can only have a single worker at a time unless we read from JSON file every time to prevent workers having different in-memory caches (might be a decent stop gap, but is not great).
Goal
A data persistence layer that:
1) is simple to set up, especially when self-hosted.
2) Doesn't over complicate our needs.
3) Is flexible as we add more features.
4) Is easily backed up.
5) Is fast af.
Current best suggestion is to use SQLite (flexible, fast af 🏃, good for self-hosted, everything can interact with SQL) + Litestream (backups & resiliency). It's good enough for `n8n, and they do a lot more!
Current state
Using JSON file and in-memory cache since we have so little config info to keep track of - can only have a single worker at a time unless we read from JSON file every time to prevent workers having different in-memory caches (might be a decent stop gap, but is not great).
Goal
A data persistence layer that: 1) is simple to set up, especially when self-hosted. 2) Doesn't over complicate our needs. 3) Is flexible as we add more features. 4) Is easily backed up. 5) Is fast af.
Current best suggestion is to use SQLite (flexible, fast af 🏃, good for self-hosted, everything can interact with SQL) + Litestream (backups & resiliency). It's good enough for `n8n, and they do a lot more!