---
title: Make your SashiDo app fast
group: Run it
nav: Performance
updated: 2026-11-13
description: Speed up a Parse Server app on SashiDo. Faster queries and indexes, lighter cloud code, the right engine and number of instances, auto-scaling, high availability and a current Parse Server version.
keywords: parse server performance, parse server slow queries, mongodb indexes parse, parse server scaling, cloud code performance, parse server high availability, sashido engine, parse server auto scaling
---

Most slow apps are slow in the same few places: queries that read too much, cloud code that does too much per request, and an engine sized for last year's traffic. Fix them in that order. More hardware won't save a query that scans a million objects.

## Measure first

- **Metrics** in the dashboard show requests, traffic, the database and the engine's CPU and memory over time. A busy CPU with few requests points at code; a busy CPU with many requests points at capacity.
- **Core › Logs**, or "show me the errors from the last hour" to your assistant: timeouts and slow-query errors name the class and the query.
- **App Checks** in the dashboard, or `get_app_advice` through [MCP](/en/docs/developers/mcp), flag problems in the database and its configuration.

## Queries

**Ask for less.** Select the fields you show and cap the results:

```javascript
const query = new Parse.Query('Post');
query.equalTo('author', user);
query.select('title', 'createdAt');   // not the whole object
query.descending('createdAt');
query.limit(20);
const posts = await query.find();
```

**Page with a cursor, not `skip`.** `skip(10000)` makes the database read and throw away 10,000 objects. Remember the last item you showed and continue after it:

```javascript
query.lessThan('createdAt', lastPost.get('createdAt'));
```

**Avoid what can't use an index:**

- `matches` (regex) that isn't anchored at the start (`^`), or that ignores case;
- `doesNotExist`, `notEqualTo` and `notContainedIn` on large classes;
- `count()` on large classes on every page load: keep a counter instead, updated in an `afterSave`;
- `containedIn` with thousands of values.

**Load related objects once.** `include('author')` fetches the authors in the same request. Fetching each in a loop is one request per row.

**Index what you filter and sort by.** MongoDB needs an index for each common query shape, e.g. `author` + `createdAt` for the query above. Without one, every request scans the class. Each index also slows writes a little, so index the queries you actually run, and build indexes on large classes at a quiet time. Not sure which index a slow query needs? Ask your assistant to look at the query and the class, or ask our support.

## Cloud code

- **Keep triggers short.** A `beforeSave` runs on every save, and the client waits for it. Validate and set fields there; move slow work (emails, calls to other services, recalculations) to a background job.
- **Batch writes.** `Parse.Object.saveAll(objects)` instead of `save()` in a loop.
- **Don't fetch what you already have.** `request.object` holds the saved object, and `request.original` its previous version.
- **Use the master key only where needed** (`{ useMasterKey: true }`). It skips permission checks, which also hides missing indexes behind "it works for me".
- **Move heavy work to background jobs.** Backfills, reports and cleanups belong in a job you schedule (**Core › Jobs**), not in a function a client waits for.
- **Watch for unbounded loops.** A `find()` without a limit returns 100 objects; code that "loops until done" over a growing class gets slower every week.

## Engine and instances

Your app's server runs on an **engine** (the CPU and memory of each instance) and a number of **instances** that share the requests. Both are under **Runtime › Engine**, and your assistant can change them with an `apps:write` token.

- **A bigger engine** helps with CPU-heavy cloud code and large responses.
- **More instances** help with more concurrent requests, and let one instance restart without your users noticing.
- **Auto-scaling** (on engines that support it) adds instances under load, between the minimum and maximum you set, and removes them when it's quiet. Set the minimum for your normal traffic and the maximum for your peaks.

Engine and instance changes are billed, and only the app's owner can make them.

## High availability

With **high availability** on, your app always runs at least three instances, with health checks: an instance that stops answering is restarted while the others keep serving. Turn it on for production apps where minutes of downtime cost more than the instances. Turning it on or off resets the scaling limits, so check them afterwards.

## Region

Run the app in the region closest to most of your users: every request crosses that distance at least twice. The region is chosen when you create the app; to move an existing app, contact our support.

## Parse Server version

Newer Parse Server versions run on newer Node.js, with performance and security fixes. If your app is still on 2.x to 4.x, an upgrade is often the biggest speed-up available. Plan it with `plan_parse_server_upgrade` (see [Build with AI](/en/docs/developers/build-with-ai)): it lists what your cloud code needs to change first.