Limits of $limit=0 for No‑Op Responses in FeathersJS Services

Short answer

No. Setting $limit: 0 in a FeathersJS query does not reliably avoid database interaction. For the officially supported Sequelize, Mongoose, and Knex adapters, the value is passed through to the underlying store as a LIMIT 0 (or .limit(0)) clause, and a query is still executed — it simply returns an empty result set. There is no short-circuit in these adapters that skips the round-trip when the limit is zero.

Likely explanation vs. confirmed behavior

The likely explanation for the confusion is the documentation's focus on pagination defaults: omitting $limit falls back to an adapter-specific default (commonly 10 or 100), so setting $limit: 0 feels like it should mean "fetch nothing." What is confirmed by adapter behavior is that "fetch nothing" still means "ask the database for zero rows" — the connection is acquired, the statement is planned and executed, and an empty array (or paginated envelope with total) comes back.

Note that third-party or community adapters may behave differently. Only the Sequelize, Mongoose, and Knex adapters are covered here; verify any other adapter against its source before relying on this.

Verifying it yourself

Enable query logging and call find with $limit: 0:

// Sequelize: new Sequelize(..., { logging: console.log })
// Mongoose: mongoose.set('debug', true)
// Knex: knex({ ..., debug: true })

await app.service('messages').find({ query: { $limit: 0 } });
// Expect a SELECT ... LIMIT 0 (or equivalent) in the logs

If the goal is a true no-op (e.g., a cheap existence or count probe), use an explicit hook that returns early instead of relying on $limit: 0.

Enforcing a global maximum $limit

Register an application-level before hook that clamps the limit for every service, rather than configuring each service individually:

app.hooks({
  before: {
    find: [
      (context) => {
        const MAX = 100;
        const q = context.params.query;
        if (q && typeof q.$limit !== 'undefined' && Number(q.$limit) > MAX) {
          q.$limit = MAX;
        }
        return context;
      }
    ]
  }
});

Caveats: this affects every find call, so services that legitimately need larger pages should be exempted (check context.path or a custom flag) or override the value in their own hooks, which run after app-level hooks.

Cost of very low limits

Using $limit: 1 or 2 when the client ultimately needs the full dataset multiplies the number of round-trips. Each page still incurs connection overhead, query planning, and network latency, so total cost rises roughly linearly with page count. For large exports, prefer a higher limit, cursor-based pagination, or streaming rather than tiny pages.

Bottom line

$limit: 0 gives you an empty payload, not a free request — the database is still hit on Sequelize, Mongoose, and Knex. If you need a genuine no-op, implement it as an early-returning hook; if you need cost control, clamp $limit globally and choose page sizes that balance payload size against request count.