Skip to main content
April 15, 2026
Question

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

  • April 15, 2026
  • 7 replies
  • 0 views

Hello Community,

I am facing a performance issue with an API‑triggered Process Model that writes data to a MySQL database using the Write to Data Store Entity smart service.

[emoticon:e7b6666c6f9742b1b7b51dddab3bb696] Scenario

  • An external system invokes an Appian Web API.
  • The API starts a Process Model.
  • The Process Model creates a case by inserting ~25+ rows into a single database table.
  • Inserts are done using Write to Data Store Entity (CDT‑based).
  • The API response is sent only after the Process Model completes.

[emoticon:e7b6666c6f9742b1b7b51dddab3bb696] Issue

  • Total API response time is 90+ seconds.
  • The process completes successfully and returns "Successful", but the latency is too high for synchronous API calls.
  • Since all records are inserted into one table, this delay seems unexpected.

[emoticon:e7b6666c6f9742b1b7b51dddab3bb696] Current Design 

  • API → Process Model
  • Multiple Write to Data Store Entity executions (likely one per record / loop)
  • Inserts are mostly sequential
  • Backend database: MySQL

[emoticon:e7b6666c6f9742b1b7b51dddab3bb696] Questions

  1. Is it expected for Write to Data Store Entity to take this long when inserting ~25 rows into a single table?
  2. Does Appian open a separate transaction / commit for each Write to Data Store execution?
  3. Would performance improve by:
    • Passing all 25 records at once in a single Write to Data Store node?
    • Using a database stored procedure for bulk inserts?
  4. In API scenarios, is it recommended to:
    • Immediately respond to the API
    • And continue DB inserts asynchronously in the background?

    7 replies

    stefanhelzle0001
    April 15, 2026

    How long does this process run when triggered manually?

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

    April 15, 2026

    Still taking 9153ms. 
    Activity chaining enabled throughout the process

    stefanhelzle0001
    April 15, 2026

    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?

    alex.acosta
    April 16, 2026

    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.

    taylorb547622
    April 19, 2026

    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.

    subhankarb6682
    April 30, 2026

    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.