Question: Do you plan to support server-full databases?

[revolko]

As I understand it, ONCE makes it very easy to install/deploy web apps that use in-process database engines (e.g. SQLite). The installation of an app using Postgres is a bit more tricky -- the only way I can think of is running Postgres DB outside of the ONCE context and provide DATABASE_URL as env var to the application (after startup).

Question

Do you plan/would consider adding support for "managed" database? By "managed" I mean that ONCE runs a database server (just like it runs once-proxy instance), creates a new database and user for each application and injects database URL as env var (e.g. DATABASE_URL).

Don't take me wrong, I really like the way you handle the persistence layer -- quite elegant (I am working on the similar tool as ONCE and I did not think of SQLite as a solution to the persistence layer problem 😄 ). So I am just wondering what are you plans/thoughts in this regard.

[kevinmcconnell]

This is something we discussed a few times, and I'd like to spike it out to see how it feels. I do quite like the idea! The important thing would be to not lose the simple backup/restore/upgrade operations, and keeping the database maintenance-free. But I think there are a few ways to approach that. So, no firm plans, but it's on my list to investigate.

FWIW there's always the option of bundling PostgreSQL into the app container. It may be a bit unconventional, but it lets you keep everything packaged into a single container that always starts/stop/upgrades as an atomic unit. There's nothing to say a container shouldn't launch multiple supports processes, as long as the life-cycle of those can be tied back to the main process. Campfire runs Redis in its app container, for example (in its case that state is ephemeral, but still, the pattern is similar).