[ReForge]: Migrate from PocketBase to PostgreSQL + Drizzle

[melvinchia3636]

Context

PocketBase has been great.

It got LifeForge off the ground quickly, and honestly, a huge portion of the project wouldn't exist today without it.

That said, the more I work on LifeForge, the more I find myself fighting abstractions that probably shouldn't exist in the first place.

A lot of things currently look like:

PocketBase Collection
        ↓
Custom Schema Layer
        ↓
Custom Query Layer
        ↓
Zod
        ↓
API Contract

and I'm starting to wonder if I'm solving problems that have already been solved elsewhere.

Proposed Direction

Move towards:

PostgreSQL
        ↓
Drizzle
        ↓
Zod
        ↓
Forge Contract

and let each tool do what it's good at.

Professional problem, professional solution.

Why?

• Less custom abstraction
• Less code to maintain
• Better type safety
• Better migration tooling
• Better database tooling
• Better support for views and more advanced database features
• Fewer moments of "why did I build this myself again?"

Why this is becoming more urgent now

At the time I wrote this issue, I genuinely saw the migration as a longer-term direction rather than something that needed to happen before stabilization.

That assessment changed as the modular system matured.

The main reasons are:

• Module installation and uninstallation need to be fully automated. PocketBase collection/schema changes still require manual intervention through the admin dashboard, which does not fit the lifecycle I want for modules.
• PocketBase adds an extra abstraction layer in the request path. LifeForge currently goes through the API, then the PocketBase SDK, then PocketBase itself before reaching the database. That adds complexity, latency, and resource usage that no longer feels worth it.
• The current PocketBase TypeScript wrapper has become fragile technical debt. It exists mostly to compensate for the SDK rather than provide meaningful value, and maintaining it has become increasingly expensive.

So the migration is no longer just about preferring PostgreSQL. It is about removing a layer that is actively getting in the way of an automated, stable, module-friendly backend.

Notes

This isn't happening tomorrow.

PocketBase still works perfectly fine, and there is no urgent need to rip it out just for the sake of it.

This is a long-term architectural direction for LifeForge, and the migration will happen as part of finishing the remaining foundational work for ReForge.

Also, if I ever find myself implementing half an ORM inside LifeForge, please remind me this issue exists. :)

[Curicows]

I noticed that the Drizzle ORM got abandoned (at the moment it is 2 months without any commits).

It would be needed to analyze a better long-term solution.

[melvinchia3636]

Ahh I see, never noticed that their open issue count has already grown to a dangerous level. Well, that is definitely a decision to be carefully discussed and considered. We will have to find a balance between DX and stability for our ORM solution. Anyhow, appreciate your reminder.

[melvinchia3636]

However, upon further investigation, I realized this branch is still very actively maintained and has thousands of commits ahead of the main branch.

[Curicows]

Even though this branch is being maintained, the issues amount is a little worrying and maybe not the best option when thinking in longevity.

[lukashow]

I see another one named TypeORM that still "actively" maintain. However, the issue amount is way worrying, so we might have to discuss further if anyone interested with it.

I see many vibecoders quite favor with this ORM, so I believe there should be a reason behind.

[Curicows]

There is also the MikroOrm, I already used it a lot in several NestJS apps and is consistent and very good at performance.
But the typeorm seems like a better option to the long-term. It is actively being maintained and is mature enough to be reliable.
I think the typeorm would be a perfect choice.

[lukashow]

From some of my research (and my personal testing), MikroORM is much better in type safety, which I think we will be in favor of (as we are using TypeScript for this project).

TypeORM is more actively maintained but I couldn't sure whether @melvinchia3636 will more prefer MikroORM more due to its strict compile-time type safety feature.

I've performed several tests too using Postgresql and Oracle database with some heavy queries, and both of it have very little performance differences.