Convert MongoDB to PostgreSQL with a mapping you can review
A document database can contain relationships without declaring them. A blog post might store a user's ObjectId in userId, but MongoDB does not need a foreign key to accept that document. Moving those records to PostgreSQL means deciding which links should become constraints and what to do with records that do not match.
Layerbase's MongoDB to PostgreSQL conversion gives you a mapping to review before it copies anything. You can start from an external MongoDB database, including Atlas, or from a managed DocumentDB database in Layerbase. PostgreSQL is the first target. FerretDB conversion and MySQL/MariaDB targets are deferred.
This changes your data model and database protocol. It does not translate your application's MongoDB queries into SQL. Plan for application changes and test them before cutover.
Review the tables before copying
Layerbase profiles field names, types, and counts, then uses deterministic rules to suggest a mapping. No document values are sent to a model.
The first version creates one root table per collection. First-level arrays can become child tables with an ordinal that preserves their order. Nested arrays stay in JSONB. Fields outside your chosen columns can be retained in JSONB overflow rather than discarded.
MongoDB _id values remain intact as text. The suggested PostgreSQL column name is id unless a separate source field would collide, in which case it remains _id. You can edit that name. Relationship mappings follow it, and any mapping change requires fresh validation before approval.
Decide which relationships become foreign keys
Suppose your blogs collection has a userId field and your users collection has ObjectId identities. Layerbase can suggest the link. You can change its endpoints, add a missing relationship, reject a suggestion, or keep a link documented without enforcing it.
Validation reads the full set of references. It shows matches, unmatched targets, nulls, missing fields, and invalid values. A matching value does not prove what your application intended, so you still approve the relationship yourself.
For an approved foreign key, Layerbase checks the copied PostgreSQL rows again before creating the constraint. An unresolved reference blocks readiness. It does not delete the row, erase the reference, or invent a user to make the check pass. No cascading deletes are added.
Read the verification report
A completed copy and a verified conversion are different things. The report breaks down what was checked:
- Root and child row counts against the source documents and arrays.
- An order-independent checksum of the preserved source IDs.
- Field coverage and values preserved in overflow.
- Approved relationships, including whether references still match.
- Reconstructed documents compared with the source, sampled up to 200 records per collection.
That last check is a sample, not a byte-for-byte comparison of every ordinary value. A passing report is useful evidence, but you should still test your application's queries and important records.
The report also distinguishes unexplained differences from recorded substitutions. Invalid UTF-8 is one example: a display substitution must not destroy the original data. Original bytes remain recoverable, affected records and fields are identified, and those preserved bytes are checked in full. Explained substitutions require acknowledgment of the current report before proceeding.
Stop writes, verify, then switch
Pause application and job writes to the source before copying. Layerbase reads the source without modifying it and writes into a new PostgreSQL target. A retry uses another new target; it does not overwrite an existing populated database.
Keep writes paused, inspect the report, and use Re-verify before changing your application's connection. There is no continuous change replication in this version. If writes resume on the source, a previous verification no longer describes the current state.
MongoDB indexes, validators, TTL behavior, change streams, credentials, and transaction semantics do not carry over unchanged. Review your PostgreSQL indexes, application behavior, and access configuration. Keep the source until you have independently confirmed that the new database works for your application.
Availability and paid access
Conversion requires feature availability and an eligible paid plan with confirmed payment. Free plans, complimentary grants, and active Pro trials cannot start a conversion.
If you are on a Pro trial, your plan page offers End trial & start now. Review the charge and forfeited trial time before confirming. Conversion unlocks after payment is confirmed, not while payment is pending or failed. Existing reports and original-byte recovery remain available after a plan change.
Start with the MongoDB conversion guide, or open Convert on your managed DocumentDB database. The conversion documentation covers mapping review, verification, and cutover. Check access before scheduling your migration window.
Keep reading
- Introducing DocumentDB 1.0: Our 19th Cloud EngineDocumentDB 1.0 joins Layerbase Cloud alongside FerretDB. Run MongoDB-compatible workloads on Free, Solo or Pro, or try it locally on Linux without Docker.
- Northflank alternatives: a preview environment is not a database branchNorthflank gives every pull request its own stack, and the database in that stack starts empty unless you seed it or restore it from a backup you already had. Here is exactly how their forks work, what a copy-on-write branch does differently, what each one costs while a PR sits open, and the cases where Northflank is the right answer.
- Branching with any databaseNeon branches Postgres. PlanetScale branches MySQL. Layerbase branches all of them, because branching happens at the filesystem, not inside the engine. Here is how it works.
- PayloadCMS Setup: PostgreSQL or FerretDBSet up PayloadCMS with managed PostgreSQL or MongoDB-compatible FerretDB on Layerbase Cloud, and why FerretDB beats MongoDB for most Payload projects.