If you’ve ever tried to prepare for a SQL interview, you know the drill. You read up on CTEs and Window Functions, maybe you watch a few tutorials, but when it comes time to actually practice, things get annoying fast.
You either have to install PostgreSQL locally and mock up your own tables, or you use an online platform that is slow, clunky, and locks the good questions behind a massive paywall because "running servers is expensive."
When I decided to build DataCurlew, I wanted to solve that. I wanted a place where anyone could practice real MAANG SQL interview questions instantly. But I didn't want to go bankrupt paying AWS for thousands of secure Docker containers every time a user ran a SELECT statement.
So, I decided not to build a backend at all.
Here is how I built a full SQL code-execution platform entirely in the browser.
Pushing Compute to the Edge (Literally, Your Browser)
The traditional way to build a SQL execution platform is:
- User types SQL code in the browser.
- Code is sent over the network to a backend server.
- A secure, isolated container spins up.
- The code runs against a real database.
- The results (or syntax errors) are sent back over the network to the user.
This approach introduces latency, scaling headaches, and massive compute costs. Every time you run a query, the company pays for server time.
Instead of doing that, I brought the database to you.
WebAssembly (WASM) is the Magic
I leveraged WebAssembly (WASM) to run the database engine directly inside your browser tab.
I use PGlite, which is literally a full PostgreSQL database compiled to WASM. When you load a challenge on DataCurlew, I create an in-memory PostgreSQL instance right in your browser, seed it with the test data, and run your queries against it locally.
(Note: I also support Python/Pandas via Pyodide, using the same browser-native logic!)
The result? Execution is practically instant. There is no network latency because your SQL query never leaves your laptop. And because I don't have to pay for backend compute to run your queries, I can afford to keep the platform accessible to people who actually need it.
The Rest of the Stack
Of course, I still need to authenticate users, save their progress, and serve the website. Here is how the rest of the puzzle fits together:
1. The Frontend (React + Vite + Zustand)
I kept it simple. It's a standard React Single Page Application (SPA) built with Vite for speed and Tailwind CSS for styling. For state management, I skipped Redux and used Zustand—it's incredibly minimal and gets out of my way. I don't even use a heavy router library; I rely on the native browser History API to keep the bundle size small.
2. State & Auth (Supabase)
Supabase acts as my "backend as a service." It handles Google OAuth, email logins, and stores your progress (which SQL challenges you've solved) via Postgres Row Level Security (RLS) policies. When you successfully solve a challenge in your browser's local PGlite database, I just send a quick ping to Supabase to mark it as complete.
3. Hosting (Cloudflare Pages)
Because my entire app is just a collection of static files (HTML, JS, CSS, and the WASM binaries), I host it on Cloudflare Pages. It is distributed globally on the edge, meaning the initial load is blazing fast no matter where you are in the world.
4. Payments (Lemon Squeezy)
If you decide to upgrade to Premium, I use Lemon Squeezy as my Merchant of Record. They handle all the nightmare scenarios of global tax compliance (VAT, GST) and fraud prevention. When a payment clears, they ping a Supabase Edge Function webhook, which flips your is_premium flag to true.
Why This Matters
I didn't build it this way just to flex modern web tech. I built it this way because it aligns with my primary goal: helping people land jobs.
By eliminating backend compute costs, I don't have to charge exorbitant subscription fees to keep the lights on. I don't have to limit how many queries you can run in a day. You can sit there and tweak your LEFT JOIN a hundred times in a row, and it won't cost me a dime.
The gap between college theory and industry reality is wide enough. Practicing SQL for your interview shouldn't be the hardest part of the process.
(If you're currently preparing for an interview, come try out the WASM engine yourself at datacurlew.in. I built a free curriculum covering everything from basic aggregation to advanced Window Functions.)
Top comments (0)