Every side project I start used to begin the same way: pick a framework, then pick a database, then figure out where that database lives. A hosted Postgres for the real thing, something else locally, connection strings in three places, and a migration story to sort out before I'd written a single feature. The database decision alone could eat the first evening.
Yatta JS removes that first evening. It's a backend-as-a-server for Bun, and the database is already inside it — a built-in database with a type-safe ORM, sitting in the same process as the rest of the backend. There is no database server to provision, no connection string to babysit, and no separate service to keep awake for a project with twelve users.
That changes how a first feature feels. The data your API serves lives next to the code that serves it. You define the shape, you read and write it from the same runtime, and the thing you deploy is one process, not a diagram of services. Auth, mail, storage, realtime, jobs, and observability live in that same process too, so the usual "I'll add that later" pieces are already there when later arrives.
The honest boundary: a built-in database is the right call at solo and small-team scale. It is not a claim that one process replaces a dedicated database cluster forever — if a project ever outgrows it, that means it found users, which is a good problem. But most side projects never die from scale. They die from setup, and a database server is often the first piece of setup that kills the momentum.
So the rule I use now: if the project is small, keep the database in the app. Yatta JS is on npm as yatta.js — install it with npm i yatta.js — and the docs are at https://yatta.js.org. Code: https://github.com/psrockstar098/yatta.js
What killed your last side project's momentum — the database setup, auth, or something else?
Top comments (0)