How Infisical Migrated from MongoDB to PostgreSQL and What You Can Learn

Infisical, a SaaS platform for secret management, grew to handle over 50 million keys per day and needed a more robust database than MongoDB. The team decided to migrate to PostgreSQL to gain transactional support, relational features, and better cloud provider compatibility.

Why abandon MongoDB?

MongoDB’s schema‑less design caused several pain points: difficulty configuring transactions, lack of cascade deletes, limited cloud‑provider support after the SSPL license change, and a steep learning curve for customers unfamiliar with MongoDB. These limitations made self‑hosting Infisical harder and increased support overhead.

Why choose PostgreSQL?

The team evaluated three options: embedding a lightweight store (e.g., SQLite), using an external relational database (PostgreSQL/MySQL), or building a custom storage layer. PostgreSQL won because of its active community, extensive documentation, rich extensions, and universal availability as a managed service across cloud providers.

ORM decision

To replace Mongoose, the team compared Drizzle ORM, Prisma, TypeORM, and Knex.js. They selected Knex.js, a query builder, for its low abstraction level, built‑in seeding and migration tools, and strong TypeScript support after custom Zod integration.

Migration planning

Because Infisical is critical for customers, any downtime had to be avoided. The plan allowed a short write‑freeze window (≈6 hours) where only reads were permitted. Data would be exported from MongoDB, transformed, and inserted into PostgreSQL table‑by‑table. To handle identifier mapping at scale, a LevelDB key‑value store was used to persist MongoDB‑to‑PostgreSQL IDs.

Execution steps

Notify users weeks in advance via email and in‑app banners.

Run a trial migration and thorough functional testing.

During the six‑hour window, execute migration scripts, verify data integrity, and switch DNS to the new PostgreSQL‑backed service.

Post‑migration, resolve any residual issues and publish updated documentation.

Results

The migration completed without data loss; only a few non‑critical features experienced brief glitches, which were fixed within 36 hours. Benefits observed include:

Significant performance boost by eliminating costly $lookup aggregation pipelines and reducing database costs by roughly 50 %.

Stronger data validation at the database layer, removing reliance on Mongoose schema enforcement.

Easier self‑hosting for customers, as PostgreSQL’s native transaction support eliminates the need for complex MongoDB replica‑set setups.

Conclusion

The three‑to‑four‑month migration required careful planning, extensive code rewrites, and a disciplined execution window, but it delivered a more reliable, performant, and self‑hostable platform. The team recommends that anyone considering a similar large‑scale database migration thoroughly assess use‑cases, plan for minimal downtime, and validate data transformations rigorously.