You're right. Since I use SQLAlchemy, the core is already database agnostic. Swapping the connection string to Postgres actually works for most features right now.

I listed it as "Roadmap" only because I haven't finished the full end-to-end test suite for Postgres yet, and I wanted the default "Quick Start" to be a zero dependency SQLite setup. I am also working on native read/write splitting so that the system can properly leverage scaling architectures (like Amazon Aurora's single-writer / multi-reader clusters) out of the box.

I'll make sure to clarify in the docs that it's currently "experimental" rather than missing. Appreciate the feedback!

Honestly, I picked AGPL mainly to prevent "cloud wrapping". I definitely don't intend for your business logic to get infected by it.

In my view, the custom hooks and schemas are "content/configuration" rather than derivative works, but I get that running in-process makes that legally murky.

To clear that up, I'll add a specific linking exception (like the Classpath Exception) to explicitly exempt user-defined hooks from the license. I want this to be safe for commercial teams to self-host, just not safe for cloud providers to resell.

Keybase's Merkle approach is elegant for their use case (efficient proofs without revealing the full chain), but I went simpler with a linear chain because:

1. Audit trails are inherently sequential - they're ordered by time and typically read/written in order. Merkle trees shine for unordered data where you need efficient inclusion proofs. 2. Verification simplicity - with a linear chain, integrity verification is just "walk the sequence and check that each entry's previous_hash matches the prior entry's checksum." O(n) and dead simple. 3. Storage efficiency - each entry stores two SHA-256 hashes as strings. No tree overhead. 4. Regulatory fit - for GxP/CFR Part 11 compliance, the requirement is tamper detection, not zero-knowledge proofs. A linear chain detects any modification equally well.

That said, if I ever need selective verification (prove entry #500 is valid without transmitting the full chain), I'd revisit Merkle. The implementation is in src/snackbase/infrastructure/persistence/repositories/audit_log_repository.py if you're curious.

On the custom DSL: This was the biggest architectural decision in SnackBase. Here's the honest breakdown:

Why not just use existing options? >Approach: Python eval() >>Why I didn't choose it: Security nightmare - can't safely let users store arbitrary code in the database

>Approach: CEL (Google's Common Expression Language) >>Why I didn't choose it: Battle-tested, but heavy dependency and less control over semantics

>Approach: JEXL/JSONLogic >>Why I didn't choose it: Another runtime to learn, harder to integrate with my macro system

>Approach: Pure JSON rules >>Why I didn't choose it: Becomes unreadable for complex expressions

What drove the decision:

1. Permissions are database-storable - rules live as strings in the permissions table, editable via API and admin UI. I needed something safe to parse and evaluate at runtime. 2. Sandboxed execution - the DSL only exposes specific operations (==, in, @has_role(), etc.). No imports, no file access, no arbitrary code. Even if someone compromises the admin UI, they can only express logic within the vocabulary I provide. 3. Syntax for non-programmers - "@has_role('admin') and @owns_record()" is more approachable than Python lambdas when you're building permissions in a web UI. 4. Macro integration - the @ prefix ties into my SQL macro system, letting users define reusable business logic like @is_department_head() that executes database queries.

The trade-off:

It's 700+ lines of lexer/parser/evaluator code I have to maintain. Every edge case (null handling, type coercion, short-circuit evaluation) needs explicit test coverage. Debugging a failed rule means returning syntax errors at position X rather than a stack trace.

If I were starting fresh today, I'd give CEL harder consideration. But since permissions are a core differentiator for SnackBase, having full control over the semantics has been worth it—especially for field-level access control and the wildcard collection system.

Implementation files if you're interested in it: - src/snackbase/core/rules/lexer.py - tokenizer - src/snackbase/core/rules/parser.py - recursive descent → AST - src/snackbase/core/rules/evaluator.py - async evaluation with short-circuiting

Happy to go deeper on any of this!

I think every developer has a story about spending months on those exact features. Organizations, RBAC, Auth, etc. before they ever get to write a single line of code for the actual business problem they were trying to solve.

Since you are coming from plain Flask, you would likely find the SnackBase architecture very familiar. I chose FastAPI and Pydantic specifically to give that same "get out of my way" developer experience, but with the compliance-first features (like the immutable audit logs) baked into the core so you don't have to think about them.

If you ever have a chance to play with the demo or the repo, I’d love to know if there are any specific missing pieces from your Flask implementation that you think should be in SnackBase.

For SnackBase, I actually spent the majority of my time on the architecture and compliance logic rather than just generating boilerplate.

Compliance Core> Getting the immutable hash-chain for audit logs to work correctly with async SQLAlchemy while ensuring it doesn't kill database performance is something I had to iterate on manually. AI is great at writing a function, but it's notoriously bad at keeping a consistent "Clean Architecture" across hundreds of files without a human steering the ship.

Custom DSL> I built the DSL specifically to solve the maintenance problem you mentioned. It acts as a single source of truth for the DB, API, and UI. This makes the project much easier to maintain long-term because you aren't manually updating three different layers every time a schema changes.

I built this because I actually need it for my work in Life sciences domain. My goal isn't a blast of commits but a rock-solid foundation that can survive a GxP audit.

That's actually just a standard component from Mintlify, which I'm using for the documentation. It’s a very popular framework for dev tools right now, so a lot of sites end up sharing the same standard icon set like "Zap" icon in this case.

I promise I’m much more focused on the "Compliance & Python Hooks" logic under the hood than icon design. I'm glad to hear the documentation looks professional, though Mintlify really does a lot of the heavy lifting there!