Hey HN,
I’m Sathvik, the creator of OmniDB.
I built this because I kept seeing the same outage pattern in production: the primary database isn’t "down" (refusing connections), it’s just stalled or slow. The application keeps trying to use it, the connection pool exhausts, and everything halts.
Most simple failover logic looks like this:
if (primary.isDown) switch_to(replica)
But this doesn't capture latency spikes or "zombie" connections. I found myself writing ~200 lines of manual "glue code" for every project to handle health checks, timeouts, and graceful failovers properly.
OmniDB is a library that extracts that logic into a thin orchestration layer (<10KB, 0 deps).
What it does:
- Orchestration, not Abstraction: You bring your own client (Prisma, pg, Redis, Mongo, etc.). OmniDB just manages the lifecycle.
- Real Health Checks: Checks for latency/timeouts, not just connectivity.
- Circuit Breakers: Built-in protection to stop cascading failures.
- O(1) Scalability: Uses a Map-based registry so it handles N database connections/shards with constant-time lookup.
It’s TypeScript-first and designed to be dropped into existing Node.js backends.
Repo: https://github.com/sathvikc/omni-db
I’d love to hear how you handle application-side failover logic. Do you roll your own or rely entirely on infrastructure (proxies/LBs)?
