There is a line of database research (VBASE at OSDI '23, Chimera in PVLDB, AkasicDB at SIGMOD '26 here) arguing that vector search, graph traversal, and relational filtering belong in **one engine with one query plan**, where the top-k is enforced *during* execution so intermediate results never blow up. AkasicDB is the full tri-modal version of that idea. It is also closed. You cannot download it.

So we rebuilt the design in the open, on Postgres. That took three pieces:

* **pgvector** for the vector leg (unmodified).

* **A native graph access method**: adjacency lists in custom-formatted pages through the buffer manager, WAL-logged with GenericXLog. Deliberately *not* an edges join table; topology gets its own storage, but it lives in the same process, same transaction manager, same WAL as everything else.

* **A fused operator extension** that streams ANN candidates out of pgvector's index and applies graph reachability plus relational predicates per candidate, with VBASE-style early termination. One call, one plan, no cross-system round trips.

The part we did not expect: we started on the lineage's research fork (Microsoft's MSVBASE, PG 13.4) to prove the mechanism, then re-homed everything onto stock PG 17. **Stock Postgres ran the identical fused query 2x faster than the fork** (0.27 ms to 0.14 ms at matched recall). We retired the fork as a launch vehicle on the spot.

Numbers, all with published method docs and one-command repros: 23.7x vs a tuned Milvus + Neo4j + Postgres stack at matched recall on a 1M corpus; injected mid-write failures tore the multi-store 42 out of 42 times vs 0 for one WAL. And the honest one: plain pgvector + a links-table CTE inside one Postgres comes within 16 microseconds of our operator on anchored queries. We published that too. Most of the win is one-system-vs-three; Postgres itself was never the bottleneck.

MIT, spec and evidence docs in the repo: https://github.com/ConsultingFuture4200/tridb

Edit: Hey guys, my name is Dustin, I'm new to software development and have been learning through the "project based learning" method, using a stack of Frontier and local LLMs as my build partner and tutor. All of this code was generated as a result of extensive Spec Driven Development. A group of people far more experienced than I built the inspiration for this project, and I set out to see if I could recreate their solution.

Any and all feedback and project contributions are welcome

I recently moved our 3dp vendor vector database (100M+ vectors) to neon using the lakebase_vector and lakebase_text extension to do hybrid search. Did not observe huge changes in retrieval performance. Interesting bit: the ann side uses ivf+ rabitq quantization instead of hnsw (probably since graph indexon object storage didn't work really well), bm25 is actual block-max wand and both seem quite performant.

Curious to know if anyone else has moved their vector indices to postgres and seen any performance bottlenecks at a larger scale

Hey PostgreSQL community!

I'm Kevin, the maker of FluentDB.

I have been working with Postgres for years and using many Postgres client apps, but none of them have satisfied me lately.

So I built the tool I wanted: a native macOS database client that is fast, lightweight, and AI-driven from the ground up.

A few things:

• Native Swift app designed for speed (not another Electron super-slow app).
• Bring your own AI: OpenAI, Anthropic, Claude Code, Codex, or local models with Ollama.
• Privacy by default: AI only sees your schema unless you explicitly approve sending data. Every AI-generated SQL query also requires approval by default.
• Support for PostgreSQL (of course) and others (SQLite, MySQL, SQL Server, and more)

FluentDB is still in its early days, and I'd genuinely love your feedback.

It's 100% free to try, no credit card required, and I am more than happy to distribute coupons for those who actually want to use it further!

For now, it only supports macOS 26+, but I am actively working on a port for Linux and Windows.

Can't wait to get your feedback :)