A detailed, URL-by-URL comparison of the old MongoDB platform and the new PostgreSQL platform—what improved, where it improved, how stable it is under the test matrix, and what we should measure next.
The same page addresses were tested in both systems. On the matched set, the new PostgreSQL system returns responses much faster on average and shows less variation from one virtual-user column to another.
Think of the old system as a delivery truck that has to collect many boxes from different warehouses, sometimes getting stuck in traffic. The new system is closer to a well-organized express railway: the information is structured, indexed, and retrieved through a more direct route. The analogy describes the observed outcome; the CSV alone cannot prove which internal mechanism caused each slowdown.
These headline metrics use the Average_Time_ms value for each matched URL. Percentiles describe the distribution across URL averages, not all individual HTTP request samples. This keeps the old and new comparisons like-for-like.
| Metric | MongoDB | PostgreSQL | Change | Plain-English meaning |
|---|
Average latency alone can hide slow pages. Percentiles show how the experience changes across the full set of URLs: p50 is the middle URL, p95 means 95% of URL averages are at or below that value, and p99 focuses on the slowest one percent.
Lower bars are better. Values are milliseconds.
Percentage reduction calculated from old versus new URL-average distributions.
The median explains the ordinary experience. The p95 and p99 matter because users do not all visit equally simple pages. A student opening a complex exam syllabus or a college admissions page can experience the slow tail even when the site-wide average looks acceptable. Reducing the tail protects the quality of the experience for those high-friction visits.
This section groups matched URLs by the page type provided in the CSV. It compares the average, median, p95, p99, and maximum URL-average latency so that we can see both typical performance and the outliers within each section.
| Page type | Matched URLs | Mongo mean | Postgres mean | Speedup | Reduction | Mongo p50 | Postgres p50 | Mongo p95 | Postgres p95 | Mongo max | Postgres max |
|---|
Speedup is the ratio of old mean latency to new mean latency. A 5× speedup means the old mean took five times as long as the new mean. Percentage reduction measures the fraction of old latency removed. Categories with a small number of URLs—especially News—should be interpreted with caution because a few pages can strongly influence their averages.
The CSV has ten response-time columns per URL. We calculate the mean for User 1 across all matched URLs, then User 2, and so on. If the line rises sharply, later columns are slower in aggregate. A flatter line suggests more consistent latency across this matrix.
| User column | Mongo mean (ms) | Postgres mean (ms) | Difference (ms) | Mongo vs U1 | Postgres vs U1 |
|---|
We also compare the User 1 to User 10 drift within each page type. This reveals whether a category remains stable across the ten columns or has a more pronounced rise.
| Page type | Mongo U1 | Mongo U10 | Mongo drift | Postgres U1 | Postgres U10 | Postgres drift |
|---|
Some MongoDB user-cell values reach exactly 15,000 ms, which is consistent with a timeout ceiling in the test configuration. We count those cells directly instead of assuming that every slow row timed out.
| Page type | URL path | Mongo URL avg | Postgres URL avg | Mongo max user cell | Postgres max user cell | Speedup |
|---|
A timeout count refers to individual user cells at or above 15,000 ms, not the number of unique URLs. One URL can contain more than one such cell.
The following table ranks URL pairs by old-to-new average latency ratio. It is useful for identifying the most dramatic before-and-after examples and prioritizing regression monitoring.
| Rank | Page type | URL path | Mongo avg | Postgres avg | Speedup | Milliseconds saved | Reduction |
|---|
Keep these URLs as regression checks. The highest-speedup pages are not necessarily the most visited pages; combine this list with analytics traffic and business value to decide which routes deserve the strongest performance alerts.
Good analysis also checks the remaining slow tail. These are the URLs with the highest new-system URL-average latency. They are candidates for targeted query-plan inspection, payload review, cache-hit analysis, or application profiling.
| Page type | URL path | Mongo avg | Postgres avg | Speedup | Postgres max user cell |
|---|
On complex pages, the application may have needed to retrieve large documents or combine related records through multiple lookups or aggregation stages. If queries read more data than the page needs, or if the application performs many round trips and transformations, total response time can rise.
A relational design can store related entities in normalized tables, use indexes to locate the relevant rows, and join related data in a planned query. Fetching only the columns and rows the page needs can reduce unnecessary work.
Redis can serve repeated cacheable reads quickly and reduce repeated database work. The result depends on cache hit rate, TTL, invalidation correctness, key design, and the amount of data cached. These CSVs do not separate cache hits from misses, so Redis-specific response times or its share of the improvement cannot be calculated from this matrix.
Lower server response time can help improve Time to First Byte (TTFB), which can support a better Largest Contentful Paint (LCP) when server waiting is a meaningful part of the page load. A 392 ms average benchmark latency is encouraging, but it is not itself a TTFB or LCP measurement. Google’s “good” TTFB guidance is generally 800 ms or less; ranking effects depend on real-user Core Web Vitals, content relevance, competition, and other signals.
Pages that respond in hundreds of milliseconds feel more immediate than pages that take multiple seconds. This can reduce friction as students move between college profiles, courses, fees, exams, and admission details. The exact effect on bounce rate or leads must be measured in the real funnel; this benchmark cannot establish a conversion uplift on its own.
Shorter request durations may reduce how long resources are occupied and give the platform more headroom. But capacity is a throughput question. Run a ramp test and measure requests per second at the target p95 latency, error rate, CPU, memory, database connections, and cache hit ratio before claiming 5×–10× more concurrent students.
Better query efficiency can postpone scaling or allow smaller resource footprints for the same workload, but the CSVs contain no server cost, CPU, memory, or throughput telemetry. Cost savings should be quantified from cloud bills and resource metrics before and after the change.
| Area | Measure | Why it matters |
|---|---|---|
| Real-user experience | TTFB, LCP, INP, p75 by template/device | Confirms whether test gains reach real visitors. |
| Business funnel | Landing-to-detail clicks, lead starts, completed leads, enquiries | Connects performance to business outcomes. |
| Capacity | Requests/second, p95/p99, errors, saturation | Shows safe traffic headroom. |
| Database | Query duration, plans, rows scanned, pool wait | Finds remaining slow routes and regressions. |
| Cache | Hit ratio, miss latency, invalidation correctness | Ensures speed does not come at the cost of stale data. |
These extra views are calculated from the matched URL records embedded in this report. They help explain not just the average improvement, but how consistently the migration helped across pages.
Share of matched URLs that became faster, stayed similar, or became slower.
Counts of URLs by speedup band. This shows whether gains were broad or concentrated in a few outliers.
Total milliseconds saved across all matched URLs, grouped by page type.
Number of matched URLs whose new average response falls within each range.
Interpretation note: the ten virtual users are concurrent samples from this test matrix, not a production traffic forecast. A faster response is a measured result; extra revenue, SEO ranking changes, and safe capacity multipliers require production evidence.
This is the detailed appendix: one row per matched URL, with the old and new average latency, speedup, milliseconds saved, percentage reduction, and all ten user-cell values from both systems. Use the search and filters to investigate any page.
| URL path | Type | Mongo avg | Postgres avg | Speedup | Saved ms | Reduced % | MongoDB User 1–10 (ms) | PostgreSQL User 1–10 (ms) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
All user values are preserved from the source CSVs where present. Empty cells represent missing/non-numeric values in the source data; they are not converted to zero.
| Check | Value |
|---|