One of our goals here at Convex is to provide the right level of functionality at the right time in your application’s journey. From the prototype where you want to side step binding decisions to a mature high usage application with many developers, we strive to provide the right tools at each step of your journey.

We’ve all used tools that are easy to get started with, but after a certain level of complexity their tooling or abstractions break down on some critical dimensions (think untyped languages for building large applications). Or we’ve used tools that feel like they require a PhD to even understand what they’re talking about (what’s a transclusion anyways?)

We hope that Convex is easy to get started, and then provides easy to use “power tools” as your application grows both in terms of developers and complexity.

Here are a few areas where this philosophy shows up in Convex:

## Schema (less-ish)

When you are first getting started, you may not fully know the schema of your application. You’ll just be stuffing data into tables. You’ll throw together different screens, you’ll test your application with your users, and only over time will find product market fit, that blissful state when users are clamoring to use your product. By this time you’ll learn what your application is truly about and only then want to formalize your schema. This is particularly helpful as your team grows larger, and your application gets a bit more sophisticated.

Turns out Convex has been tracking your schema all along! You can see it in the Convex dashboard by clicking on the Schema button next to each table. You can then take that Schema and decide to enforce it. Using schemas in Convex will only get better, stay tuned for some new features in this space soon!

![The messages schema](https://cdn.sanity.io/images/ts10onj4/production/7cc06b8db9a68d1da9053a13f27848207062edac-2000x1143.png?w=450)

## Indexes

Similar to schemas, indexes are more useful as you learn the performance characteristics of your app. For example, let’s say you have a Users table. But turns out you’re often querying it by email rather than by `Id` (the default index). Once you get enough users (yay! congrats!), you may find that this query by email is a performance bottleneck. At this point you’ll probably want to add a `by_email` index to speed up that query.

We’re actively working on adding custom indexes to Convex. Watch this space for an update in the near future. This is another great way we’re ensuring that you have all the tools you need to work with your data as your app scales.

## Caching

All Convex functions are [deterministic](https://docs.convex.dev/understanding/convex-fundamentals/functions#determinism). One great side effect of this is that it’s very easy to cache a query’s output. Convex does this automatically for you! If you call the same query again with the same set of inputs, you will get the data back faster because it’s already cached. Even better, if you’re subscribed to a query then we update that query only when the dependencies change, and then cache the results. There is no excess computation or data fetches due to polling or multiple requests for the same query.

Put another way, you don’t have to worry about whether your cache is valid or not, you just get the benefits without any extra work. This means as more people use your app the more the cache is used. Convex’s performance scales to your usage.

We hope this makes Convex the right product to chose for your application’s data needs. You don’t have to worry about the system locking you into a decision that seems convenient at first but is a headache to deal with later. We’d love to get your feedback on how we can make these decisions easier, [join our Discord](https://convex.dev/community).

You don’t have to worry about the platform locking you into a decision that seems convenient at first but is a headache to deal with later.

Indy Khare

All posts by Indy