One App, Three Databases: Benchmarking PostgreSQL, MongoDB and SQLite on a Real School Workload
Students pick a database because a tutorial used it. Build the same school management backend (admissions, attendance, fees, results) on PostgreSQL, MongoDB and SQLite, generate a realistic workload, and compare correctness under concurrency, query speed, schema change effort, backups and hosting cost. The result is an evidence-based guide to choosing a database for a typical local business app.
Beginner
Achievable by one student in a semester with familiar tools.1 semester · 2 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- One API specification for a school system implemented three times, sharing the same tests
- A data generator for a realistic school (for example 2,000 students over three years) and a workload model: daily attendance, fee payment rush at month end, result day traffic
- Concurrency tests: two clerks recording the same fee payment, simultaneous seat allocation, and what each database does by default
- Benchmarks for typical queries (a student's history, a class's monthly attendance, defaulter lists) with indexes designed for each database
- A schema change exercise (adding siblings and discounts) with time and risk recorded for each database
- Backup and restore drills with timings
- A written decision guide: which to choose for which kind of app, and why
If you have time left
- Adding a hosted serverless database option
- A reporting workload on DuckDB fed from the main database
- Offline sync for a branch campus
The problem: database choice by tutorial
Ask a final-year student why their project uses MongoDB and the honest answer is often "the course used it". Ask another why PostgreSQL and the answer is "everyone says it is better". Real projects need a reason: data shape, consistency needs, reporting, team skills, hosting and cost.
School and tuition management systems are a good test case. They are common local software products in Pakistan and beyond, with clear relational data (students, classes, fees), bursts of traffic and money that must add up.
What already exists and the gap
- Standard benchmarks such as YCSB and TPC-C measure databases under generic workloads.
- Vendor comparisons are written by vendors.
- Opinion posts compare databases without running anything.
The gap is a fair, reproducible comparison on one realistic app that students recognise, covering not only speed but correctness, schema change and operations.
Inspiration
Jepsen's analyses of distributed databases showed how much can be learned by testing what databases actually do under concurrent access, rather than what the documentation implies. Your project applies a beginner-friendly version of that habit to everyday business software.
What you build
- Three backends behind one API and one test suite.
- A workload that mimics a real school's month.
- Experiments on concurrency, queries, schema change and backups.
- A decision guide.
The technically interesting part
- Correctness first. What happens when two payments for the same student arrive at once? Transactions, unique constraints and write concerns differ by database.
- Fair indexing. Design indexes properly for each database before comparing speed.
- Change cost. Measure how long a realistic schema change takes, including migrating existing data.
How you will evaluate it
- Correctness tests passed or failed for each database under concurrency.
- p50 and p95 latency for typical queries at your workload.
- Time and steps for the schema change and the restore drill.
Path to a product
The school backend itself can become a product, and the evidence-based guide is a valuable piece of writing for your portfolio. Small software houses also value engineers who can justify architecture choices with data.
Scope warning
Keep the feature set small and identical across the three versions. Use generated data, never real student records.
Learn what you need on Sefism
- Choosing databases roadmap: how to choose a database from requirements.
- Choosing databases cheat sheet: the trade-offs in one page.
- SQL databases roadmap: transactions, indexing and query plans.
- MongoDB roadmap: document modelling and indexes done properly.
- PostgreSQL documentation: transaction isolation and constraints.
- Designing Data-Intensive Applications: the chapters on transactions and data models.
- Should I use PostgreSQL or MongoDB for my project?: the decision your benchmark should inform.
- Should I use Firebase or Supabase for my app?: the hosted backend version of the same choice.
Get help with this idea
The risk is a biased comparison. Tauseef can help you design fair experiments and write a guide people trust. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.