docs(rfc): proposal to scope SQLite self-hosting - #1216
Conversation
Document the SQLite gap matrix and the options: invest in parity, scope it to packaging-only with Supabase recommended, or take a middle path. Recommend scoping short term and token persistence first if demand justifies it.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@macroscope-app review |
|
Manual reviews triggered for commit All prior checks · these links stay valid even if you push more commits. |
|
Review started; results will be posted as checks. |
ApprovabilityVerdict: Would Approve Macroscope's review found this PR approvable — This PR adds only a proposed RFC documenting SQLite limitations and possible future directions. It changes no executable code, configuration, deployment behavior, schema, or user-facing runtime behavior. Not approved because:
Enable approvability here. You can add or adjust custom eligibility rules. Learn more. |
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Summary
RFC for item 12 from the Reddit follow-up. A self-hoster reported SQLite was "extremely basic and lacking a lot of features." The code agrees: two tables, no token persistence, and a list of Supabase-only surfaces.
This RFC records the gap matrix and the options (invest in parity, scope to packaging-only with Supabase recommended, or a middle path), and recommends scoping short term plus fail-fast Docker startup, with token persistence as the first thing to add if demand justifies investment.
Testing
Summary by CodeRabbit