Why Infisical Switched from MongoDB to PostgreSQL—and How They Did It

Background

Infisical is an open‑source key‑management platform that processes over 50 million secrets daily for teams, CI/CD pipelines, and servers. Rapid growth made the original MongoDB + Mongoose stack insufficient for the platform’s evolving requirements.

Why Abandon MongoDB?

Several practical constraints pushed Infisical away from MongoDB:

Difficulty configuring transactions : MongoDB requires a clustered deployment for reliable transactions, creating heavy operational overhead for customers running simple proof‑of‑concepts.

Lack of relational features : Absence of cascade deletes and other relational semantics caused orphaned records and complex cleanup logic.

Inconsistent cloud‑provider support : After MongoDB switched to the SSPL license, many providers only offered older versions, limiting feature availability.

Limited operational expertise : Teams were more familiar with SQL databases, leading to higher support costs for MongoDB deployments.

These issues, combined with the desire to make self‑hosted deployments easier, motivated a move to a relational database.

Choosing PostgreSQL

The team listed key criteria: easy management, built‑in transaction support, and robust relational capabilities. Alternatives considered included embedding SQLite with Raft replication, or using other external databases such as MySQL. PostgreSQL was selected for its vibrant community, extensive documentation, rich ecosystem of extensions, and universal support across cloud providers.

ORM Strategy

To replace Mongoose, the team evaluated Drizzle ORM, Prisma, TypeORM, and Knex.js. They ultimately chose Knex.js because it offers fine‑grained control, a mature migration toolset, and straightforward TypeScript integration, avoiding the overhead of a full ORM while still providing query building utilities.

Migration Planning

Given Infisical’s critical role in customer infrastructure, a full‑stop migration was unacceptable. The plan allowed a short write‑freeze window (≈6 hours) during which only read operations were permitted. The migration steps were:

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

Export data from MongoDB, transform hierarchical structures into relational tables, and store identifier mappings in a LevelDB key‑value store to avoid memory exhaustion.

Insert transformed data into PostgreSQL in batches, verifying integrity after each batch.

Switch DNS to the new PostgreSQL‑backed instances and run post‑migration validation.

Address any residual issues and publish updated documentation.

Execution and Results

The migration completed without data loss; only minor non‑essential features failed temporarily and were fixed within 36 hours. Observed benefits include:

Significant performance boost : Eliminated costly $lookup aggregations, reducing database spend by ~50%.

Improved data validation : PostgreSQL enforces schema and type constraints at the database layer, eliminating inconsistencies previously handled by Mongoose.

Easier self‑hosting : Customers can now run Infisical on any cloud provider’s managed PostgreSQL service without complex MongoDB replica‑set configurations.

Conclusion

The three‑to‑four‑month effort demonstrated that a well‑planned migration from a NoSQL to a relational store can yield performance, reliability, and operational advantages. The team advises anyone undertaking a similar large‑scale migration to thoroughly evaluate use cases, plan the data transformation, and conduct extensive testing before execution.