When we built the first VulneraX MVP, we needed a backend that could ship quickly, sync instantly, and handle high-velocity data from multiple scanners. We chose Firebase Realtime Database—a decision that shaped our early architecture in surprising ways.

Why Firebase?

Security scanning isn’t batch processing—it’s event-driven. Scans complete at unpredictable times, partial results trickle in, and developers want immediate feedback. Firebase’s real-time sync meant our dashboard updated the moment a scanner pushed findings.

Data model design

We structured data around /scans/{scanId} nodes, with nested objects for:

• metadata — target, scanner version, start/end timestamps
• findings — array of vulnerability objects with severity, description, and proof
• report — signed URL to the generated PDF

Indexes on target and status let us quickly pull “all active scans” or “all scans for a client” without excessive reads.

Tradeoffs

• Pros: Instant UI updates, simple client SDK, low ops overhead
• Cons: Limited complex querying, requires careful rules to prevent over-fetching

Security rules for AppSec data

Given the sensitivity of scan results, our Firebase rules enforce:

• Only authenticated users can access scans
• Users can only read their own data
• All writes validated against a server-generated whitelist of fields

For an early-stage security product, Firebase let us focus on scanner innovation instead of backend plumbing. As VulneraX scales, we’ll pair it with a long-term data warehouse—but for now, its real-time sync keeps teams one step ahead of attackers.