Why I built ElysianDB
Source: Dev.to
The Problem with Early Backend Decisions
Most projects don’t fail because of a lack of ideas.
They slow down for a more structural reason: backend decisions are either made too early, or postponed behind mocks that no one truly trusts.
At the beginning of a project, teams want momentum. They want to explore features, validate user flows, and iterate quickly. But they still need a backend that behaves like a real system—not a fragile mock that collapses as soon as authentication, permissions, or relations appear, and not a fully designed architecture that assumes too much about a product that barely exists.
This tension is common and costly:
- Mocks tend to grow until they resemble a backend without its guarantees.
- Real implementations often start with constraints that later turn out to be wrong.
In both cases, teams end up rewriting significant parts of what they built, either because it was never meant to last, or because it was designed too early.
Introducing ElysianDB
ElysianDB was born from that gap. The project is written in Go and built around a simple idea: allow teams to start with a real backend from day one, without locking themselves into architectural decisions that should only be made once the product is clearer.
Immediate Usability
- Starts from raw JSON.
- Stores documents with an instantly usable API.
- CRUD endpoints are available without scaffolding.
- Queries are real, persistence is real, and authentication & access control are enforced from the beginning.
- Frontends talk to an actual system, not a placeholder.
Continuity Over Premature Optimization
Early in a project, ElysianDB relies on a fast and lightweight internal storage engine designed for rapid iteration, minimal setup, and low friction. The priority at this stage is speed of feedback and the ability to change direction safely—not maximum durability or horizontal scalability.
As the project evolves:
- Data grows.
- Reliability becomes critical.
Instead of redesigning the backend or migrating APIs, ElysianDB allows the storage layer to evolve. By switching configuration, the same API can run on MongoDB. Endpoints stay identical, contracts remain stable, and the frontend does not need to adapt. The system grows without breaking what was already built.
Behavior and Permissions
ElysianDB addresses dynamic behavior and security through hooks and access control lists (ACLs).
Hooks
- Written in JavaScript.
- Executed at read time.
- Enable enrichment or transformation of data dynamically without mutating stored documents or embedding business logic too early.
ACLs
- Define permissions explicitly.
- Enforce them consistently, avoiding retrofitted security after launch.
Both are managed through a web‑based admin interface, making complexity visible and adjustable as the system evolves.
Current Status
ElysianDB is still under active development. It is not yet a mature, all‑encompassing backend solution, and it does not claim to be one. Its purpose is to reduce backend friction without pretending that complexity does not exist.
- Not a replacement for carefully crafted domain‑driven systems.
- Not a competitor to large backend platforms.
- Goal: Provide a trustworthy backend early, keep it honest as the project grows, and delay irreversible decisions until they are justified.
Call to Action
If this way of building resonates with you, I would genuinely like to know where you would use ElysianDB—and where you would not.