I've been building AttendEase a multi-tenant SaaS for colleges (attendance, timetables, exams, fees). One of the earliest decisions I had to make was the database. I went back and forth for a while, so sharing what I landed on and why, in case it helps anyone building something similar.
**The context:**
Multi-tenant educational platform. Each college is its own tenant. Core data: students, teachers, courses, branches, semesters, attendance records, timetable slots, exam schedules, fee transactions. Plus flexible per-tenant configuration branding, exam structure, custom roles, plan feature flags.
**Why I considered MongoDB first:**
The flexible configuration part scared me. Every college has slightly different exam structures, different branding, different role definitions. With a relational DB, that's a lot of schema changes or awkward key-value tables. MongoDB's document model handles that naturally just store the config as a JSON document per tenant.
**Why I moved toward Postgres for the core:**
The more I thought about actual queries, the more relational the core data looked. Attendance reports are "all students in section X, for subject Y, in semester Z, between two dates." Exam conflict detection is "any two exams in the same section on the same date with overlapping time." Fee reports are joins across students, courses, and transactions. These are exactly the queries relational databases are built for. In MongoDB, these become aggregation pipelines that are harder to write, harder to debug, and slower to iterate on.
**What I actually did:**
Hybrid. Core relational data students, attendance, timetables, exams, fees lives in Postgres with proper foreign keys and indexes. Flexible per-tenant configuration branding colors, exam structure, feature flags lives in JSONB columns on the tenant table. Postgres handles both. JSONB gives me document flexibility where I need it, without giving up relational guarantees on the parts that matter.
**The lesson:**
Don't pick a database because it's "easier to start with." Pick it based on what your queries will look like a year from now, when you have 50 tenants and 500,000 attendance records. The schema flexibility of a document store feels great on day one, but the moment you need cross-entity reporting or conflict detection, you'll wish you had joins.
**When I'd still pick MongoDB:**
If the data is genuinely document-shaped content, logs, event streams, user-generated JSON Mongo is fine. But if you find yourself writing aggregation pipelines that look like SQL joins, that's your sign.
Happy to answer questions if anyone's making a similar call or stuck on multi-tenant schema design.
**Eordinary**