Ugh, what’s with the fawning over Convex? Gross. Enough with all the marketing speak. Convex SUCKS.

Studies show that the best way to know how much Convex sucks is to use it to build something cool and find out that you really like it.

That sounds hella lame though. Let’s talk about how Convex sucks instead…

No longer interested in reading words? Watch this dumb video instead.

I’m sick of learning new stuff 🤯

Us too! Now if you’d just learn this one new thing please…

Yep Convex is a new thing to learn. At least we think it’s easy to learn. If you know JavaScript or TypeScript and can wrap your head around queries and subscriptions then you’re probably set for the lifetime of your product… apart from having to relearn React all the damn time. You can learn Convex and build an AI chat app in The Tour in less time than you were planning to spend arguing on Reddit today.

At least there isn’t some huge catch you’ll run into when your app scales, apart from having to remember to add indexes where needed. The design goal for Convex is to get you to write your application in the “right” way instead of having magic query planners or half-promises that we can’t keep.

I’m going to get locked in and depend on Convex

Yeah, this could happen.

This is a tricky one. If you love Convex and build your product on it then you depend on it. That’s the problem with falling in love.

If you wanted to move off of hosted Convex then you can run the open source version but it isn’t as seamless of an experience as hosted Convex. You can also export or stream your data at any time.

Convex the company is backed by top-tier investors and has a very solid trajectory blah blah blah but if you want to chat more about business continuity for your company drop us a line.

I’m going to waste time learning “Convex” instead of something transferrable like Postgres, Terraform, and Kafka

No one reads the “skills” section on your LinkedIn. Probably what differentiates you as an engineer is all the cool stuff you’ve built, not all the tears you shed after mistyping some kubectl command.

There’s value in understanding your stack though. The higher up the stack you go the more you need to trust the stuff below it. Convex is a black box to some developers, since they don’t have to care how it’s built to be able to use it, and you’re probably not going to read the source code either.

We’d prefer to call Convex an “abstraction”, which is kinda like a black box but sounds fancier. You know you’ve encountered a good abstraction because it works so well that it feels like the bottom of the stack, even though it’s not. If you’re using Postgres, Consul or XFS you probably don’t spent too much time thinking about the design of B-Trees, consensus protocols or disk scheduling, and that’s a good thing. We think Convex is a good abstraction.

(The Convex team spent a large part of their careers thinking about the design of B-Trees, consensus protocols, and disk scheduling. Hopefully you don’t have to.)

Convex is a good fit for folks who just want their problems to go away. If you want to build stuff from scratch though you should go do that. You might be interested in how Convex works internally. Maybe you want to come work here.

It doesn’t have all the features I want

Yeah this is the problem with “batteries included” platforms like Convex. Does it have all the batteries? What if you need AAs and the remote control has AAAs in it? Where did all the AAs go? Who’s been using all the AAs? Convex includes functions, storage, http handlers, compute, text search, vector search, crons, scheduling, auth a bunch of stuff, but you’ll likely find something that’s missing.

We don’t use this phrase in our marketing because it sounds grandiose but Convex is designed to be “the operating system for app development”. See? Sounds a little grandiose. Anyway Convex includes a basic set of core features but the point is that you can build other stuff on top of it.

Some days though you wake up just want geospatial indexing, or feature gating, or a scalable waitlist, or database triggers, or push notifications, or Stripe integration, and you want someone else to build it. Wouldn’t it be great if Convex had a component system where you could just drop this stuff in and it’d run as self-contained modules the same transactional context as your application? Good idea. We’re building this.

There’s still some stuff you can’t run on Convex right now, like a giant map-reduce query. You’d have to stream data out to an analytics database and run it there. That’s annoying. Wouldn’t it be great if we also build native analytics support? Good idea too.

It might be expensive

Convex might be expensive for you. A lot of highly-paid software engineers value their time at zero and proudly spend hours trying to save a few dollars (hi Hacker News!). For other folks $25/month for Convex Pro might be a legit hardship. If you’re in either of these camps you can use the free hosted Convex plan or self-host open source Convex. If you want to run a hosted app that’s so popular that it can’t fit in the free plan but you don’t have $25 then you’re out of luck unfortunately. Stuff costs money.

Of course we’re going to tell you that the best decision you can make as a company is to focus your resources on building what uniquely differentiates your product and to waste as little time as possible building supporting infra. That sounds like marketing speak though, presumably you want some cold hard numbers. Our pricing page lists the stuff we charge for but we concede it can be hard to estimate how much Convex will cost if your app gets really popular. We’ll put together a pricing calculator soon and just reach out if you want to chat more about pricing.

It doesn’t support SQL and everyone knows SQL is the standard

We can go two ways on this one: is SQL good or is SQL necessary? Let’s argue about the first one then low-key agree on the second.

Is SQL good? Not really, for user-facing transactional applications at least. We’ve written posts, given talks, and recorded podcasts on this. We’d love to have a big ol’ debate about it. Transactions written as TypeScript functions are more expressive, type safe, predictable, and intuitive, plus you don’t need an ORM to make them usable.

Ok sure, whatever, but is SQL necessary? Maybe! It’s still the lingua franca of databases. Every now and then a Convex customer wants to point some third party service at Convex and have it communicate via SQL. Sometimes folks want to use SQL to perform analytics queries on their data too. They have to use our Fivetran or Airbyte integrations to stream data out of Convex into an analytics database.

We’re going to add support for running SQL analytics queries on a live snapshot of Convex state, plus have some plans for deep integration with Postgres for folks migrating to Convex. Stay tuned.

It doesn’t support GraphQL and everyone knows GraphQL is the… new standard

No one says this anymore. They used to say it all the time when we started building Convex. If you used to work at Facebook you can use Convex Ents.

It’s annoying to write joins in JavaScript

Have joins ever been not-annoying? RIGHT OUTER JOIN anyone? Anyway the ergonomic argument is fair; there’s no built-in join operator in Convex so you have to write stuff like this:

const posts = await ctx.db.query("posts").collect();
const comments = await Promise.all(
  posts.map(
    async (post) =>
      await ctx.db
        .query("comments")
        .withIndex("postId", (q) => q.eq("postId", post._id))
        .collect()
    )
);

The withIndex syntax is a little clumsy and it’s extra code to write. We’ll tighten up some of this syntax for Convex 2.0, especially the (q) => q.eq() stuff. Some folks use our database relationship helpers or Convex Ents to avoid this boilerplate.

Perhaps the real issue though is that it looks like this might be inefficient! That’s true. It does look inefficient, because it is inefficient, and a join in Postgres is also inefficient, even if it doesn’t look inefficient. Now’s a good time to jump to the next section, which also includes the word “inefficient”.

It’s too easy to write inefficient queries

Hmmmmmmmmmmmmmmmmmmm… but is it though?

Ideally APIs that look efficient should actually be efficient and APIs that are expensive should actually look expensive. Good APIs should be “instructive”: their use should be obvious and it shouldn’t be possible to accidentally do something dumb if you were trying your best to not be dumb.

SQL is not instructive. There’s very little correlation between how a SQL query is written and how it’s executed by the query planner. ORDER BY RANDOM() looks innocent but it’ll walk over your entire table before selecting a row. A UNION of two columns or a FULL OUTER JOIN will happily kill your database by creating an entire copy of your table in memory. Databases aren’t magic but SQL sure likes to pretend they are.

Convex tries to make expensive things like joins actually look expensive, like joins. We haven’t always got this right though, e.g., the .filter() operation which is just an unindexed table scan. In the early versions of Convex this was called .fullTableScan() which was at least annoying to type.

You probably shouldn’t worry too much that your application-level join looks like it’s going through a list of rows and then looking up another table for every row… because that’s what a join is. There’s inefficiency from crossing the boundary between TypeScript and the database multiple times but at least Promise.all lets us execute these in parallel.

Convex wants your queries to be scalable, so it enforces limits on what they can do, but that requires you to add indexes and write sensible queries. We should do a better job of sending you early warnings about queries that need an index or pagination. We’ll add that. For queries that aren’t possible to write efficiently, well those should run on our built-in analytics database, which doesn’t exist yet but will real soon.

Do you think Convex sucks in ways we haven’t mentioned? We need to hear about it! Send us a tweet or email and you might just make it onto this page.

P.S. Convex is kinda dope, you should try it.