Convex optimizing queries
Yea, I am getting acquainted with the idea that, of course I could write a slow query function, but there's some faith that Convex will know what my function is trying to do and optimize the database transaction(s) for me
9 Replies
The spirit of this is right, but for general interest: it's not that Convex will make clever optimizations, it's that querying the
ctx.db in a Convex Query function is a fast, ~1ms operation because Convex functions run "inside the database."I suppose Convex shines against, say, a Firebase project where the Firebase app makes multiple roundtrips to retrieve various Firestore documents (which by-design have no relations)
But is a Convex query function (that makes two queries to two different tables) faster than a call using Drizzle ORM to Neon that has a nested SQL select statement?
It should be roughly equivalent - SQL is doing the same thing under the hood. As an application developer you shouldn't have to worry about a few ms. I haven't (yet) heard anyone using Convex consider it slower than what they were using before
Here's some data from the very complicated AI Town project. Each of these functions is reading and writing from many tables, with various steps. You can see the code for
queryPromptData here: https://github.com/a16z-infra/ai-town/blob/main/convex/agent/conversation.ts#L242GitHub
ai-town/convex/agent/conversation.ts at main · a16z-infra/ai-town
A MIT-licensed, deployable starter kit for building and customizing your own version of AI town - a virtual town where AI characters live, chat and socialize. - a16z-infra/ai-town
one reason convex might be faster than the equivalent nexted sql statements: sql can choose not to use indexes, even if indexes are defined correctly. Even in cases where it's a single-row lookup by an index, I've observed cases where postgres and mysql will decide to scan the whole table
yes, I think the developer crowd who likes type safety also likes that Convex withIndex() method
Thanks Ian, that queryPromptData screenshot shows that each of those queries successfully hit the cache. So, even if the Postgres nested SQL statement is roughly equivalent, is it correct to to think that since the queries are cached in Convex, in real life the Convex query function is typically faster than a tech stack of Vercel+Next.js+Drizzle+Neon
Only one of those hit the cache, but that is correct.
Having the ability to consistently cache and serve data without ever touching the DB is a big selling point of Convex.
One of the reasons we could have thousands of people watching AI Town scalably is that they're all seeing data from the same cached requests. Like watching a TV broadcast, it's only recorded once. The only per-user cost is when they enter the world and interact with characters, or do any other logged-in actions.
Nice, I gave AI Town for a spin. Really good stuff.
For an app like AI Town, where data is often from requests cached in Convex, the developer can save money on Convex bandwidth costs. But would Vercel charge for that agent conversation requests as Vercel bandwidth?
All of the data is going over the Convex websocket. Vercel just loads the static assets.