vibecode-db rethinks how frontend apps talk to the backend. Define your schema once and query any backend - SQLite, Supabase, PostgreSQL, REST APIs — using one unified, type-safe interface. No rewrites, no SDK switching, no lock-in. Swap databases anytime, build offline-first apps, and integrate any backend through CustomAdapter. Write once. Use anywhere.
Hey Product Hunt!
We built vibecode-db because modern frontend developers deal with too many database APIs — SQLite in the browser, Supabase for side projects, Postgres in production, custom REST endpoints in enterprises.
The result?
Rewrites. Vendor lock-in. Cognitive overload.
vibecode-db fixes this.
You define your schema once.
You write your queries once.
And you can plug in any database using adapters — without changing your application code.
It’s type-safe, fully open source, and built for real-world dev workflows:
• prototype in SQLite,
• deploy on Supabase,
• integrate REST APIs,
• or migrate databases without rewriting code.
We’d love your feedback, ideas, and contributions.
This is just the beginning — and your support means the world.
Happy to answer any questions!
— The Vibecode Team (GeekyAnts)
Report
@sanketsahu Any thoughts on performance trade‑offs when switching between SQLite prototyping and Supabase deployment? Congrats on launch!
@lliloulane No guardrails today. The QueryBuilder exposes a unified API, and each adapter (SQLite, Supabase, Custom) handles compatibility. SQLite and Supabase support the full query API natively, so errors come from the underlying system. Custom adapters can implement client-side fallbacks or return errors as needed.
As we add more adapters (Firebase, GraphQL), we'll incorporate guardrails (runtime warnings and capability validation). This keeps your query code consistent while adapters handle differences transparently.
RapidNative
@sanketsahu Any thoughts on performance trade‑offs when switching between SQLite prototyping and Supabase deployment? Congrats on launch!
RapidNative
@masump It's just a mapper, shouldn't cause any performance issues when switching!
Congrats @sanketsahu and team! Are there guardrails for preventing developers from writing queries that one adapter supports but another doesn't?
Vibecode DB
@lliloulane No guardrails today. The QueryBuilder exposes a unified API, and each adapter (SQLite, Supabase, Custom) handles compatibility. SQLite and Supabase support the full query API natively, so errors come from the underlying system. Custom adapters can implement client-side fallbacks or return errors as needed.
As we add more adapters (Firebase, GraphQL), we'll incorporate guardrails (runtime warnings and capability validation). This keeps your query code consistent while adapters handle differences transparently.
Somorr
Hi is it open source?
RapidNative
Yes@daniel112, it is an open source project!