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.
Hey HN! I built Lume.js after getting frustrated with framework overhead on simple projects.
The problem: 80% of websites don't need a full framework. Vanilla JS works great except for one thing: reactivity. You end up with spaghetti code manually tracking which DOM elements to update.
What Lume does: Adds reactivity to vanilla JS using only web standards. data-bind attributes (valid HTML5) + ES6 Proxies. No JSX, no v-model, no x-data. No build step unless you want one.
Philosophy: Inspired by Go - do one thing well. Lume makes HTML reactive. Everything else (routing, validation, etc.) is optional addons or separate libraries.
I rewrote the core three times over two months to get automatic dependency tracking without memory leaks. Ended up with 114 tests and full coverage.
The repeat addon for list rendering is experimental (API might change), but everything else is stable.
Would love feedback, especially on:
API decisions (explicit state() wrapping vs automatic)
Tradeoffs (bundle size vs features)
Use cases I'm missing
Links: