FindBug v0.5 is out - database-agnostic (PG/MySQL/SQLite), 79 specs, and what's coming next
Hey everyone,
Three months ago I posted about FindBug, a self-hosted error tracking gem for Rails. The feedback was way more than I expected - and a few specific asks came up over and over. v0.5 is the release that ships them.
TL;DR: No more jsonb - only. Works on PostgreSQL, MySQL, and SQLite now, with the adapter detected automatically. 79 RSpec examples covering every adapter path. Yes, AI helped build parts of this - more on that below.
What v0.5 ships
1. Database-agnostic - your #1 ask
Until now FindBug was effectively PostgreSQL-only. The migrations used jsonb, the dashboard's time-bucket queries used `date_trunc()`. If you were on MySQL or SQLite, things broke in interesting and embarrassing ways.
v0.5 detects your ActiveRecord::Base.connection.adapter_name at migration and query time, and picks the right column types and SQL functions per adapter.
Application code is identical across adapters - the model's JSON accessors normalise reads to native `Hash` / `Array` regardless of underlying storage. And the helper that drives this is part of the public API, in case you want to write your own migrations against the same strategy:
Existing PG users - this is fully backwards compatible. Your schema doesn't change, your code doesn't change, you just `bundle update findbug` and carry on.
2. Tests, for real this time
When I shipped v0.4, the test suite was - let's call it "aspirational." For v0.5 I wrote 79 RSpec examples covering:
- Adapter detection across PostgreSQL / MySQL / SQLite (using stubbed connection names so we test every branch)
- JSON column round-trips on real SQLite text columns - round-trip Hash → text → Hash, malformed JSON, pre-serialised strings, nil
- JSON accessor behaviour on stubbed `jsonb` / `json` columns - verify the setter passes through to AR's native type system without double-encoding
- Model behaviour - validations, fingerprint upsert, percentile aggregation, time-series queries
- Edge cases I'd been quietly hoping nobody would hit
The suite runs against in-memory SQLite, so contributors can send PRs without standing up a PG cluster.
On AI - being straight about it
I want to put this out there because I think the community deserves honesty: I used AI (Claude, mostly) extensively while building FindBug. Code review, hunting edge cases, scaffolding tests, refactoring loops for clarity, generating doc tables, the boring CSS.
What I did not outsource:
- The "never block the request" rule
- Why a dedicated Redis connection pool, separate from the app's
- Why fingerprint-based aggregation instead of storing every event
- Why a background thread by default and ActiveJob as an opt-in
- The decision to make alert channels DB-driven so they're configurable from the dashboard without redeploys
- Which features ship in which release
AI sped up the typing; the engineering judgment was mine. I'd rather say that out loud than pretend a solo dev shipped 7,000 lines of code at side-project velocity through pure caffeine.
What's coming in v0.6
Driven entirely by comments on the last thread:
- Frontend JS error tracking for Rails apps that render views - a findbug_js_tag helper that injects a tiny snippet, an ingest endpoint inside the engine, frontend errors flowing through the same Redis → DB pipeline with `source: "javascript"`. Same-origin only, so no source-map gymnastics in v0.6.
- Valkey support - Valkey is a drop-in Redis replacement after Redis Inc.'s licensing shenanigans. Should mostly Just Work, but I want to test and document it explicitly so people don't have to guess.
- Solid Queue as an alternative to Redis - for apps already on Solid Queue who'd rather not run a separate Redis just for FindBug's buffer.
- No-Redis (and no-Valkey) mode - for tiny apps that don't want to introduce a key-value store at all. Direct DB writes, with a big "you'll pay the latency cost" warning in the docs. Opt-in.
- Separate database for FindBug events - point the gem at its own DB via connects_to, so error data lives in a dedicated operational database instead of bloating your application DB. Useful for multi-tenant apps and for keeping retention windows independent of your main DB's backup strategy.
If one of these matters more to you than the others, comment and I'll prioritise.
Links
- Site & live demo: https://findbug.dev
- Docs: https://findbug.dev/docs
- RubyGems: https://rubygems.org/gems/findbug
- GitHub: https://github.com/ITSSOUMIT/findbug ← ⭐ if it's useful to you
If you tried v0.4 and bounced because of the PG-only limitation, this is the release for you. And if you've got opinions on the v0.6 roadmap - particularly the no-Redis path - drop them in the comments. Every priority above came from feedback on the last thread; I'd like to keep it that way.
One small ask: if FindBug solves a problem for you (or even just looks like it might), a ⭐ on the repo goes a long way. It's the main signal other Rails devs use to decide whether a side-project gem is worth trying, and right now it's the difference between FindBug being a "weird thing I built" and "thing people actually use." No pressure if it's not your thing - just thanks for reading this far either way.
- Soumit
Link to the launch post of FindBug -
https://www.reddit.com/r/rails/comments/1rea800/i_built_findbug_a_selfhosted_opensource_error/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button