Concerns About Bandwidth Usage, Caching, and Scalability Limits in Convex

[franckdsf]

Hi Convex team,

I've been migrating my app to Convex for about a month now. While it's still not in production, I've already hit the 1 GB database bandwidth threshold, which is quite concerning.

It's a web-based AI application that launches tasks to generate content. Convex has been helpful in eliminating the need for a traditional polling system to retrieve that content in real time.

Here’s some context:

• My database is only 5 MB
• My writes are only 6 MB
• But my reads are at 900 MB

Despite optimizing my queries to fetch only necessary data, caching does not seem to work as expected:

• When I refresh the browser, every 1 out of 2 tries does not hit the cache.
• Paginated queries never seem to use the cache, neither on the backend nor on the frontend — and there is currently no Convex helper for paginated caching.

This raises questions about the practicality of caching in real-world apps.

For comparison, my existing Supabase setup (with ~500 users averaging 25-minute sessions) handles:

• 200 MB database
• ~3 GB monthly egress

With Convex, based on my current trajectory, this could scale to over 600 GB/month, which is extremely high and unsustainable.

Additional Concerns

• I'm using convex-auth, and in just one month on a single account, it generated over 2,000 authRefreshTokens. At scale, this would be over 1 million refresh tokens for 500 users, which seems highly inefficient.

• When listing elements with query or paginationQuery, any update to a single element triggers a full re-send of the entire list, instead of just the updated row. This results in megabytes of bandwidth used, rather than just a few kilobytes.

Feedback & Request

• The current documentation and tutorials don’t provide clear guidance on building scalable, production-ready data fetching and caching strategies in Convex.

• We'd really benefit from official best practices for:

  • Efficient pagination with real-time updates.
  • Reducing redundant data transmission when listing or updating items.
  • Managing authRefreshTokens efficiently at scale.
  • Monitoring and optimizing bandwidth usage, especially in real-time applications.

• Additionally, the Logs tab in the dashboard needs to offer more transparency and debugging insight. Specifically, it would be extremely helpful to see:

  • Query parameters sent
  • Returned result data
  • Size of the result
  • Any internal database bandwidth used (if it contributes to the usage limits)

I'm genuinely excited about Convex, but these issues could be blockers for production use. I hope you can shed some light on whether improvements are planned around these limitations, and if not, how developers should handle them effectively.

Thanks for your work and looking forward to your response!

[franckdsf]

Another concern is Convex's current limitations when it comes to filtering and indexing arrays. While it's possible to define nested objects and arrays of IDs, you can't filter directly on individual items within those arrays — nor can you index them in a meaningful way (unless you index the entire array).

For example:

export const workspaces = defineTable({
  name: v.string(),
  userIds: v.array(v.id('users')),
})

In this case, you might want to query all workspaces where a given userId is included in userIds, but that's currently not supported at all. This makes many-to-many relationships difficult to handle and forces developers to rely on workarounds that add unnecessary complexity or increase bandwidth usage — or, fall back to using a SQL-like relational model, but without the power of SQL joins and filtering syntax.

[franckdsf]

Here is an example of my mutations and queries

import { v } from "convex/values";
import { internalMutation } from "../../_generated/server";
import { serverMutation, userMutation } from "../../procedures";
import { internal } from "../../_generated/api";

type Result = boolean

const internalArgs = {
  userId: v.id("users"),
  workspaceId: v.id("workspaces"),
}

export const _internal = internalMutation({
  args: internalArgs,
  handler: async (ctx, args): Promise<Result> => {
    const { userId, workspaceId } = args;

    // retrieve workspace
    const workspace = await ctx.db.get(workspaceId);
    if (!workspace) throw new Error("Workspace not found");

    // Check if user is already in workspace
    if (workspace.userIds.includes(userId)) { return true; }

    // Add user to workspace
    await ctx.db.patch(workspaceId, {
      userIds: [...workspace.userIds, userId],
    });

    return true;
  },
})

// This is the client mutation that will be called from the client (browser)
export const client = userMutation({
  args: { userId: v.id("users") },
  handler: async (ctx, args): Promise<Result> => {
    // Any permission checks
    // await isAllowed(ctx, {....})

    return ctx.runMutation(internal.router.workspaces.addUser._internal, {
      ...args,
      workspaceId: ctx.user.currentWorkspaceId,
    })
  }
})

// Requires a custom auth token to be passed in the args
// This is only called from the server
// and is not exposed to the client
export const server = serverMutation({
  args: internalArgs,
  handler: async (ctx, args): Promise<Result> =>
    ctx.runMutation(internal.router.workspaces.addUser._internal, args)
})

[franckdsf]

One of the main concerns is how aggressively cache invalidation is handled. Given a table shape like:

export const workspaces = defineTable({
  name: v.string(),
  userIds: v.array(v.id('users')),
})

If I update the userIds field, it invalidates all queries for that document, even queries that only retrieve and return the name of the workspace — despite the fact that the result of those queries hasn't changed at all.

This behavior undermines the value of caching. What's the point of having a caching layer if any field update invalidates all queries, even when the updated fields are irrelevant to the query results?

[ikhare]

Hello! Thanks for the super detailed question. I'll answer some of it here, though I recommend hopping on our Discord server (https://convex.dev/community) to get more thoughts on it.

Relational model and invalidation

This seems to be your biggest concern here. Query function invalidation is determined based on which records/documents change, not at a sub-document level. Convex is designed to be used as a relational data model, just with a TypeScript query language and not SQL. As you point out, the workspace user membership is a many-to-many relationship that is often molded as a join table.

I agree that out-of-the-box Convex does not provide great syntax for this, but I recommend using one of our helper libraries. This document might offer you guidance on how to express this in Convex: https://stack.convex.dev/functional-relationships-helpers

Logs

Some of the data you're asking for is available via log streams: https://docs.convex.dev/production/integrations/log-streams/. When it comes to detailed debugging, our customers often prefer more complete logging products such as Axiom or Datadog.

We don't log actual query parameters and results by default. If you want to debug that, for now, the best thing is to put in your own console.log lines. This is generally because we've erred on not implicitly logging things folks would prefer not to. Having worked in data-sensitive environments in the past, this is the right tradeoff for now.

Auth tokens

Similar products, such as Clerk, refresh every 5 minutes, while Convex Auth refreshes every hour. In practice, we haven't seen this be a problem for our customers so far, but let us know if you're seeing major problems.

Pagination refreshes

Since Convex caches and invalidates at the query level, based on when a dependent record changes, when a record causes a query page to invalidate, that whole page is invalidated and refreshed. I'd look at why the documents are being invalidated as often as you see. I suspect this goes back to the first point about properly modeling your data in a relational fashion.

I hope this helps. Since you have multiple concerns, you may find it easier to chat about them in the Discord community (https://convex.dev/community), where many people can chime in and help.

[franckdsf]

So just to confirm — this query will still be invalidated when updating the project status, even though I'm not retrieving the status field at all?

import { defineTable } from "convex/server";
import { v } from "convex/values";
import { query } from "../../_generated/server";
import { Id } from "../../_generated/dataModel";

export const PROJECT_STATUS = v.union(
  v.literal("ready"),
  v.literal("processing"),
  v.literal("completed"),
);

export const projects = defineTable({
  name: v.string(),
  status: PROJECT_STATUS,
});

type GetProjects = Array<{ _id: Id<'projects'>, name: string }>;

export const getProjects = query({
  args: {},
  handler: async (ctx): Promise<GetProjects> => {
    const projects = await ctx.db.query("projects").collect();
    return projects.map((project) => ({ _id: project._id, name: project.name }));
  },
});

If that's the case, it means I have to extract the status field into a separate table just to avoid unnecessary invalidation — and then create another query with an index to fetch it:

export const projects = defineTable({
  name: v.string(),
});

export const projectsStatus = defineTable({
  projectId: v.id('projects'),
  status: PROJECT_STATUS,
}).index("by_project_id", ["projectId"]);

export const getProjectStatus = query({
  args: { projectId: v.id('projects') },
  handler: async (ctx, args) => {
    const project = await ctx.db
      .query("projectsStatus")
      .withIndex("by_project_id", (q) => q.eq("projectId", args.projectId))
      .unique();
    if (!project) throw new Error("Project not found");
    return project.status;
  },
});

This raises another question: do internal queries like this count toward database bandwidth usage?

It feels like a lot of overhead just to work around a limitation in the cache invalidation model — especially when the actual query result remains unchanged.

[franckdsf]

I made a post in the community Discord to better highlight the caching system issues.
Without any mutations — just by waiting a few minutes — the cache stops working.

[franckdsf]

@ikhare I also shared screenshot of the refreshSession being triggered more than once an hour 🤔.

Also, as you can see it creates thousands of refresh tokens for no reason (I'm using the same browser, only one session, always signed in).

----- that was actually irrelevant, but I'm wondering why we don't delete old authRefreshTokens

[ikhare]

I see you got a lot of clarity in the Discord post. Thanks for moving the conversation there!

RE Auth: IIUC, we also refresh the token on a reconnection. So if you're in development, you'll see many of these since you're likely constantly reconnecting. I could be off here, @thomasballinger will know more.