People occasionally ask why Knight LTD projects tend to combine Vercel, Firebase, and now Turso, instead of picking one all-in-one backend platform. It's not indecision — each piece is doing a specific job, and the combination has held up well across dozens of small-to-medium projects.
Vercel: hosting and serverless functions
Vercel handles static hosting and serverless API routes. For a vanilla HTML/CSS/JS frontend, this means we can deploy instantly, get a global CDN for free, and add lightweight backend logic (form handlers, auth checks, database calls) as individual functions without running a persistent server.
Firebase: realtime data and auth for interactive apps
For products that need realtime updates — a tournament bracket updating live, a chat feature, presence indicators — Firebase's Firestore and Realtime Database are still hard to beat for how quickly they let you wire up live UI updates without building a WebSocket server yourself. Firebase Auth also remains a solid default for email/password and social login when a project needs full user accounts.
Turso: SQL where a document store is the wrong shape
Not every dataset fits Firestore's document model well. Anything relational — notices with an active/inactive flag queried and ordered by date, contact form submissions you might want to filter and export, waitlist entries with uniqueness constraints — is simpler to express and query correctly in SQL. Turso gives us libSQL (a SQLite-compatible engine) with an HTTP API that works cleanly from serverless functions and even from Cloudflare Workers, without needing a persistent TCP connection.
A concrete example: the notice ticker
The scrolling notice bar you see across Knight LTD pages is a good example of "right tool for the job." It's a small, structured table (id, message, active, created_at) that needs simple filtered, ordered queries. That's a textbook SQL use case — trying to force it into a realtime document listener would be more code for no real benefit, since the ticker doesn't need sub-second live updates.
Cloudflare Workers: for the edge-critical paths
When a route needs to respond from the nearest edge location with minimal cold-start latency — like a public read-only API — a Cloudflare Worker calling Turso's HTTP API directly is often faster and cheaper than a full serverless function on a different platform. We use Workers selectively, not as a replacement for Vercel functions everywhere.
When this stack is the wrong choice
This combination isn't universal advice. If a project genuinely needs complex relational joins across large datasets with heavy write concurrency, a managed Postgres instance with a proper ORM is a better foundation than stitching together multiple lightweight services. And if a team already has deep expertise in one platform (say, fully committed to Supabase or AWS), consistency often beats theoretically "optimal" tool selection.
The underlying principle
Pick infrastructure per data shape and access pattern, not per platform brand loyalty. Realtime UI state goes where realtime listeners are cheap. Relational, queryable, exportable data goes where SQL is natural. Static assets go on a CDN. It adds a small amount of operational complexity — more services to configure environment variables for — but each piece stays simple, replaceable, and easy to reason about on its own.