sometimes the database is fast, but the api is still slow.
i had an endpoint that returned products with nested relational data.
the database query was finishing in a few hundred milliseconds. but the api response was taking around 3 to 4 seconds, and sometimes even more during heavier traffic.
i checked the query. it was fast. i checked the database. it was fine. then boom.
the issue was not the database. it was orm hydration.
when an orm gets rows from the database, it may not return them directly. it can create entity objects for every product, build nested relation objects, map fields, convert dates and json, run transformers, and create a huge amount of javascript objects in memory.
this is convenient when you need full entities and business logic around them. but for a large read-only endpoint, it can become expensive very quickly.
request timing looked something like this: • database query: a few hundred ms • orm hydration and object mapping: 1 to 2 seconds • json serialization and response processing: 1 to 2 seconds • total api time: around 3 to 4 seconds, sometimes more
the database had already finished. node.js was still busy turning database rows into a huge nested response.
so i played around with a raw query instead of loading full orm entities with all the fancy relation loading functions.
the raw query returned plain rows with only the fields the frontend needed.
less entity creation. less relation mapping. less memory usage. less serialization work.
key points: • fast sql does not always mean a fast api • orm hydration happens after the database query finishes • loading full entities can be expensive for large read endpoints • raw queries or lightweight selects can return plain rows faster • return only the fields the frontend needs • measure database time and application processing time separately
So yah yah. sometimes the slowest part is not getting data from the database. it is what your application does with that data after it arrives.