API‑triggered Process Model using Write to Data Store (MySQL) takes 90+ seconds for ~25 inserts into a single table

How long does this process run when triggered manually?

Did you enable activity chaining throughout the process? This should raise the priority.

Still taking 9153ms. 
Activity chaining enabled throughout the process

That's long. How long do the individual inserts take?

You write about a loop. Running nodes in a loop takes time. Did you consider writing everything in one go?

I suggest you take a look to this https://docs.appian.com/suite/help/26.3/understanding-the-health-check-report.html#slow-web-apis. As first method for improving responsiveness, make sure the a!startProcess() that is used from a Web API with isSynchronous set to false. 

1. If network round-trip time to the database is high, even 25+ single-row writes can add noticeable latency, even for a single table. 

2. The Write to Data Store Entity smart service writes one row at a time; bulk inserts/updates are not supported.[Write DSE]

3. If yours is a high latency network, consider using Execute Stored Procedure, as this will most likely improve performance.

4. Yes, make the DB inserts asynchronous and check the Health Check report, as this flags slow web APIs and points to which expressions/rules are taking the most time.

Didn't checked for individual inserts. The thing is that the same table is accessing throughout the process multiple times for retrieving, inserting and updating.

90s for 25 rows usually means the loop + repeated reads/updates are the problem, not the fact that it is one table.

Write to Data Store Entity does not bulk insert, so if you call it once per row Appian pays that cost each time. I would test 3 things first:

1. Pass the full CDT array into one Write to Data Store Entity node instead of looping.
2. Time the insert path separately from the reads/updates, since you mentioned the same table is being retrieved, inserted, and updated multiple times in the same process model.
3. If the caller does not need the DB work finished before the response, return from a!startProcess() with isSynchronous: false and let the writes finish asynchronously.

If one-array write is still slow after that, I would move the insert-heavy part to Execute Stored Procedure. That is usually the next step when network round trips or per-node transaction overhead are the bottleneck.

is this a batch call from the calling system and limited to 25 rows/hit? How many times this hit is being made per hour/ per day ? Why there is a need that only when all the inserts are made then give a response.. design should be messages received... responding back with affirmation... validation/processing should not be handled during the API call processing. if the row count is going to be more.