[arch1e]

We already load all the documentation assets into memory whenever something changes. Even with large projects spanning hundreds of pages and page groups, it remains very fast—under 1 second in our testing.

That being said, there are some cases where a database is necessary. For example, handling multiple people editing the same document simultaneously wouldn’t work well with just flat files. Also, where would we store user emails/passwords for authentication? Another feature Kalmia supports is private documentation, where users need to log in to access certain docs (there's a simple toggle to enable authentication).

That said, adding an "export to zip" or "push to git" button is totally feasible, and it's something we've had a lot of requests for. While we don't personally use it, we'll be adding it so people can host their docs on static file platforms without needing Kalmia as the backend.

[9dev]

The nice thing about flat files represented in memory would really be maximum performance, no external data store necessary, and easy portability. I definitely understand that sorting out concurrency by using a DBMS is easier, however.

> Also, where would we store user emails/passwords for authentication?

For this kind of application, I’d strongly recommend (and request from anything I buy) OAuth signin via my existing identity provider. That means I don’t have yet another location for accounts, and you don’t have to worry about storing them securely.