I’ve been working on RushDB, an instant, open-source database built on Neo4j. The idea is simple: no schema design, no migrations, no backend setup - just throw in any JSON/CSV data, and it figures out the structure dynamically.
A decade ago, I started as a frontend developer, and over the years, I kept running into the same problem: needing a simple yet powerful persistence layer without dealing with infrastructure, normalization, database setups, CRUD boilerplate, or backend proxies just to fetch rows by criteria. RushDB is my take on fixing that.
It’s not another document store. Instead of dumping nested JSON and hoping for the best, RushDB normalizes data into an interconnected graph on the fly - without flaky LLM guesses. Instead, it runs a deterministic, optimized BFS-based algorithm to handle relationships, data types, and structure.
What makes it different?
- No schema or configuration: Just push any data, and RushDB does the heavy lifting on the fly.
- Graph querying without Cypher overhead: Works like MongoDB but for graph data. Simple API, no need to write graph queries manually.
- Dynamic filtering: Think faceted search in marketplaces - filters generate automatically based on ingested data. - No migrations: Schema changes work just like in MongoDB - batch updates to Records.
- Fractal API: Filtering refines itself dynamically based on previous queries, only showing valid options.
- Battle-tested: A team of two frontend devs built an entire EdTech platform (LMS, CMS, and Analytics with telemetry for a web-first 3D engine) using only RushDB - no backend expertise required.
Right now, there’s an SDK for Python and TypeScript, but the REST API provides the same DX.
GitHub: https://github.com/rush-db/rushdb
Would love to hear your thoughts, feedback, or any edge cases that might break it!