Vercel WebSockets and Neon live queries. When data needs a second and when a minute will do

In October several platforms announced real-time features at once. Vercel took WebSocket support in its functions out of beta, Neon made SQL queries live, Stripe started writing payments straight into Postgres at Supabase and Neon, and Netflix described how it rebuilt its ads event pipeline for live broadcasts. For a business owner there is one question behind all of this: which data in the company has to update within a second, which can wait a minute, and which is fine with a nightly export. The answer decides what the system costs and in how many places it can stall.

What came out and from whom

On October 20, Vercel wrote in its changelog that WebSocket support in Vercel Functions is now generally available. Since the public beta launched in late June, their CDN has served 300 million connections, and the current rate is 15 million a day. Connections are billed like ordinary function invocations, and on the Active CPU pricing the processor time counts only while a message is being handled.

On October 15, the Neon blog ran a short note saying Neon Realtime is in public beta: any SQL query can be made live, you subscribe to it, and the result updates as the data changes, with no polling.

Supabase on October 15 described how Stripe Data Pipeline syncs Stripe data to Supabase. You connect it from the Stripe dashboard. Stripe loads the history, then keeps the data current: payments, refunds, disputes, customers, subscriptions and invoices arrive as tables in a separate schema with the stripe_sdp prefix. Stripe connects with its own role that can reach only that schema, using short-lived tokens and no database password. On October 16, Neon reported the same thing for its Postgres: connection from the Stripe dashboard and live payment data next to the application data.

Netflix on October 14 published part two of its story about the ads event pipeline. Before, the ad server wrote metadata to a global registry synchronously on every impression and waited for confirmation. For live broadcasts that didn't work: more than 100 million viewers watched the Jake Paul vs. Mike Tyson fight, and a single ad break would have meant millions of mandatory database writes per second on the critical path. Netflix engineers replaced the database write with a streaming connection to Apache Flink: the server logs what it showed, and the matching with device events happens afterward. A storage failure no longer stops the ad from running.

Example: a rental company with three data speeds

Take a car rental company. The manager at the handover desk checks whether a car is free and what inspection photos it has. He needs the state as of right now: if two bookings for the same car drift apart by a minute, the customer waits at the counter. The accountant reconciles yesterday's payments, and a morning export is enough for that. The fleet utilization board in the office can lag by a minute and nobody will notice.

If you push every stream through WebSockets, you pay for connections for the sake of a board that would be fine with a query once a minute. If you batch everything overnight, the manager at handover will be calling a colleague to ask whether someone took the car. Netflix has the same problem at a different scale: every mandatory synchronous step on the way to the customer has to be justified.

How I pick the channel

At the PDR company in the US that I have worked with since 2021, the TV boards on 4 televisions update in real time: the owner, production, the front desk and the salespeople see the workload and the movement of orders. A call to the IVR creates a lead in the CRM right away, because a delay there costs a customer. The super app for salespeople, on the other hand, is built offline first: on a site visit the salesperson takes photos and works the lead without a connection, and the app syncs the data once the connection is back.

For a consulting company in London, in 2023 I built Scraper Hub, a service that collects news from 120 sources. The interface showed the progress of a run over WebSockets, because a person started the collection and waited for the result. In the order calculation program for a manufacturing company, the server and the client are also connected over WebSocket: a calculation takes 65 seconds on average, and the design engineer sees what is going on.

In the “Coffee Together” service, the supplier catalog syncs on a schedule, up to three runs a week. The order total appears after the organizer has checked the real cart. Nobody needs a one-second update there, and a permanent connection to the supplier's API would add places where things can break. I haven't tried Vercel's WebSockets, Neon's live queries or the Stripe pipeline myself and go by their descriptions.

What I would do

Write down the data streams in the company and, for each one, put a price on a one-minute delay and a one-hour delay.

For the one-second streams, use WebSockets or a live query, but with a fallback: when the connection drops, the client requests the full state again.

For the one-minute streams, run a background worker with retries and protection against double processing.

Take external services off the critical path. If the payment system or the CRM is down, the car handover continues, and the data catches up later.

Count the cost: on a platform you pay for connections the way you pay for function invocations; on your own server they cost memory and attention to limits.

I covered background jobs and retries in the article on workers and in the review on reprocessing without a repeated result. Projects from this review: the PDR company, Scraper Hub and order calculation for manufacturing. On the TVs and the leaderboard there is a review about metrics that teach a team bad decisions, on the price of platforms a review of backends on Vercel, Fly and Supabase, on observability on a single server this one. Service areas: internal systems and API integrations. If you have data that should update faster than it does now, tell me which data and why. Discuss your task.