PostgreSQL bucklesat 100M rows.
JSONB columns balloon in size. Vacuuming stalls. Index bloat becomes a full-time job. It was built for structured rows — not 850 KB JSON blobs at scale.
We kept hitting
the same wall.
Every project reached a point where storing large JSON records got painful. Firestore document limits. MongoDB costs exploding at scale. DynamoDB complexity. There had to be a better way.
Everything your app needs, built in.
Hydrous is a managed database platform purpose-built for massive-scale JSON records. Hover each card to see it come alive.
Built for scale. Priced for reality.
Most databases charge per document read or scale storage costs linearly with record size. Hydrous stores records as GCS blobs — paying object-storage prices, not database prices.
Hydrous pays ~$0.02/GB/month with no per-read pricing. Competitors charge per document read — at 1B records, that delta is enormous.
Every record is compressed before upload. JSON typically compresses 60–80%, making effective storage cost 3–5× lower than the nominal size.
The GCS path is derived from the record ID in memory. No index lookup, no read unit consumed — just one network call to GCS.
Records age into Nearline → Coldline → Archive automatically. At 1B records, this drops storage cost from $2,860 to $708/mo.
◉ Live Architecture Tour
The record that
never touches a database
Every medical record starts as raw JSON. We stamp it with a time-encoded ID, shrink it with gzip, and drop it straight to cloud storage — zero database involved.
REST API.
No SDK required.
Every operation is a plain HTTP call. Any language, any runtime. Your API key and bucket key are the only credentials you need.
Real questions.
Direct answers.
Mostly the "but why not just use X" questions that every developer asks before switching.
Firestore charges per document read. At 300 KB–1 MB per record and 1B records, that's financially catastrophic. Hydrous stores the actual blobs in GCS ($0.02/GB, no per-read fee) and uses Firestore only for the tiny index document — paying Firestore prices only for metadata, not payloads. At 1B records, the monthly cost difference is over $59,000.
Both are row-oriented databases that store full document payloads inside the database engine. At 1 MB records, you're paying full database storage and compute pricing for bytes that could live in object storage at 1/10th the cost. Hydrous separates the index (Firestore, tiny) from the payload (GCS, cheap). You get queryability without paying database-storage prices for large blobs.
Every record ID is date-prefixed: 260601-rec_01JA2XYZ. The full GCS path is deterministically computed from that ID in memory — no network call, no lookup. The server builds the path, downloads the blob from GCS, decompresses it, and returns it. One network call total. Firestore is only consulted for filter queries, never for direct record fetches.
Queryable fields are the fields you declare at write time that get indexed in Firestore. Firestore indexing is what makes filter queries fast. The 3-field limit exists because each additional Firestore-indexed field increases write cost and index storage. For most workloads, 3 queryable fields is more than enough — time-scoped queries use GCS folder structure and need zero Firestore reads at all.
No. The crash-safety system handles this. Every write starts by setting _repairNeeded: true in the Firestore index doc. Only after the GCS blob is confirmed uploaded does the flag clear. A scheduled reconciliation job scans for stale _repairNeeded flags, checks whether the blob exists, and either completes the write or removes the orphaned index entry. The GCS blob is always the source of truth — the index can always be rebuilt from it.
Every record is gzip-compressed unconditionally before upload (ALWAYS_COMPRESS = true). JSON typically compresses 60–80%, so a 1 MB record becomes ~200–400 KB stored. You cannot opt out per-record, but you wouldn't want to — it's the primary reason GCS storage costs stay so low. On download, the magic-byte detector (0x1f 0x8b header) auto-decompresses. Legacy uncompressed blobs are handled transparently.
Hydration runs at 20 concurrent GCS downloads (DEFAULT_HYDRATION_CONCURRENCY). Each download is cache-checked first — if the record is in the in-process LRU cache (1,000 entries), zero GCS reads are made for it. Records not in cache are fetched in parallel batches of 20. The query result is assembled and returned. For very hot data, consider Redis as a shared cache layer — zero code changes required in the operations layer.
Yes. The built-in Analytics Engine (analytics.js) handles timeSeries, distribution, topN, stats, multiMetric, and crossBucket queries directly over your record data. BigQuery is the additional layer for raw SQL access and large-scale aggregations that need columnar performance. For most app-level analytics needs, the built-in engine is sufficient and cheaper.
Credit-based.
Pay exactly for what you use.
1 Hydrous Credit (HC) = $0.00001. Every operation costs a precise number of credits. No surprise bills — the calculator below shows your exact cost.
Built with the people who use it.
Every shipped feature started as a community thread. Our team reads every post, replies to every question, and builds what you actually need.
This is Priority 1 on our roadmap — zero changes to operations.js required, we just swap the cache interface. ETA: next sprint.
Exactly right — the ID encodes YYMMDD, so the GCS path is computed in memory from the ID alone. Zero Firestore reads, one GCS download.
In active development — async generator replaces the batch-then-emit pattern. Early benchmarks show 5–10× improvement in perceived query speed.
Shipped in v2.1! POST /storage/batch-upload-urls now accepts up to 50 files in a single call. Closing this ✓
On the roadmap as Priority 10 — HTTP callbacks via Cloud Tasks. We'll be opening a design doc for community feedback before building.
Full Standard SQL including ML functions — the external table exposes your GCS blobs directly to BigQuery ML. No data copy needed.