docs/backend-storage-comparison.md holds draft notes for your solo SaaS side project storage decision. You’re choosing between these two file-based storage options because you don’t want to manage a separate database server for your small, low-traffic app, and you want to keep your tech stack as simple as possible while still supporting your core features.
Compare core performance metrics
You run all performance tests on your 2GB Ubuntu VPS to ensure results match real-world production conditions. The table below averages latency across 100 consecutive test runs for common backend workloads:
| Workload type | SQLite (v3.41) latency | JSON file (node:fs read/write) latency | Notes |
|---|---|---|---|
| Single record fetch by unique ID | 1.2ms | 12.7ms | JSON requires parsing the full file to locate the matching record |
| Bulk 1000 record fetch | 8.4ms | 21.3ms | JSON file size is 2.2MB for 1000 sample user records |
| Single record update | 1.7ms | 19.4ms | JSON requires rewriting the full file after modifying one entry |
| Bulk 100 record update | 5.9ms | 172.1ms | JSON write time grows linearly with total file size |
Illustrative example: 12,472 user records stored as a single JSON file take 187ms to parse fully on every request that accesses user data, compared to 2ms for an indexed SQLite lookup of a single user from that same dataset. You notice that JSON performance drops sharply as file size grows, while SQLite performance stays relatively consistent even as you add tens of thousands of records, thanks to built-in indexing that removes the need to scan the full dataset for every query. You also note that SQLite read performance stays consistent even when multiple users access the database at the same time, while concurrent reads of large JSON files can cause server memory spikes that slow down all incoming requests.
Calculate implementation overhead for solo workflows
You weigh the time you’ll spend setting up and maintaining each option against the benefits they provide, since your time as a solo developer is your most limited resource. For JSON files, there is zero setup overhead: you can create a new JSON file, write data to it, and read from it with built-in filesystem functions in every programming language, no dependencies or installation required. You can edit the file directly in your code editor if you need to fix a single data entry, no query syntax required, and you can back it up by copying the file to a cloud storage bucket in one line of code. The main overhead comes from writing custom code to handle common data operations: filtering, sorting, paginating records, ensuring data consistency, and preventing corruption during writes. You have to write all of this logic from scratch, since there are no built-in safeguards for JSON file storage.
For SQLite, you spend a small amount of upfront time writing simple migration scripts when you need to update your data schema, but you get all common data operation logic built in: filter, sort, paginate, and modify records with standard SQL queries, no custom code required. You also get built-in transactions and data constraints that prevent invalid data from being saved and eliminate the risk of file corruption if your server crashes mid-write. The setup overhead for SQLite is roughly one hour for a basic backend, compared to 10 minutes for JSON, but you save dozens of hours later on writing and debugging custom data handling code.
Map use cases to each storage option
You don’t have to choose one option for your entire backend; you can mix and match them based on the type of data you’re storing to get the best of both worlds. JSON files are ideal for static or semi-static data that changes very rarely, and that you don’t need to filter or sort dynamically. This includes your app’s feature flag settings, tier pricing details, static landing page content, and public API documentation that you update once every few months at most. For these use cases, the performance difference between JSON and SQLite is negligible, and the simplicity of editing a JSON file directly outweighs any benefits of using a database. You can even import the JSON file directly into your backend code as a static object, eliminating disk I/O entirely for those data points.
SQLite is the better choice for dynamic data that changes frequently, or that you need to query in flexible ways. This includes user account records, session data, user-generated content, order histories, and any other data that is modified by users on a regular basis. For these use cases, the performance and reliability benefits of SQLite far outweigh the small setup overhead. If you try to use JSON files for dynamic data, you will quickly run into performance issues as your user base grows, and you will spend far more time fixing data corruption issues and writing custom query logic than you would have spent setting up SQLite in the first place. You also avoid the risk of data loss from concurrent writes, which is a common issue with JSON file storage when multiple users modify data at the same time.
Outline edge case mitigation steps
Even with the right storage option for your use case, you need to put small safeguards in place to prevent data loss and ensure consistent performance for your users. You follow these 5 steps for both storage options to cover the most common edge cases:
- For JSON file storage, enable atomic writes by writing all changes to a temporary file first, then renaming the temporary file to replace the original once the write is complete. This ensures you never have a half-written file if your server process crashes or loses power in the middle of a save operation, which would corrupt the entire JSON file and lead to total data loss for that dataset.
- For SQLite storage, enable write-ahead logging (WAL) mode on database initialization to support concurrent reads and writes without locking the entire database for every write operation. This reduces latency for write-heavy workloads and prevents timeouts for users who are trying to read data while another user is modifying a different record.
- For both storage options, set up automated daily backups to a separate cloud storage bucket, with 30 days of version history enabled so you can restore previous versions of your data if it gets corrupted or accidentally deleted. You test your backup restore process once a month to confirm it works as expected, so you don’t get stuck with unusable backups when you need them.
- For dynamic datasets larger than 1000 records, add a lightweight in-memory caching layer for frequent queries, regardless of which storage option you use, to reduce disk I/O and speed up response times for your users. You invalidate the cache automatically any time the underlying data is modified, so users always see the most up-to-date information.
- For any write operation that modifies more than 10 records at a time, add a schema validation step before executing the write to confirm all changes match your expected data structure and value constraints. This prevents invalid data from being saved to your storage layer, which could break downstream functionality for all of your users.
Open this file after running your initial performance test
When you open this file next, you already have real test data from running your core app workflows with both storage options on your production server. You paste your actual latency numbers into the table in the first section to replace the sample data, and adjust the use case mapping to match your app’s specific data access patterns. You note any edge cases you ran into during testing that you didn’t account for in your initial outline, such as rare concurrent write scenarios for your user-generated content feature, and update your mitigation steps to cover those cases. You weigh the tradeoffs between setup time, maintenance overhead, performance, and reliability for your specific use case, and make a final call on which storage option to use for each part of your backend. If you’re still unsure which option is right for a specific part of your app, you can prototype both in less than an hour, since both are file-based and require no external server setup or configuration. If you need pre-built backend templates that support both SQLite and JSON storage out of the box, Build Next Stack has boilerplates optimized for solo developer workflows that cut down setup time significantly. You don’t overcomplicate the decision: for most solo backend projects, SQLite is the better default choice for all dynamic data, and JSON files work perfectly for static config data, with minimal overhead and maintenance required for either option.