by acidburnNSA
2 subcomments
- * "Self-hosted: Runs entirely on your infrastructure. No data leaves your network."
* "Bring Your Own LLM: Anthropic, OpenAI, Gemini, or open-weight models via vLLM."
With so many newbies wanting these kinds of services it might be worth adjusting the first bullet to say: "No data leaves your network, at least as long as you don't use any Anthropic, OpenAI, or Gemini models via the network of course"
by philippemnoel
2 subcomments
- (ParadeDB maintainer here). This is super cool. Congrats on the project, and I'm excited to see ParadeDB be used to power this kind of use case. If there's anything else you need to ship Omni, don't hesitate to reach out to me!
- How are you managing multiplayer and permissions? I see in the docs that you can add multiple users and that queries are filtered by the requesting user such that the user only sees what they have access to. The docs aren't particularly clear on how this is being accomplished.
Does each user do their own auth and the ingest runs for each user using stored user creds, perhaps deduplicating the data in the index, but storing permissions metadata for query time filtering?
Or is there a single "team" level integration credential that indexes everything in the workspace and separately builds a permissions model based on the ACLs from the source system API?
by PhilippGille
1 subcomments
- How does it compare to Onyx (rebranded from Danswer, with more chat focus, while Danswer was more RAG focus on company docs/comms)?
- https://onyx.app/
- Their rebranded Onyx launch: https://news.ycombinator.com/item?id=46045987
- Their orignal Danswer launch: https://news.ycombinator.com/item?id=36667374
- Interesting!
I also started to build something similar for us, as an PoC/alternative to Glean. I'm curious how you handle data isolation, where each user has access to just the messages in their own Slack channels, or Jira tickets from only workspaces they have access to? Managing user mapping was also super painful in AWS Q for Business.
by swaminarayan
4 subcomments
- How well does the Postgres-only approach hold up as data grows — did you benchmark it against Elasticsearch or a dedicated vector DB?
- I've done some RAG using postgres and the vector db extension, look into it if you're doing that type of search; it's certainly simpler than bolting another solution for it.
- Can it connect to Teams?
- Nice! Could you elaborate on "not just a basic RAG"?
by vladdoster
1 subcomments
- Multiple pages link to a `API Reference` that returns a 404
by jFriedensreich
1 subcomments
- Can we please not change the meaning of chat to mean agent interface? It was painful to see crypto suddenly meaning token instead if cryptography. Plus i really dont want to “chat” with ai. its a textual interface
- The Postgres-only approach is a really smart call for this scale. I've run pgvector alongside BM25 (via ParadeDB) for internal search at work and it handles mid-size corpora surprisingly well. The operational simplicity of one database vs. managing Elasticsearch + a vector DB + Postgres is a huge win for small teams.
One thing I'd watch out for: HNSW index rebuild times can get painful once you cross ~5M vectors. We ended up doing incremental inserts with a background reindex job. Not a dealbreaker, just something to plan for early.
Also curious how you handle permission syncing. That's usually where self-hosted workplace search gets tricky. Google Drive permissions in particular are a nightmare to mirror accurately.
- [dead]
- [dead]
by raphaelmolly8
0 subcomment
- [dead]
by shablulman
0 subcomment
- [dead]
- [dead]
by mickelsamuel
1 subcomments
- Postgres as a search backend is one of those decisions that looks wrong on paper but works really well in practice. tsvector handles full-text, pg_trgm does fuzzy matching, pgvector covers semantic — and you don't need to babysit an Elasticsearch cluster or worry about sync lag.
The part that's easy to overlook: your search index is transactionally consistent with everything else. No stale results because some background sync job fell over at 3am.
With 3000+ schemas I'd keep an eye on GIN index bloat. The per-index overhead across that many schemas adds up and autovac has trouble keeping pace.
Hacker News