|
| 1 | +--- |
| 2 | +title: 'SPEC-7: POC to spike Tigris/Turso for local access to cloud data' |
| 3 | +type: spec |
| 4 | +permalink: specs/spec-7-poc-tigris-turso-local-access-cloud-data |
| 5 | +tags: |
| 6 | +- poc |
| 7 | +- tigris |
| 8 | +- turso |
| 9 | +- cloud-storage |
| 10 | +- architecture |
| 11 | +- proof-of-concept |
| 12 | +--- |
| 13 | + |
| 14 | +# SPEC-7: POC to spike Tigris/Turso for local access to cloud data |
| 15 | + |
| 16 | +## Why |
| 17 | + |
| 18 | +Current basic-memory-cloud architecture uses Fly volumes for tenant file storage, which creates several limitations: |
| 19 | + |
| 20 | +1. **Storage Scalability**: Fly volumes require pre-provisioning and don't auto-scale with usage |
| 21 | +2. **Cost Model**: Volume pricing vs object storage pricing may be less favorable at scale |
| 22 | +3. **Local Development**: No way for users to mount their cloud tenant files locally for real-time editing |
| 23 | +4. **Multi-Region**: Volumes are region-locked, limiting global deployment flexibility |
| 24 | +5. **Backup/Disaster Recovery**: Object storage provides better durability and replication options |
| 25 | + |
| 26 | +The core insight is that Basic Memory requires POSIX filesystem semantics but could benefit from object storage durability and accessibility. By combining: |
| 27 | +- **Tigris object storage** for file persistence (via rclone mount) |
| 28 | +- **Turso/libSQL** for SQLite indexing (replacing local .db files) |
| 29 | + |
| 30 | +We could enable a revolutionary user experience: **local editing of cloud-stored files** while maintaining Basic Memory's existing filesystem assumptions. |
| 31 | + |
| 32 | +## What |
| 33 | + |
| 34 | +This specification defines a proof-of-concept to validate the technical feasibility of the Tigris/Turso architecture for basic-memory-cloud tenants. |
| 35 | + |
| 36 | +**Affected Areas:** |
| 37 | +- **Storage Architecture**: Replace Fly volumes with Tigris object storage |
| 38 | +- **Database Architecture**: Replace local SQLite with Turso remote database |
| 39 | +- **Container Setup**: Add rclone mounting in tenant containers |
| 40 | +- **Local Development**: Enable local mounting of cloud tenant data |
| 41 | +- **Basic Memory Core**: Validate unchanged operation over mounted filesystems |
| 42 | + |
| 43 | +**Key Components:** |
| 44 | +- **Tigris Storage**: S3-compatible object storage via Fly.io integration |
| 45 | +- **rclone NFS Mount**: Native NFS mounting without FUSE dependencies |
| 46 | +- **Turso Database**: Hosted libSQL for SQLite replacement |
| 47 | +- **Single-Tenant Model**: One bucket + one database per tenant (simplified isolation) |
| 48 | + |
| 49 | +## How (High Level) |
| 50 | + |
| 51 | +### Phase 1: Local POC Validation |
| 52 | +- [ ] Set up Tigris bucket with test data |
| 53 | +- [ ] Configure rclone NFS mount locally |
| 54 | +- [ ] Test Basic Memory operations over mounted filesystem |
| 55 | +- [ ] Measure performance characteristics and identify issues |
| 56 | +- [ ] Validate file watching, sync operations, and concurrent access patterns |
| 57 | + |
| 58 | +### Phase 2: Database Migration |
| 59 | +- [ ] Set up Turso account and test database |
| 60 | +- [ ] Modify Basic Memory to accept external DATABASE_URL |
| 61 | +- [ ] Test all operations with remote SQLite via Turso |
| 62 | +- [ ] Validate performance and functionality parity |
| 63 | + |
| 64 | +### Phase 3: Container Integration |
| 65 | +- [ ] Create container image with rclone + NFS support |
| 66 | +- [ ] Implement tenant-specific credential management |
| 67 | +- [ ] Test container startup with automatic mounting |
| 68 | +- [ ] Validate isolation between tenant containers |
| 69 | + |
| 70 | +### Phase 4: Local Access Validation |
| 71 | +- [ ] Test local rclone mounting of tenant data |
| 72 | +- [ ] Validate real-time file editing experience |
| 73 | +- [ ] Test conflict resolution and sync behavior |
| 74 | +- [ ] Measure latency impact on user experience |
| 75 | + |
| 76 | +### Architecture Overview |
| 77 | +``` |
| 78 | +Local Development: |
| 79 | +┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ |
| 80 | +│ Local rclone │───▶│ Tigris Bucket │◀───│ Tenant Container│ |
| 81 | +│ NFS Mount │ │ (S3 storage) │ │ rclone mount │ |
| 82 | +└─────────────────┘ └─────────────────┘ └─────────────────┘ |
| 83 | + │ │ |
| 84 | + ▼ ▼ |
| 85 | +┌─────────────────┐ ┌─────────────────┐ |
| 86 | +│ Basic Memory │ │ Basic Memory │ |
| 87 | +│ (local files) │ │ (mounted files) │ |
| 88 | +└─────────────────┘ └─────────────────┘ |
| 89 | + │ │ |
| 90 | + ▼ ▼ |
| 91 | +┌─────────────────┐ ┌─────────────────┐ |
| 92 | +│ Turso Database │◀───────────────────────────│ Turso Database │ |
| 93 | +│ (shared index) │ │ (shared index) │ |
| 94 | +└─────────────────┘ └─────────────────┘ |
| 95 | +``` |
| 96 | + |
| 97 | +## How to Evaluate |
| 98 | + |
| 99 | +### Success Criteria |
| 100 | +- [ ] **Filesystem Compatibility**: Basic Memory operates without modification over rclone-mounted Tigris storage |
| 101 | +- [ ] **Performance Acceptable**: File operations complete within 2x local filesystem latency |
| 102 | +- [ ] **Database Functionality**: All Basic Memory features work with Turso remote SQLite |
| 103 | +- [ ] **Container Reliability**: Tenant containers start successfully with automatic mounting |
| 104 | +- [ ] **Local Access**: Users can mount and edit cloud files locally with real-time sync |
| 105 | +- [ ] **Data Isolation**: Tenant data remains properly isolated using bucket/database separation |
| 106 | + |
| 107 | +### Testing Procedure |
| 108 | +1. **Local Filesystem Test**: |
| 109 | + ```bash |
| 110 | + # Mount Tigris bucket locally |
| 111 | + rclone nfsmount tigris:test-bucket ~/tigris-test --vfs-cache-mode writes |
| 112 | + |
| 113 | + # Run Basic Memory operations |
| 114 | + cd ~/tigris-test && basic-memory sync --watch |
| 115 | + # Test: create notes, search, file watching, bulk operations |
| 116 | + ``` |
| 117 | + |
| 118 | +2. **Database Migration Test**: |
| 119 | + ```bash |
| 120 | + # Configure Turso connection |
| 121 | + export DATABASE_URL="libsql://test-db.turso.io?authToken=..." |
| 122 | + |
| 123 | + # Test all MCP tools with remote database |
| 124 | + basic-memory tools # Test each tool functionality |
| 125 | + ``` |
| 126 | + |
| 127 | +3. **Container Integration Test**: |
| 128 | + ```dockerfile |
| 129 | + # Test container with rclone mounting |
| 130 | + FROM python:3.12 |
| 131 | + RUN apt-get update && apt-get install -y rclone nfs-common |
| 132 | + # ... test startup and mounting process |
| 133 | + ``` |
| 134 | + |
| 135 | +4. **Performance Benchmarking**: |
| 136 | + - File creation/read/write operations (target: <2x local latency) |
| 137 | + - Search query performance (target: comparable to local SQLite) |
| 138 | + - File watching responsiveness (target: events within 1-2 seconds) |
| 139 | + - Concurrent operation handling |
| 140 | + |
| 141 | +### Risk Assessment |
| 142 | +**High Risk Items**: |
| 143 | +- [ ] NFS-over-S3 performance may be insufficient for real-time operations |
| 144 | +- [ ] File watching (`inotify`) over NFS may be unreliable |
| 145 | +- [ ] Network interruptions could cause filesystem errors |
| 146 | +- [ ] Concurrent access patterns might hit S3 rate limits |
| 147 | + |
| 148 | +**Mitigation Strategies**: |
| 149 | +- Comprehensive performance testing before committing to architecture |
| 150 | +- Fallback plan to S3-native storage backend if filesystem approach fails |
| 151 | +- Extensive error handling and retry logic for network issues |
| 152 | + |
| 153 | +### Metrics to Track |
| 154 | +- **Latency**: File operation response times (read/write/watch) |
| 155 | +- **Reliability**: Success rate of file operations over time |
| 156 | +- **Throughput**: Concurrent file operations and search queries |
| 157 | +- **User Experience**: Perceived performance for local mounting use case |
| 158 | + |
| 159 | +## Notes |
| 160 | + |
| 161 | +### Key Architectural Decisions |
| 162 | +- **Single tenant per bucket/database**: Simplifies isolation and credential management |
| 163 | +- **Maintain POSIX compatibility**: Preserve Basic Memory's existing filesystem assumptions |
| 164 | +- **NFS over FUSE**: Better compatibility and performance characteristics |
| 165 | +- **Turso for SQLite**: Leverages specialized remote SQLite expertise |
| 166 | + |
| 167 | +### Alternative Approaches Considered |
| 168 | +- **S3-native storage backend**: Would require Basic Memory architecture changes |
| 169 | +- **Hybrid approach**: Local files + cloud sync (adds complexity) |
| 170 | +- **FUSE mounting**: More platform dependencies and kernel requirements |
| 171 | + |
| 172 | +### Integration Points |
| 173 | +- [ ] Fly.io Tigris integration for bucket provisioning |
| 174 | +- [ ] Turso account setup and database provisioning |
| 175 | +- [ ] Container image modifications for rclone support |
| 176 | +- [ ] Credential management for tenant isolation |
| 177 | + |
| 178 | +## Observations |
| 179 | + |
| 180 | +- [architecture] Tigris/Turso split cleanly separates file storage from indexing concerns #storage-separation |
| 181 | +- [user-experience] Local mounting of cloud files could be revolutionary for knowledge management #local-cloud-hybrid |
| 182 | +- [compatibility] Maintaining POSIX filesystem assumptions preserves Basic Memory's local/cloud compatibility #architecture-preservation |
| 183 | +- [simplification] Single tenant per bucket eliminates complex multi-tenancy in storage layer #tenant-isolation |
| 184 | +- [risk] NFS-over-S3 performance characteristics are unproven for real-time operations #performance-risk |
| 185 | +- [benefit] Object storage pricing model could be more favorable than volume pricing #cost-optimization |
| 186 | +- [innovation] Real-time local editing of cloud-stored files addresses major SaaS limitation #competitive-advantage |
| 187 | + |
| 188 | +## Relations |
| 189 | + |
| 190 | +- implements [[SPEC-6 Explicit Project Parameter Architecture]] |
| 191 | +- requires [[Fly.io Tigris Integration]] |
| 192 | +- enables [[Local Cloud File Access]] |
| 193 | +- alternative_to [[Fly Volume Storage]] |
0 commit comments