Dora NodaOmni showed up on HN in March 2026 with 177 points and a one-line deploy: docker compose up. Inside that compose file is a single Postgres running ParadeDB for BM25 full-text search and pgvector for embeddings. No separate search cluster, no vector database, no second datastore to back up.
For a self-hosted PaaS, the interesting part is not “AI search is cool.” It's that a Glean-class enterprise search now fits the same operational surface as any other tenant app on the fleet.
What Omni actually is
- Ingestion: connectors for Google Drive, Notion, Confluence, and local docs
- Index: BM25 via ParadeDB (Postgres extension) + embeddings via pgvector (same Postgres)
- Serve: a stateless web tier that queries Postgres
- Deploy: one
docker compose up— one database, one app
The “one Postgres” pattern is the point. Search index, vectors, and app state share WAL, backups, and monitoring. You already operate Postgres for your PaaS — this adds extensions, not a new distributed system.
Why one database wins for self-hosting
| Approach | Components | Backup story | Marginal cost on owned hardware |
|---|---|---|---|
| Separate search + vector DB | Postgres + Elasticsearch/OpenSearch + Qdrant/Pinecone | Three backup policies | Three stateful systems |
| Omni (single Postgres) | Postgres + ParadeDB + pgvector | One pg_basebackup | Disk + one more table |
Per-seat SaaS search (Glean, etc.) scales with headcount. Self-hosted Omni scales with disk. On a Hetzner fleet you already pay for, the 10th user costs the same as the first.
Running it as a tenant workload
On a self-hosted PaaS, Omni is just another app:
- Database: provision a Postgres with
paradedbandvectorextensions (oneCREATE EXTENSIONeach) - App: deploy the Omni container with
DATABASE_URLpointing at that Postgres - Storage: attach a volume for the Postgres data dir — same as any stateful tenant
- Ingress: expose via the same TLS automation as
*.onbex.co
No special node pool, no GPU for indexing (embeddings run on CPU at this scale), no sidecar.
When this pattern fits and when it doesn't
Fits:
- Team <1,000 users, <5M documents — single Postgres handles it
- You already operate Postgres for the PaaS — extensions are cheap
- Data residency matters — the index never leaves your fleet
Doesn't fit:
-
10M documents with sub-50ms p95 — you want a dedicated search tier
- Heavy real-time ingestion >1k docs/sec — separate the pipeline
- You have no Postgres on-call — fix that before adding search
The PaaS lesson
The 2026 self-hosting wave is not about running one big app. It's about running many small apps on the same fleet with the same primitives. Omni proves that even “enterprise search” now fits that shape — one more docker compose on hardware you already own, versus a per-seat SaaS that scales with headcount, not with value.
If your PaaS can run Postgres, it can run workplace search.
