Two libraries, two different jobs
Almost every Delphi developer has used Indy at some point. It ships in the box with the IDE, it has been around since the late 1990s, and a generation of Delphi networking code is built on TIdHTTP, TIdTCPClient, TIdSMTP and friends. sgcWebSockets is a much newer commercial library focused on the protocols that have appeared since Indy was originally designed — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — plus a large catalogue of REST API integrations.
The most common question on the Embarcadero forums and Stack Overflow is some variation of “Why would I pay for sgcWebSockets when Indy is free?”. The short answer is that they solve different problems, and in many real projects you will end up using both. This article walks through the practical differences in 2026 so you can decide which one (or which combination) fits your application.
What each library actually does
Indy is a general-purpose TCP/UDP toolkit with a long list of classic Internet protocols: HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois, plus a TCP server framework. Its design is thread-per-connection and blocking I/O. There is no native WebSocket client or server in stock Indy — you have to bolt one on, and several community projects do exactly that with mixed results.
sgcWebSockets is a focused, protocol-rich library aimed at modern client/server scenarios. It is organised around a core TsgcWebSocketClient / TsgcWebSocketHTTPServer pair with optional add-ons for HTTP/2, HTTP/3 over QUIC, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT (CoAP, AWS IoT, Azure IoT), end-to-end encryption, and 30+ API wrappers (OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp, etc.).
An important and often missed detail: sgcWebSockets uses Indy internally as one of its transport backends. The TCP/TLS plumbing for several components is an Indy TIdTCPClient / TIdHTTPServer underneath, so installing sgcWebSockets does not replace Indy — it builds on top of it. The library also offers alternative transports (Synapse-style, ICS, SChannel) for scenarios where Indy is not the best fit.
Feature-by-feature comparison
| Feature | Indy (stock) | sgcWebSockets |
|---|---|---|
| HTTP/1.1 client | Yes (TIdHTTP) | Yes (TsgcHTTPComponentClient, can use Indy or ICS backend) |
| HTTP/1.1 server | Yes (TIdHTTPServer) | Yes (TsgcWebSocketHTTPServer, handles HTTP + WS on same port) |
| WebSocket client/server | No native support | Full RFC 6455, permessage-deflate, subprotocols, autobahn-tested |
| HTTP/2 (h2 + h2c) | No | Yes, custom HPACK + frame layer |
| HTTP/3 / QUIC | No | Yes (msquic-based) |
| MQTT 3.1.1 and 5.0 | No | Yes, client and broker |
| AMQP 1.0 / 0.9.1 | No | Yes |
| STOMP, SSE, WAMP | No | Yes |
| WebRTC / P2P / STUN / TURN | No | Yes |
| CoAP and IoT cloud (AWS, Azure) | No | Yes |
| OpenAI, Anthropic, Gemini, MCP | No | Yes, dedicated components |
| FTP / SMTP / POP3 / IMAP | Yes | No (use Indy for those) |
| Free / commercial | Free, MIT-style | Commercial, several editions incl. Free |
| Delphi versions | D7 and up (varies per fork) | D7 through D13 |
| Active maintenance | Community (IndyProject on GitHub) | Vendor, monthly releases |
Where Indy still wins
If your project is a classic Internet client — download a file over HTTP, post a form, send an SMTP email, fetch mail over IMAP, talk to an old FTP server — stock Indy is the right answer. It is free, it is bundled with the IDE, the API is familiar, and you do not need anything else. The same goes for hobby TCP servers and protocols Indy ships natively (NNTP, IRC, Telnet, Whois). For those use cases, adding a paid library is overkill.
Indy is also the obvious choice when you must interoperate with code that already uses Indy types — for example, components that expect a TIdSSLIOHandlerSocketOpenSSL or an TIdHTTPServerCommandHandler.
Where sgcWebSockets is the right tool
Anything involving the modern web stack is significantly easier with sgcWebSockets. Concretely:
- WebSocket — full-duplex messaging is a first-class feature. The server handles HTTP and WebSocket on the same port, manages subprotocols, supports compression, and integrates with the auto-reconnect WatchDog out of the box.
- HTTP/2 and HTTP/3 — required for Apple Push Notifications, Google services, and a growing number of REST APIs that have started to enforce h2 minimum. Indy has no answer here.
- Messaging brokers — MQTT 5, AMQP 1.0, STOMP, WAMP and SSE all ship as ready-to-use components with TLS, reconnection, and authentication.
- Real-time multimedia — WebRTC, ICE, STUN, TURN and DTLS-SRTP for browser-compatible audio/video and data channels.
- AI and cloud APIs — OpenAI, Anthropic, Google Gemini, AWS, Azure, Telegram, WhatsApp, Stripe and a few dozen others are wrapped as typed components instead of raw REST calls.
Performance and scaling
Indy's thread-per-connection model is simple and correct, but it caps practical throughput around a few thousand concurrent connections on a typical Windows server before context switching becomes the bottleneck. sgcWebSockets offers the same Indy backend for compatibility, plus an IOCP-based server transport on Windows that has been benchmarked at tens of thousands of concurrent WebSocket connections per process. For pure HTTP throughput the difference is smaller, but for long-lived connections (WebSocket, MQTT, SSE) the architectural gap matters.
Memory footprint per idle connection is also lower with the IOCP transport because there is no dedicated OS thread per socket. On Linux the picture is similar with epoll-based servers via the Indy fork sgcWebSockets ships.
Maintenance and release cadence
Indy is maintained by a small group of volunteers on the IndyProject GitHub repository. Releases are slow but the codebase is stable. Critical fixes (TLS compatibility, modern OpenSSL bindings) do land but not always quickly.
sgcWebSockets is a commercial product from eSeGeCe with monthly releases, a public history file, and direct vendor support. New Delphi versions are typically supported on day one — Delphi 13 was supported from the first beta — and new protocol revisions (MQTT 5.0.1, HTTP/3 final, MCP spec updates) ship in days rather than years.
License and pricing
Indy is free and ships with Delphi. sgcWebSockets is commercial but has a Free Edition for non-commercial use, plus paid editions (Standard, Professional, Enterprise, All-Access) with progressively wider protocol coverage. Most commercial projects can justify a single-developer Professional licence with a single deployed customer.
A simple decision rule
A pragmatic 2026 rule of thumb:
- Use Indy for SMTP/POP3/IMAP/FTP, for short-lived HTTP downloads inside an existing Indy codebase, or for any classic Internet protocol that Indy already handles natively.
- Use sgcWebSockets the moment WebSocket, HTTP/2, HTTP/3, MQTT, AMQP, WebRTC, IoT or any AI/REST API enters the picture, or when you need a server that scales beyond a few thousand connections.
- Use both in the same project — that is in fact the most common pattern. Indy stays for the email and FTP layer, sgcWebSockets handles the real-time and modern-API layer, and they share the same Indy SSL/IO infrastructure underneath.
Closing thoughts
Indy is not going anywhere — it is the trusty hammer in every Delphi toolbox. But the protocols that define the 2026 internet (WebSocket, HTTP/2/3, MQTT, WebRTC, AI APIs) simply did not exist when Indy was designed. sgcWebSockets fills that gap with a focused, actively maintained, commercially supported library that builds on Indy where useful and replaces it where necessary. For new projects targeting modern back-ends, the question is no longer Indy or sgcWebSockets? — it is how do I combine them?