Good point! We use a database (SQLite or Postgres) to enable more advanced features like versioning, collaboration, and access control, which aren't easily managed with static files alone. The database also allows us to scale better for teams with frequent updates.

While it does limit deployment to platforms like GitHub Pages, Kalmia is designed for teams that need more than just static documentation—think of it as a middle ground between static site generators and fully dynamic CMS solutions. For purely static sites, there are other great options out there, but Kalmia focuses on more interactive, collaborative documentation.

That said, we’re actually interested in providing an option for users to export and deploy it to platforms like GitHub Pages or similar, so stay tuned for future updates on that!

You could look into frontmatter to store metadata within the files, and just load it all into memory on startup. Even for huge projects, that probably won’t hurt anyway.

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.

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.