Convex Backend

Convex is an open-source reactive database built specifically for web app developers who want to build dynamic, live-updating applications without juggling separate backend services, REST APIs, or WebSocket management. It unifies a database, server-side function runtime, and client libraries into a single cohesive system, letting developers write queries and mutations in pure TypeScript that execute directly on the server with strong consistency guarantees.

At its core, Convex implements a reactive subscription model: when database records change, all subscribed clients receive automatic real-time updates without polling. The backend is written in Rust for performance, while user-defined functions run in secure V8 JavaScript isolates that provide controlled access to the database through a typed syscall interface. This architecture enables deterministic, strongly-consistent execution that avoids eventual consistency pitfalls common in distributed databases.

Convex supports self-hosting via Docker or prebuilt binaries, with storage backends including SQLite (default), PostgreSQL, Neon, and MySQL. The built-in dashboard and CLI let teams manage deployments, monitor function logs, run queries, and administer databases without external tooling. Advanced capabilities like vector search, file storage, scheduled jobs, cron functions, and snapshot exports are all first-class features rather than add-ons.

The project is backed by the Convex team and kept in sync with internal development. While community contributions are welcomed for bug fixes and documentation, the Convex team maintains strong control over API design to ensure product coherence. A generous free tier on the cloud platform makes it accessible to solo developers and side projects, while self-hosting provides full control for production workloads.

What You Get

• Real-Time Reactive Queries - Write TypeScript queries that automatically push live updates to all connected clients whenever underlying data changes, with no polling or WebSocket boilerplate required.
• Pure TypeScript Server Functions - Define queries, mutations, and actions in TypeScript that run directly on the Convex server with full type safety, eliminating the need for a separate REST or GraphQL API layer.
• Built-In Vector Search - Perform semantic similarity searches against embedding vectors stored natively in Convex, enabling AI-powered features without an external vector database.
• File Storage with Reactive Queries - Store and serve files (images, PDFs, documents) directly through Convex with transactional metadata and reactive query integration for live file state.
• Scheduled Jobs and Cron Functions - Define recurring background tasks and one-off scheduled functions directly in TypeScript, managed by the Convex runtime with automatic retry and observability.
• Self-Hosting with Docker or Binaries - Deploy the full Convex backend and dashboard on your own infrastructure using Docker Compose or prebuilt binaries, with support for SQLite, PostgreSQL, Neon, and MySQL backends.
• Snapshot Export and Import - Export full database snapshots with binary object management for backups and migrations, or stream data to external systems via the export engine.
• Secure Isolated UDF Runtime - User-defined functions execute in sandboxed V8 JavaScript isolates with a controlled syscall API, preventing side effects outside the Convex runtime boundary.

Common Use Cases

• Building real-time collaborative tools - A product team builds a shared whiteboard where multiple users see each other’s changes instantly, using Convex reactive queries to sync cursor positions and drawing state without managing WebSocket infrastructure.
• AI-powered applications with vector search - A developer builds a document Q&A app that stores OpenAI embeddings in Convex vector indexes, querying semantically similar content in real time as users type their questions.
• Live dashboards and analytics UIs - A SaaS company powers a customer-facing metrics dashboard that updates in real time as backend events are written to Convex, without polling or separate streaming infrastructure.
• Self-hosted backend for regulated industries - A healthcare startup self-hosts Convex on their own AWS infrastructure using Docker and PostgreSQL to meet data residency requirements while retaining the developer experience of the cloud product.
• Chat and messaging applications - An indie developer builds a multi-room chat app with typing indicators, read receipts, and message history using Convex reactive subscriptions and scheduled functions for notification delivery.
• Background job processing pipelines - An engineering team uses Convex scheduled jobs and cron functions to orchestrate data sync pipelines, report generation, and third-party API polling without a separate task queue system.

Under The Hood

Architecture Convex is structured as a Rust monorepo with over sixty internal crates organized by bounded domain: authentication, database, function execution, file storage, vector search, exports, search indexing, and more. The core database crate implements a snapshot-based MVCC model with a dedicated SnapshotManager that maintains read-consistent views at multiple timestamps, enabling concurrent queries without locking. The subscription system tracks per-query read sets and uses async channels to fan out invalidation notifications when document writes commit, achieving reactive updates through pure event-driven signaling. The local backend sits atop the Application layer, routing HTTP and WebSocket traffic via Axum while delegating to typed domain services, with middleware handling authentication and deployment state validation cleanly at the routing boundary.

Tech Stack The backend is written in Rust using Axum for HTTP and WebSocket handling, with Tokio as the async runtime and an async-first design pervasive through all crates. User-defined functions run in V8 JavaScript isolates managed by the isolate crate, with a custom syscall interface bridging TypeScript user code to Rust database internals. Storage backends are pluggable: SQLite via rusqlite for local development and single-node deployments, PostgreSQL and MySQL via async drivers for production. Vector search uses Qdrant segment internals for in-process nearest-neighbor indexing. The TypeScript client library (versioned at 1.41.0) is built with esbuild and ships with full type definitions, while the dashboard is a Next.js application providing a complete admin interface for self-hosted deployments.

Code Quality The codebase demonstrates comprehensive investment in correctness: backend crates make extensive use of Rust’s type system to encode invariants at compile time, and the function runner and isolate layers have specialized test harnesses for UDF execution scenarios. The npm packages include integration tests, UDF unit tests, scenario runners, and simulation suites that exercise end-to-end behavior. TypeScript code is linted via ESLint with strict rules and formatted with Prettier; Rust code enforces rustfmt and dprint. CI enforces linting and type checking across both the Rust and TypeScript layers. The open-source repository omits some proprietary randomized test suites used internally, which the README acknowledges transparently.

What Makes It Unique Convex’s core innovation is treating reactivity as a first-class database primitive rather than a bolt-on. The subscription engine tracks exact read sets per query and invalidates only affected subscribers on writes, providing reactive updates with strong consistency semantics—a combination most databases force developers to implement manually with polling or optimistic UI tricks. The seamless full-stack type flow, where TypeScript functions defined on the server are directly callable as typed hooks from React without any code generation step, collapses the traditional frontend-backend boundary. Built-in vector search as a native index type (rather than a separate service) and the component model enabling hierarchical, typed function exports as reusable building blocks further distinguish Convex from conventional databases paired with API layers.

Self-Hosting

Convex is released under the Functional Source License 1.1 (FSL-1.1-Apache-2.0), which is a source-available license with a time-delayed open-source component. The FSL grants broad rights to use, modify, and redistribute the software for any purpose except competing use—meaning you cannot use Convex to build and offer a commercial product or service that substitutes for Convex itself. After two years, each release automatically converts to the Apache 2.0 license. For internal use, self-hosted production deployments, non-commercial education, and research, the FSL imposes no meaningful restrictions, making it suitable for most developer and startup scenarios. However, if you are building a managed database platform or a backend-as-a-service offering, you would be in competing use territory.

Self-hosting Convex requires deploying and operating three services: the Rust backend binary (or Docker container), the Next.js dashboard, and your own frontend. The backend defaults to SQLite for simplicity but can be pointed at a PostgreSQL, Neon, or MySQL database for durability and scale. File storage can be configured to use S3-compatible storage for exports, snapshots, modules, and search indexes. Persistent volume configuration, TLS termination, authentication setup, and database backups are all your responsibility as the operator. The team notes that Convex is battle-tested primarily on Linux and macOS, with less production experience on Windows. Horizontal scaling of the Convex backend itself is not straightforward; the architecture is optimized for a single high-throughput node rather than multi-node clustering.

Compared to the managed Convex Cloud, self-hosting gives up the zero-maintenance experience, generous free tier, automatic scaling, managed upgrades, and official SLA-backed support. Cloud support is available through Discord’s #self-hosted channel only—there is no enterprise support tier for self-hosted deployments. The cloud product also includes features like team management, usage dashboards, and deployment previews that the self-hosted dashboard may lag behind. Developers evaluating self-hosting should weigh the FSL’s competing-use restriction carefully and factor in the operational burden of managing persistent storage, backups, and uptime for a stateful system.