PostgreSQL or MariaDB — what I ask before choosing

The honest starting point

For most of the systems I work on, either database would work. The decision is usually about the environment around it: what the host already runs, what the team knows, and which features the domain actually needs.

Questions

What does the host already run?

If the server already has MariaDB for other applications, adding PostgreSQL means another service to patch, back up, and monitor. That cost is real and often larger than any feature difference.

Does the domain need specific types?

PostgreSQL is comfortable with jsonb, arrays, ranges, and richer indexing. If a schema genuinely benefits from those, the choice is easier. If it is plain relational data with normal indexes, the argument is weaker.

What does the ORM support well?

Drizzle, Prisma, and Laravel’s ORM all support both, but not identically. Migration generation, type inference, and handling of generated columns differ. I check the ORM before committing.

Who operates it after me?

A database that the next person cannot back up and restore is a liability. Familiarity is a feature in a small team.

What is the concurrency profile?

Write-heavy transactional workloads and read-heavy content workloads stress different parts. For a university site, reads dominate. For an exam submission window, writes spike.

Where I have landed

• TOEFL Prediction System: PostgreSQL, because the exam data model benefits from strong constraints and the JSON handling is useful for exam payloads.
• Existing content systems: MariaDB or MySQL, because they were already there and the schema is straightforward.

That is not a universal rule. It is a record of decisions made in context — which is how database choices should be written down.

Open questions

• A small migration checklist for moving a MariaDB schema to PostgreSQL without downtime.
• How much of the choice should be encoded in the ORM configuration versus documented separately.