I picked MongoDB on day one. By month eight I needed Postgres.

The decision took about nine minutes.

It was the start of a new product — VirtualRx, a business-management app for
small retailers in Lagos. Point of sale, inventory, invoices, the lot. I
needed a database, I had a schema roughly in my head, and MongoDB let me
start writing code that afternoon instead of arguing with migrations. Nine
minutes. createdb, connection string, first model, move on.

That decision was fine for about eight months.

Then a client asked a question I couldn't answer: "Which of my three
branches actually makes money on Tuesdays?"

It's not an exotic question. It's a GROUP BY with a couple of joins and a
window function. On Postgres it's ten lines. On Mongo it was an aggregation
pipeline I rewrote four times, got working, and then couldn't read a week
later. I remember staring at a $lookup inside a $facet and thinking:
I chose this in nine minutes, and now I'm stuck with it.

The obvious move was to add Postgres for reporting. Keep Mongo for the
operational stuff, pipe the analytics somewhere that likes analytics. Sensible.
Boring. Standard.

Except that meant two data layers. Two sets of models. Two mental models. And
every helper I'd written — soft delete, tenant scoping, audit logging — needed
a second implementation that behaved almost the same.

What I actually wanted

I wanted to write this:

const rows = await db.sale.findMany({
  where: { locationId, postedAt: { gte: start } },
  include: { customer: true },
});

…and have it not care which database was underneath.

Not "abstract away SQL." Not "one query language to rule them all." Just:
the ordinary 90% of queries should be portable, and the other 10% should
drop to raw SQL without ceremony.

I looked at what existed.

Prisma has the API shape I wanted. But it's a code generation step. Every
schema change means prisma generate, a regenerated client committed or
gitignored, a Rust query engine binary in your deploy, and a real fight to run
in a browser or on React Native. I've watched a teammate lose an afternoon to a
stale generated client that looked fine.

Drizzle is excellent and I nearly used it. But it's SQL-shaped by design —
which is the right call for a SQL-only tool, and the wrong one when one of my
six targets is MongoDB.

TypeORM and friends: decorators, metadata, a lot of machinery.

None of them ran in a browser tab. That mattered more than I expected, and I'll
come back to it in a later post.

So I did the thing you're not supposed to do. I wrote my own.

forge-orm

It's a small, Prisma-shaped data layer for MongoDB, PostgreSQL, MySQL,
SQLite, DuckDB and SQL Server. You write models once in plain TypeScript and
the same query code runs against any of them.

npm install forge-orm
npm install pg          # only the driver you actually use

import { createDb, f, model } from 'forge-orm';

const User = model('users', {
  id:    f.id(),
  email: f.string().unique(),
  name:  f.string(),
  age:   f.int().optional(),
});

const db = await createDb({
  url: process.env.DATABASE_URL!,   // postgres:// … | mongodb:// … | sqlite: …
  schema: { user: User },
});

const adults = await db.user.findMany({
  where:   { age: { gte: 18 } },
  orderBy: { name: 'asc' },
  take:    20,
});

adults is fully typed. There was no build step. There is no generated client
in your repo. Change the model, and the types change on the next keystroke —
because they're inferred from the object you just wrote, not produced by a
tool you have to remember to run.

Point DATABASE_URL at Mongo instead and that same findMany runs as a Mongo
find. Point it at SQLite and it's a SELECT. The query code doesn't move.

The part I didn't expect to matter

forge ships no database driver of its own. Each one is an optional peer
dependency, so npm install forge-orm pulls nothing extra, and importing forge
needs no driver at all.

Database	URL starts with	Install
PostgreSQL	postgres://	npm install pg
MySQL / MariaDB	mysql://	npm install mysql2
SQLite	sqlite: or file:	npm install better-sqlite3
MongoDB	mongodb://	npm install mongodb
DuckDB	duckdb:	npm install @duckdb/node-api
SQL Server	mssql:	npm install mssql

That sounds like packaging trivia. It turned out to be the thing that let forge
run in places an ORM normally can't — a browser tab, an Expo app, an embedded
Postgres compiled to WebAssembly. Those posts are coming.

What it is not

I want to be straight about this, because I've been burned by READMEs that
weren't.

forge is not a replacement for Prisma or Drizzle in maturity. It has fewer
features, a much smaller ecosystem, and no GUI. Prisma's migration tooling is
more battle-tested than mine. Drizzle's SQL surface is broader. If you need
either of those things, use them — genuinely.

What forge gives you is a small dependency you can read in an afternoon, one
query API across six databases, full autocomplete with nothing to regenerate,
and the ability to drop to raw SQL whenever the abstraction stops helping:

const rows = await db.$queryRaw`
  SELECT location_id, SUM(total) AS revenue
  FROM sales WHERE posted_at >= ${start}
  GROUP BY location_id
`;

That escape hatch is not an admission of failure. It's the point. An ORM that
tries to own every query eventually owns the ones it's bad at.

Did it actually solve the problem?

VirtualRx still runs on MongoDB. The analytics moved to a Postgres read model.
Both go through the same db.<model>.findMany calls, the same models, the same
soft-delete and tenant-scoping helpers. The report that started all this is
about fifteen lines now.

And the nine-minute decision stopped being permanent, which is really all I
wanted.

---

Next in this series: the codegen step — why prisma generate exists, what
it's actually solving, and how you get the same autocomplete without it.

📖 Docs: johnsonfash.github.io/forge-orm
📦 npm: forge-orm
⭐ GitHub: johnsonfash/forge-orm

If you've been stuck with a day-one database decision, I'd genuinely like to
hear what it was. That's half of why I wrote this.