Why I picked Convex
Most founders reach for Postgres because it’s a proven default. I almost did. Then I priced out the things I’d actually need to build around it.
Postgres meant more composition. Convex meant faster shipping.
A bare Postgres database didn’t include everything I needed for a full backend. The Postgres ecosystem has solutions for everything that comes next: pg-boss for queues, pg_cron for scheduling, LISTEN/NOTIFY for fanout, S3 for files. The argument isn’t that Postgres can’t do these things. It’s that each one is a separate library, extension, or service to choose, operate, and keep in sync with the database. Convex includes many of these capabilities natively. Here are the five pieces I’d have to compose myself if I went with Postgres.
Realtime sync. Postgres has LISTEN/NOTIFY for server-to-server fanout, but getting updates to a connected browser still means building the bridge: a persistent connection layer, fan-out logic, a subscription protocol. None of it is the product, but it still becomes part of what you maintain.
A typed client. The frontend has to know the schema. That’s either a codegen pipeline I run on every migration, a runtime ORM, or a hand-maintained second copy of the schema in TypeScript. Pick one and account for it on every change.
A job queue. Email sends, document generation, pricelist updates, anything that doesn’t belong in the request cycle. Postgres has tables and triggers, not a first-class queue. You compose one with SKIP LOCKED + workers or by adding pg-boss, river, or graphile-worker.
File storage. Postgres can store bytes, but it’s often better to use dedicated object storage. So now I’m wiring S3, signed URLs, and lifecycle policies on top of the database I supposedly already chose.
Scheduled work. Cron jobs, scheduled exports, periodic data pulls from external APIs. Convex declares all of it in a single config. With Postgres I’m wiring a separate scheduler: pg_cron if I self-host, a managed cron service or external worker if I don’t. Either way it’s a second system to keep in sync with the database.
That’s roughly four week-long projects (for me) before I could have shipped a feature for the product. Each one is well-understood territory in 2026. Each one is also a moving target with version drift, security patches, and integration overhead. None of them is what makes QuoteLogic distinct. Postgres is the more composable option, which can be a benefit or a cost depending on the project and the team. For this project that overhead didn’t make sense.
Convex delivers everything in one folder
All of it lives in convex/. Reactive queries that re-run automatically when their data changes. Mutations as serverless functions. End-to-end types from the schema to the client without a codegen step. File storage with built-in signed URLs. Cron jobs declared in a config. A scheduled-functions API for delayed work.
It’s not “a database with realtime bolted on.” It’s the realtime, the types, the queue, the storage, and the cron all designed against the same data model. You write a query once and it streams.
How Convex pays for itself
Two places it pays back hard.
Live quote state. A deal in QuoteLogic gets touched by a rep, a Sales Ops reviewer, and a Deals Desk approver. They are not always in the same Zoom, Teams or Slack call. With reactive queries the approver sees the quote update as the rep edits it instantly. Any one of them can leave a comment and the others see it immediately. No “refresh to see latest.” No socket plumbing on my end.
Types across a heavy data model. A quote has products, line items, discount tiers, modifiers, term lengths, currency conversions, and approval state. Every one of those is shaped data. The Convex schema is the single source of truth. Rename a field and the typed backend refuses to deploy until every reference is updated. I never maintain a parallel schema in code to stay in sync with the database. The database is the schema.
Don’t use Convex if…
I’d reach for Postgres in four cases.
You’re already a year into a Postgres-shaped app. Migration risk is real and “free realtime” doesn’t pay back the rewrite. Stay where you are and bolt on the missing pieces one at a time.
Compliance demands self-hosted infrastructure. Convex is managed. That’s a feature most days and a blocker the day a regulator asks where the data lives. If “where” has to be a server you own, this isn’t the call.
The workload needs exotic SQL. Recursive CTEs, window functions on tens of millions of rows, full-text search at scale. Convex is a document store with a query API, not a SQL engine, so it’s best suited for workloads aligned to that model.
You’re betting on a ten-year horizon for a system you couldn’t migrate later. Convex is a startup vendor. The migration story is real but it’s not free, and a long horizon makes the “what if they pivot” question worth pricing in.
The first two rule out Convex outright. The last two are reasons to plan an exit you might not need to take.
Two questions I always get
Why not Supabase? It follows a Postgres-based approach with a set of integrated services like database, auth, storage, edge functions, and realtime. If you specifically want Postgres with realtime capabilities, Supabase is a strong option. For QuoteLogic, I was looking for a single mental model across everything, along with Convex’s reactive query approach.
Will Convex be the forever database? For QuoteLogic, yes. The “you’ll outgrow it for analytics” pushback assumes a system that owns the deal end to end. QL doesn’t. A quote in flight is live, collaborative, state-heavy: exactly Convex’s sweet spot. Once a deal closes, the quote data leaves QL via API to whatever system the business uses for revenue reporting. QL is a focused micro-SaaS for the in-flight quote, not a data warehouse for closed deals. The light reporting that stays inside QL (admin dashboards, usage stats) is workload Convex is actively building for. The hybrid argument applies to apps that own the whole funnel. QL doesn’t, by design.
The decision rule
Pick Convex when you’re starting from zero and want one surface for realtime, types, storage, and cron. Pick Postgres when you have a year-old codebase, a compliance requirement, or a workload SQL is genuinely better at.
The question isn’t “can I move off Convex later?” The question is “how much time can I afford to lose right now?”
The answer for a solo founder is: none.