Support for Geo Queries Within Main Query Structure

[armanhadifatah]

Description:

Currently, geo queries in Convex are implemented as a completely separate system from the main query engine. This separation creates unnecessary complexity, especially for real-world applications where spatial data is just one of many filtering dimensions.

For example, in a real estate app, we often need to query properties based on multiple criteria such as:

Number of bedrooms

Price range

Property type

AND location (latitude/longitude radius)

Right now, combining a geo query with these other filters is cumbersome because the geo query is treated as a distinct system, almost like querying a separate database. This limits composability and makes the developer experience more fragmented.

Proposal:

Unify geo queries with the main Convex query system, so spatial filtering can be composed directly alongside other standard filters. This would significantly simplify use cases involving geospatial data and make Convex more suitable for location-based apps.

Benefits:

Easier to build apps with combined filtering (e.g., "Find nearby apartments under $1000/month with 2+ bedrooms")

Cleaner, more intuitive developer experience

Better alignment with real-world use cases where location is just one of many filters

[ikhare]

Thanks for a well-written request.

This, unfortunately, is not a design goal of Convex. Convex is designed to compose your code at the function level, rather than pushing complex query patterns into the internal query engine. The reasoning is that incorporating this level of complexity into the main query path obscures the work the system is doing, making it incredibly difficult to reason about performance. The reality is that your database is doing all the work you are writing in code here, and you now have complete control over what it's doing. In fact, for our 2.0 of the query language, we're going to make it even simpler and more explicit.

That said, you can build an abstraction in your code that does this for you. You can hide this work behind a module in your code or class that treats inserts and queries as a higher-level concept, presenting them as a single entity. For example, you can create a class called Properties that has various functions to insert, update, and query your entity that decompose into relevant Convex functions. This way, you can achieve the ergonomics you want throughout the rest of your project that interacts with this data, and you can still modify how the queries are run.