Why Choose Convex Instead of a SQL Backend?

TL;DR

Convex can replace much of the traditional backend work surrounding a React application by combining database access, synchronization, and supporting libraries. The creator adopted it after initially dismissing it as a tool for toy projects, then found that it improved type safety, data handling, development confidence, and the user experience enough to power T3 Chat and most of his subsequent projects.

Transcript

This is one of those videos that people have been waiting for for a while. We're here to talk today about my new favorite database provider, backend, sync engine, set of libraries, and so much more. Of course, we're talking about Convex, the database that I migrated to kind of twice at this point, and all the reasons that I have slowly fallen in lo... Read More

Key Insights

• Convex is presented as more than a database provider because it also supplies backend functionality, synchronization, libraries, and much of the infrastructure outside a React frontend. This integrated scope changed how the creator structured applications and reduced his need to assemble separate data-handling components.
• The creator's first assessment of Convex was that it primarily served toy applications and beginners who wanted to assemble projects quickly. He later regretted holding that opinion for so long, while acknowledging that the product was still at an early stage when he first encountered it.
• Convex became the backend solution for all of T3 Chat and most projects the team built afterward. The adoption followed a gradual reassessment rather than immediate enthusiasm, with trusted developers using the product helping motivate the creator to give it a serious evaluation.
• The original motivation behind the T3 Stack was cultural as well as technical. The creator had developed through the LAMP, MEAN, and MER eras and wanted a modern stack abbreviation that represented a particular moment, development style, and community in a similarly recognizable way.
• The creator adopted Next primarily because its API directory simplified packaging and deployment of TypeScript backend functions. His decision was not initially driven by Next's broader feature set, but by the practical advantage of keeping frontend code and deployable backend endpoints within one application.
• The central development problem was moving data from backend code into React while preserving its correct shape and behavior. Defining endpoints separately, fetching them with React Query, and coordinating types created enough friction that the creator designed his own alternative workflow in July 2021.
• The use backend proposal placed backend logic directly beside React code so TypeScript could infer the returned data type during development. At compilation, the proposed system would separate frontend and backend responsibilities while retaining the type information and convenient authoring experience.
• The proposed compiler would generate a React Query call, a matching API endpoint, JSON response handling, and optional server-side prefetching through getServerSideProps. These generated pieces aimed to improve type safety, composability, reliability, deployment convenience, and server-rendering performance without repetitive manual integration work.

Questions & Answers

Q: Why did the creator move from SQL-style backends to Convex?

The creator moved toward Convex because it combined several responsibilities he previously handled through separate backend functions, database tooling, data-fetching libraries, and synchronization logic. After initially dismissing it, he found that its integrated model improved how he built applications, increased his confidence in the resulting experiences, and worked well enough to become the foundation for T3 Chat and most later projects from his team.

Q: What is Convex used for in a React application?

Convex is described as handling much of a React application's non-frontend work. Its role includes acting as a database provider, backend, synchronization engine, and collection of supporting libraries. Instead of requiring developers to connect several independent tools for storage, endpoints, data movement, and updates, it offers a more unified way to structure those responsibilities around the frontend application.

Q: Why was the creator initially skeptical of Convex?

The creator first encountered Convex around 2021 and quickly concluded that it was not intended for his needs. He viewed it as a solution for toy applications and beginners who wanted to put something together quickly. He later acknowledged that Convex was still very early at that time, but regretted retaining that original judgment instead of reevaluating the product sooner as it developed.

Q: What changed the creator's opinion about Convex?

The creator began taking Convex more seriously after people he trusted started using it, according to the description. A proper evaluation then showed that the product addressed longstanding concerns about backend structure, data delivery, and application development. His opinion changed gradually, eventually reaching the point where Convex powered all of T3 Chat and most of the team's subsequent work.

Q: What backend problems was the use backend proposal designed to solve?

The use backend proposal was designed to reduce the friction of defining an endpoint, calling it with React Query, and separately ensuring that frontend code understood the returned data shape. It aimed to place backend logic near React code, infer types directly, generate the network boundary during compilation, and support optional server-side prefetching without requiring developers to manually coordinate every layer.

Q: How would the proposed use backend system work?

A developer would write a use backend call in React code, assign it a unique key, execute the necessary backend operation, and return the data. During development, TypeScript could infer the frontend data type from that nearby return value. At compilation, the system would generate a React Query call, create a matching endpoint, handle JSON responses, and optionally generate getServerSideProps integration for prefetched data.

Q: Why did the creator originally adopt Next?

The creator originally moved toward Next because its API directory made deployment easier. He had been using React, Vite, React Query, and separate TypeScript backend functions hosted through an API directory. Next could package those endpoints within the same application, reducing deployment friction. He explicitly characterized this as a decision motivated by deployment convenience rather than by the broader capabilities associated with Next itself.

Q: How did prior GraphQL experience influence the creator's backend preferences?

At Twitch, the creator used GraphQL with code generation and became accustomed to reliable type definitions. When later building with endpoints and React Query, he missed having that dependable connection between backend results and frontend expectations. This experience shaped his preference for tools and architectures that preserve data shapes, improve type safety, and reduce the manual coordination required across application boundaries.

Summary & Key Takeaways

• The creator initially dismissed Convex after encountering it around 2021, viewing it as a convenient solution mainly for toy applications and beginners. After trusted developers began using it and the product matured, he reconsidered that judgment. Convex eventually became the database and backend foundation for T3 Chat and most projects his team built afterward.

• His interest in simpler backend development predates Convex. While building the application that became ping.gg, he disliked defining separate endpoints, calling them through React Query, and maintaining reliable data shapes. Experience with GraphQL code generation at Twitch had shown him the value of consistent types shared between backend operations and frontend consumers.

• A 2021 proposal called use backend captured his desired workflow. Developers would place backend logic near React code, infer returned TypeScript types directly, and let compilation generate endpoints, React Query calls, JSON handling, and optional server-rendered data. Convex appealed because it addressed many of the same concerns through a more integrated backend model.