Nostr Relay Implementations Compared

Nostr Relay Software Overview

Running a Nostr relay means choosing software that determines your throughput ceiling, storage costs, spam resilience, and operational complexity. Five implementations dominate the self-hosted relay landscape: strfry (C++/LMDB), nostr-rs-relay (Rust/SQLite), Khatru (Go/pluggable), nostream (TypeScript/PostgreSQL), and the managed hosting service relay.tools. Each targets a different operator profile, from hobbyists running a personal relay on a VPS to organizations operating high-throughput public infrastructure.

The following table summarizes the key differences. Detailed breakdowns of storage, NIP coverage, spam filtering, and deployment follow below.

Storage Backends and Performance

Storage backend choice affects write throughput, query latency, disk usage, and backup strategy. The three models in use across these relays are embedded key-value stores (LMDB), relational databases (PostgreSQL, SQLite), and pluggable interfaces.

LMDB (strfry)

strfry stores all events in LMDB, a memory-mapped B-tree that requires no external database process. Reads are zero-copy and writes are synchronous: strfry only returns an OK message after the event is committed to disk. This design delivers the highest raw write throughput among the relays compared here, at the cost of requiring enough address space for memory mapping (64-bit systems only). LMDB files are not human-readable and require strfry's own export tooling for backup, though the database supports online snapshots.

SQLite (nostr-rs-relay)

nostr-rs-relay uses SQLite as its primary store, keeping everything in a single file with WAL (write-ahead logging) mode enabled for concurrent reads. SQLite's backup tooling is mature: the .backup command works while the relay is live, and compressed backups typically achieve roughly 4:1 ratios. The tradeoff is lower write throughput compared to LMDB, and SQLite's single-writer lock can become a bottleneck on relays with heavy ingest. An experimental PostgreSQL backend exists but is not recommended for production.

PostgreSQL + Redis (nostream)

nostream requires PostgreSQL 14+ for persistent event storage and Redis for caching, rate limiting, and pub/sub notification. This stack gives operators access to PostgreSQL's query planner, full-text search, and replication tooling, but raises the base memory footprint to approximately 150 MB and adds operational overhead: two external services to monitor, patch, and back up. Docker Compose is the recommended deployment path.

Pluggable (Khatru)

Khatru is a relay framework, not a turnkey relay. Operators supply their own storage backend by implementing StoreEvent and QueryStored hooks. Community relays built on Khatru use SQLite, PostgreSQL, and BadgerDB. This flexibility means performance depends entirely on the chosen backend and how the hooks are implemented. Khatru itself adds minimal overhead beyond WebSocket handling and filter evaluation.

NIP Support Coverage

Nostr's protocol is defined by NIPs (Nostr Implementation Possibilities). Relay operators care most about which event kinds and protocol extensions their software supports, since unsupported NIPs silently drop events or refuse queries. The table below lists key NIPs and which relays implement them. NIP support evolves rapidly: verify against each project's current README before deploying.

Khatru's "Via hooks" entries mean the framework provides the plumbing, but the operator must implement the logic. This is powerful for custom relays but requires Go programming knowledge. strfry's NIP-77 negentropy sync is particularly valuable for relay operators who need to synchronize event databases across multiple instances: it efficiently determines the set difference between two relays without transferring the full event corpus.

Spam Filtering and Moderation

Public relays face persistent spam: bots publishing garbage events, impersonation attempts, and high-volume flooding. Each relay offers different tools for defense.

strfry uses an external write policy plugin architecture. The relay pipes each incoming event through a configurable executable that returns accept, reject, or shadow-reject. Three community plugins dominate: Spamblaster (Go, pulls policy from a remote URL with 60-second refresh), Chief (Rust, pubkey and word blocklists via JSON or PostgreSQL), and Noteguard (pipeline-based filter chains with per-pubkey rate limits). Operators often pair these with fail2ban rules that block IPs after repeated rejections.

nostr-rs-relay has minimal built-in filtering. Rate limiting requires a reverse proxy like nginx or Caddy in front of the relay. Its simplicity is intentional: the relay focuses on correctness and low resource usage rather than policy enforcement.

Khatru exposes RejectEvent and RejectFilter hooks that let operators write arbitrary validation logic in Go. NIP-13 proof-of-work checks, pubkey allowlists, and content analysis can all be implemented as hook functions. The framework also supports NIP-42 authentication natively, enabling authenticated-only relays.

nostream includes built-in rate limiting via Redis and supports paid admission through Lightning payments. Operators can connect a payment provider API key to gate access: users pay a one-time admission fee, and their public key is added to an allowlist. This model directly addresses spam economics by making event publishing cost money.

Relay Operator Economics

Running a relay costs money: compute, bandwidth, storage, and the operator's time. The question is whether those costs can be recovered, and how.

Self-hosted relays on a basic VPS (2 vCPU, 4 GB RAM, 80 GB SSD) cost roughly $10-25/month depending on provider and region. strfry and nostr-rs-relay can run comfortably on this hardware for small to medium-sized relays. nostream's PostgreSQL + Redis stack benefits from more RAM: budget $20-40/month for moderate traffic.

relay.tools offers managed hosting starting at 7,000 sats with monthly costs around 12,000 sats. Relay owners who accept payments from users can apply that revenue toward their hosting balance, creating a self-sustaining loop.

Bitcoin-Native Monetization with NWC

Nostr Wallet Connect (NWC) enables Bitcoin-native relay monetization without traditional payment processors. NWC uses Nostr events as a transport layer for Lightning Network payment instructions: a client sends a payment request event to a user's wallet service, which executes the Lightning payment and returns a response event. For relay operators, this means accepting zaps and admission fees denominated in satoshis, with settlement measured in seconds rather than days.

The paid relay model works as follows: the relay requires NIP-42 authentication, verifies that the connecting pubkey has paid the admission fee via a Lightning invoice, and adds the pubkey to an allowlist. nostream has the most mature implementation of this flow. For deeper coverage of how NWC enables remote Lightning payments across Nostr applications, see our Nostr Wallet Connect research article.

Relay economics remain challenging. Most public relays operate at a loss or break even. Paid relays generate some revenue but limit their audience. The emerging model is a hybrid approach: free for reading, paid for writing, with NIP-13 proof-of-work as a fallback for unpaid users. This mirrors the economics of Bitcoin node operation, where infrastructure providers absorb costs to support the network while exploring sustainable revenue models.

Deployment and Operations

Deployment complexity varies significantly across these implementations. The choice depends on your team's operational expertise and infrastructure preferences.

• strfry requires a C++20 compiler and a handful of system dependencies. It supports hot-reloading configuration and zero-downtime binary upgrades, making it suitable for production environments that need continuous availability. Docker images are community-maintained.
• nostr-rs-relay compiles to a single Rust binary with no external dependencies beyond SQLite (typically bundled). Setup is straightforward: download or compile the binary, create a config file, and run. This is the simplest path for operators who want a relay running in minutes.
• Khatru requires writing Go code. There is no turnkey binary: you import the framework, implement your storage hooks and policies, then compile and deploy your custom relay. This is appropriate for developers building specialized relays (DVM relays, group relays, NIP-29 communities).
• nostream ships a Docker Compose stack that brings up PostgreSQL, Redis, and the relay in one command. This is the easiest Docker-based deployment. Standalone installation is possible but requires manually configuring PostgreSQL and Redis.
• relay.tools removes deployment entirely. Operators use a web panel to configure their relay, set moderation rules, and manage billing. A self-host installer script is also available for operators who want the relay.tools management interface on their own infrastructure.

How to Choose a Nostr Relay Implementation

The right relay depends on your use case, technical skills, and operational budget.

Choose strfry if you need the highest possible write throughput and are comfortable with C++ compilation. It excels at high-volume public relays and multi-relay synchronization via NIP-77 negentropy. Its write policy plugin system provides flexible spam filtering without modifying the relay source code.

Choose nostr-rs-relay if you want the lowest resource footprint and simplest setup. At ~30 MB base memory and a single binary with SQLite storage, it is ideal for personal relays, small community relays, or operators running on constrained hardware. The tradeoff is fewer built-in features and reliance on reverse proxies for rate limiting.

Choose Khatru if you are a Go developer building a custom relay with specific business logic. Its hook-based architecture lets you implement arbitrary event validation, custom storage backends, and specialized NIP support. Projects like NIP-29 group relays and NIP-90 DVM relays commonly use Khatru as their foundation.

Choose nostream if you want a feature-complete relay with built-in paid admission and Docker-based deployment. Its PostgreSQL backend supports complex queries and scales well with standard database tooling. The higher resource requirements (150 MB+ base memory, external PostgreSQL and Redis) are the tradeoff for operational convenience.

Choose relay.tools if you want a relay without managing infrastructure. It handles deployment, updates, certificates, and billing for a monthly fee in sats. This is the fastest path from zero to a functioning relay.

For comparison with other Bitcoin layer-2 and payment protocols, see our Nostr Zap comparison tool and the Nostr Bitcoin identity and payments research. Bitcoin-native payment infrastructure like Spark can complement relay operations by enabling fast, low-cost stablecoin and BTC transfers for relay admission fees and zap-based monetization.

Frequently Asked Questions

What is the fastest Nostr relay software?

strfry consistently benchmarks as the fastest mainstream relay for raw write throughput due to its LMDB storage engine and C++ implementation. Newer competitors like Airfry and Magnitude Relay report even higher numbers (4-10x strfry's throughput in self-reported benchmarks), but these are less widely deployed. For most operators, strfry's performance is more than sufficient: the bottleneck is usually network bandwidth or client-side limits, not relay write speed.

How much does it cost to run a Nostr relay?

A basic self-hosted relay on a VPS costs $10-25/month. strfry and nostr-rs-relay run comfortably on 2 vCPU / 4 GB RAM instances. nostream needs more resources due to PostgreSQL and Redis: budget $20-40/month. relay.tools managed hosting costs approximately 12,000 sats/month after a 7,000-15,000 sat initial payment. Storage grows linearly with the number of events stored: a relay with one million events typically uses 1-3 GB of disk depending on event sizes and the storage backend.

Which Nostr relay has the best spam filtering?

strfry has the most mature spam filtering ecosystem through its write policy plugin architecture. Plugins like Spamblaster, Chief, and Noteguard provide pubkey blocklists, rate limiting, content filtering, and remote policy synchronization. nostream offers a different approach with built-in paid admission via Lightning, which addresses spam at the economic layer. Khatru offers maximum flexibility through custom Go hooks but requires development effort.

What is NIP-77 negentropy sync and why does it matter?

NIP-77 defines a set reconciliation protocol based on the negentropy library. It lets two relays efficiently determine which events one has that the other lacks, without transferring the entire event database. strfry and Khatru support it. This is critical for relay operators running multiple instances, mirroring public relays, or building archival infrastructure. Without negentropy, syncing relays requires re-downloading and checking every event, which scales poorly beyond a few hundred thousand events.

Can I make money running a Nostr relay?

Most public relay operators do not profit. Paid relays using Lightning admission fees can offset costs, but the user base willing to pay is small. The most sustainable models combine free read access with paid write access, supplemented by NWC-powered zap revenue. Some relay operators fund their infrastructure through community donations or grants from organizations like OpenSats. Relay operation is best understood as infrastructure contribution rather than a business.

Should I use Docker or bare metal for my Nostr relay?

Docker is simpler for initial setup, especially with nostream's Docker Compose stack. Bare metal offers better performance and lower overhead: strfry's LMDB benefits from direct filesystem access without container abstraction layers. For nostr-rs-relay, bare metal is trivial since it compiles to a single binary. Use Docker when you want reproducible deployments and easy updates. Use bare metal when you need maximum performance or are running on resource-constrained hardware.

What storage backend should I choose for a Nostr relay?

LMDB (strfry) is the best choice for high-throughput relays that prioritize write speed and low latency. SQLite (nostr-rs-relay) is ideal for simplicity: single-file databases are easy to back up, move, and inspect. PostgreSQL (nostream) is appropriate when you need advanced querying, replication, or plan to run analytics against your event data. The choice also affects your backup strategy, monitoring tooling, and operational runbooks.

This tool is for informational purposes only and does not constitute financial advice. Data is approximate and based on publicly available information as of late 2026. Nostr relay software evolves rapidly: always verify NIP support, performance claims, and pricing against each project's current repository and documentation before making deployment decisions.