Frequently Asked Questions

No. PulseSocketDB is designed with complete isolation: • Dedicated Port: Runs on port 3001 by default, avoiding conflicts with other local apps (ports 3000, 8080, etc). • Nginx Domain Routing: Nginx forwards requests based on hostnames (e.g. api.pulsesocketdb.com). • Isolated Processes: Each process runs under PM2/Docker. A restart in one app does not affect others.

• Minimum (Testing / Small Apps): 1 vCPU, 1 GB RAM, 10 GB SSD. Handles tens of thousands of requests alongside lightweight apps. • Recommended (Scale Production): 2 vCPUs, 4 GB RAM, 40 GB NVMe SSD. Delivers sub-millisecond RAM caching and thousands of concurrent WebSockets.

PulseSocketDB prevents collisions through two key mechanisms: 1. Prefixed Namespaces: All internal keys use structured prefixes (e.g. project_meta:*, user_redis_config:*, quota:*). 2. Logical Databases (DB Index): Set REDIS_URL to target dedicated databases (e.g. redis://127.0.0.1:6379/1), isolating data from default db 0.

Yes! PulseSocketDB includes a dynamic TenantConnectionManager. Pro and Enterprise clients can supply custom Redis endpoints (AWS ElastiCache, Upstash, Redis Enterprise) for 100% data sovereignty.

In /etc/redis/redis.conf, configure maxmemory and maxmemory-policy: maxmemory 512mb maxmemory-policy noeviction This sets a strict memory cap so Redis never starves the host operating system or adjacent applications.

The Fastify-powered Core API is ultra-lightweight: • RAM Usage: ~100MB to 150MB at idle. • Latency: Sub-5ms in-memory operations. • PM2 Protection: Recommended launch flag --max-memory-restart 500M ensures automatic preventive recovery.

PulseSocketDB provides live telemetry inside the Dashboard: • Total Operations: Granular tracking of Reads and Writes. • Storage Volume: Exact memory usage in MB/KB. • Active Connections: Number of live WebSocket subscribers. • Quota Status: Visual alerts when approaching tier thresholds.

When a quota limit is reached, excess requests return a 429 Too Many Requests response. Saved data remains 100% safe, and instant plan upgrades can be triggered from the Dashboard.

No! The npm package (pulsesocketdb) publishes only the compiled dist/ directory specified in package.json ("files": ["dist"]). Your GitHub monorepo remains completely private.

The SDK features automatic reconnection with Exponential Backoff. If a WebSocket connection drops due to network blips, it reconnects seamlessly in the background without UI blocking.

No — and this is one of PulseSocketDB's most important architectural advantages. The system uses a connection multiplexing model: regardless of how many clients are connected simultaneously (100, 1,000 or 10,000), Redis always receives only 2 fixed connections from the Core API: • 1 command connection (reads and writes) • 1 Pub/Sub connection (real-time event broadcasting) Clients connect to Node.js via WebSocket. Node.js acts as an efficient intermediary — Redis is never exposed directly to end-user count. This is the same architecture used by Firebase Realtime Database and Supabase Realtime, products that serve millions of users on Redis.

Redis and SQL databases have fundamentally different models: • PostgreSQL / MySQL: Each client opens 1 dedicated connection to the database. 500 simultaneous users = 500 connections — a real bottleneck requiring connection pools and replica sets. • Redis: Single-threaded event loop. Processes 100,000+ operations per second in RAM on a single instance, with zero locking. Writing a document is an atomic HSET operation taking under 1 millisecond. The concern about 'database not supporting simultaneous writes' is valid for SQL systems, but does not apply to Redis, which was specifically designed for high-throughput, write-heavy workloads.

PulseSocketDB was built for a specific use case: real-time data with ultra-low latency. Redis is the ideal choice because: • Speed: Sub-1ms in-memory operations (vs. tens of milliseconds on disk with SQL). • Native Pub/Sub: Redis has a built-in publish/subscribe system — the foundation of our real-time sync, with no polling or external triggers needed. • Rich Data Structures: Native Hashes, Sets, and Sorted Sets handle operations that would require complex SQL queries. • Schema-free: Perfect for dynamic data varying by project and client. For data requiring SQL (complex reports, joins, multi-table ACID transactions), PulseSocketDB is not the right tool — and we are honest about that. Our focus is real-time state sync, not replacing transactional databases.