Telebugs Thrives on SQLite

Telebugs runs on SQLite.

Not as a toy setup. Not as the thing I plan to replace once Telebugs gets "serious." SQLite is part of the design.

I like that. Actually, I love that.

A self-hosted error tracker should be easy to understand. You should be able to run it on one server, back it up without a committee meeting, move it when you need to, and know roughly where your data lives. SQLite fits that shape beautifully.

SQLite Fits Telebugs

Telebugs is a focused product. It receives errors, groups them, stores useful debugging context, sends notifications, keeps releases and source maps around, and helps you fix the thing that broke.

That does not require a giant distributed system. It requires boring persistence, sensible indexes, a queue, retention, cleanup, and enough operational care that the boring parts stay boring.

SQLite is extremely good at being boring in the best possible way. There is no separate database server to provision. No network hop between the app and the database. No second service to forget during a backup. The database is right there, inside the persistent storage for the app.

The Stack Got Good at This

Modern Rails made this setup feel normal again. Telebugs uses SQLite for the primary application database, Solid Cache for cache storage, and Solid Queue for background jobs.

In production, that means a small set of files in persistent storage:

storage/db/production.sqlite3
storage/db/production_cache.sqlite3
storage/db/production_queue.sqlite3

I like how plain that is. Application data is in one SQLite database. Cache data is in another. Queue churn is in another. You can reason about them separately without adding Postgres, Redis, a queue broker, and a tiny operations department to your error tracker.

That is very much the Telebugs philosophy: fewer moving parts, fewer services to babysit, and enough power for the job it is meant to do.

SQLite Makes You Honest

SQLite is not magic. I do not want to pretend it is.

A few months ago I wrote about a customer whose queue database grew to 95GB in a single day. The problem was not that SQLite was bad. The problem was that I had put large payloads directly inside background job arguments. SQLite made the mistake visible very quickly.

That was painful, but useful. It forced the design in the right direction: job arguments should be identifiers, not giant blobs of data. Heavy payloads should live in the right table, be processed, and be cleaned up deliberately.

I like tools that make sloppy architecture feel uncomfortable. SQLite does that. It rewards simple, direct data design and makes the cost of carelessness obvious.

Telebugs Cares for SQLite

Celebrating SQLite does not mean ignoring the operational details. Telebugs has to treat SQLite well.

There is a scheduled VACUUM job, but it checks free disk space first because SQLite may need up to twice the database size to complete the operation. There is a recurring PRAGMA optimize job. Disk usage checks include the main database file plus the WAL and SHM files. Ingest protection can pause incoming errors before a noisy app turns a bad deploy into a disk problem.

This is the unglamorous part, but it matters. A small system should not mean a fragile system. It should mean you can see the whole thing, understand the tradeoffs, and give the database the care it needs.

Why This Matters

For Telebugs users, SQLite turns into practical benefits:

• one app to deploy
• one persistent volume to back up
• no separate database server to operate
• no Redis just to run jobs or cache data
• easy local, private, VPS, and internal-network deployments
• a system that stays small enough to understand

This is especially important for self-hosted error tracking. If you choose self-hosting because you want control, privacy, predictable costs, or fewer vendor dependencies, the database story should support that. SQLite does.

I do not want Telebugs to become a platform that requires a platform team. I want it to be useful software you can run, trust, back up, and forget about until an error needs your attention.

Small Is a Feature

SQLite lets Telebugs stay Telebugs: self-hosted, source-provided after purchase, Sentry SDK compatible, simple to deploy, and boring to operate.

It is not the right database for every product. That is fine. Telebugs is not trying to be every product.

For this product, for this shape, SQLite feels exactly right.

That is worth celebrating.

Telebugs is a self-hosted Sentry alternative that runs on your own server, with no event quotas and no monthly surprise. Learn more at telebugs.com.