Proposal: Architecture for a Pluggable Database Backend (SQLite, Postgres, etc.)

[mcexit]

Proposal: Architecture for a Pluggable Database Backend (SQLite, Postgres, etc.)

Bruno’s current "collections-as-code" architecture maps every request directly to the file system. While this design is excellent for Git-based workflows, imposing the file system as the only storage layer creates specific limitations regarding performance, OS constraints, and future scalability for real-time collaboration.

I propose introducing an optional Database Storage Layer. While SQLite would likely be the primary target for local users (solving immediate file system issues), this architecture would pave the way for other backends (PostgreSQL, MySQL, libSQL) to support multi-user environments.

The Current Challenges (File System Mode)

1. OS & File System Constraints:

   • NTFS Limits: Windows path limits frequently block deep nesting or descriptive request names
   • Filename Restrictions: Operating systems & cloud storage providers prohibit certain characters in filenames. This forces Bruno to sanitize names or may limit names for workspaces, collections, folders, etc.
   • Inode & Object Limits: Storing potentially thousands of small files is inefficient and will consume "object count" quotas on cloud storage
   • Sync Friction: Syncing metadata for thousands of tiny files is significantly slower and more error-prone than syncing a single database file via delta-sync.

2. Performance:

   • Loading large workspaces involves thousands of I/O read operations, causing visible UI lag. Database indexing would make querying and filtering requests instantaneous.

The Proposal: Pluggable Storage Backends

Bruno could support mounting a workspace from a database connection string rather than just a folder path.

1. The Local Solution: SQLite

   • Benefits: Portable, single-file backup, instant loading, no "invalid filename" character restrictions, and efficient cloud syncing (more & more modern cloud agents handle single-file delta syncs).

   For individual users, the entire workspace lives in a single local .brudb or .db file.

2. The Collaborative Solution: SQL Backends (Postgres / MySQL / libSQL)

   By abstracting the storage layer, Bruno opens the door for:

   • True Multi-User Support: Multiple users connecting to a centralized Postgres or other client-server DB.
   • Concurrency: Databases natively handle locking and concurrent edits better than file system watchers.
   • Granular Permissions: Moving beyond file-system permissions to implement Role-Based Access Control (RBAC) at the row/table level.
   • Distributed Options: Technologies like rqlite or libSQL could offer a middle ground—local-feel with distributed syncing capabilities.

Open Source vs. Paid Strategy

This architecture aligns perfectly with a sustainable open-core model:

• OSS Core: Support for File System (Git) and Local SQLite is available to everyone. This ensures the best possible local developer experience.
• Paid/Enterprise: Support for Remote Backends (Postgres, MySQL) or a managed Sync Server becomes a clear value add for teams requiring real-time collaboration, centralized RBAC, and audit logging.

Summary

I believe moving to a database-agnostic storage layer allows Bruno to lay the foundation for a "Postman-killer" feature set.