· Engineering Team ·
Engineering Architecture
Why We Chose a Single-Tenant SQLite Architecture for SaaS
The technical and privacy benefits of isolating agency data into separate SQLite files using Golang.
Building a B2B SaaS usually means spinning up a PostgreSQL cluster and defining Row-Level Security rules to keep one tenant from seeing another’s data.
For FeedbackFalcon, we went in a different direction.
The Database-Per-Tenant Model
Our Go backend manages hundreds of individual SQLite databases. When an agency signs up, they get their own isolated SQLite .db file on disk.
This approach solves three main problems:
- Data location: A coding error in our backend cannot accidentally leak Agency A’s bug reports to Agency B, because the datasets don’t share the same file or process space.
- The noisy neighbor problem: If one agency suddenly experiences a traffic spike resulting in 50,000 bug submissions, their SQLite file handles the queue independently. The rest of the platform isn’t affected.
- Economics: Hosting hundreds of flat files is much cheaper than maintaining a managed enterprise SQL cluster.
By minimizing our server costs through SQLite and Go, we can sustain flat-rate pricing without sacrificing performance. It’s a pragmatic architecture decision that supports our business model.