Integrations

A document is a row: its id, its text, its metadata as JSON and its vector under @hnsw, in a collection created on the first write, once the embedding's size is known. Adding an id that is already there replaces it — the old row out and the new one in, sent as one /batch and run under one write lock, so no reader sees the id twice or not at all.

A metadata field named in metadata_fields gets a column of its own under @hash, and filter takes equality and $in over those: {"source": "ops"} becomes where source = $2, answered by the index before near looks for neighbours among the rows that passed. A filter on a field not declared is refused rather than applied to the JSON after the search, which would return fewer than k rows and not say so.

The score is fenecdb's own, the one the HTTP endpoint and the browser module return: the cosine similarity under cosine (the default), the distance under l2, the product under dot. similarity_search_with_relevance_scores maps them the way LangChain's own functions do.

store = FenecVectorStore(embeddings, "handbook", url=..., token=...,
                         full_text=True, quant="int8")
store.similarity_search("compact dead records", k=4, mode="text")     # BM25 alone
store.similarity_search("how do I compact", k=4, mode="hybrid")       # both, fused
retriever = store.as_retriever(search_kwargs={"k": 8, "mode": "hybrid"})

With full_text=True the text is indexed for BM25 as well (@text, added to a collection made before without it), and a search takes mode: "text" ranks by the words alone with match and embeds nothing, and "hybrid" runs match and near each to their own depth and fuses the two rankings (fuse). Their scores are BM25's and the fusion's, not similarities. quant, "int8" or "bit" (cosine only), keeps the graph over codes, and near still orders by the vectors themselves.

The Python store's collection, from JavaScript: a document is a row of its id, text, metadata as JSON and vector under @hnsw, made on the first write; metadataFields get columns of their own under @hash, and filter takes equality and $in over them; with fullText, search(query, k, {mode}) ranks by the words ('text') or both ('hybrid'). client is anything with run(sql, params): a Fenec keeps the whole RAG index in the page, no server, and a FenecHttp the server's. Writing an id already there replaces it — two statements, which over HTTP are two requests.

A node is a row with its document's id beside it, so index.delete_ref_doc(...) is one del over a hashed field. Filters take ==, !=, <, <=, >, >=, in and nin over the declared fields, joined by and or or and nested; node_ids and doc_ids narrow the same way. get_nodes, delete_nodes and clear are there; delete_nodes() with neither ids nor filters deletes nothing — everything is clear, asked for by name. With full_text=True the text is indexed for BM25 as well, and a query takes the modes that need it: TEXT_SEARCH ranks by the words alone (match), and HYBRID runs match and near each to their own depth — hybrid_top_k, or sparse_top_k, deep — and fuses the two rankings (fuse). The fusion adds ranks rather than scores, so alpha has nothing to weigh and is not read. quant is taken as the LangChain store takes it.

store = FenecVectorStore("handbook", url=..., token=..., full_text=True)
retriever = index.as_retriever(similarity_top_k=4, vector_store_query_mode="hybrid")

The AI SDK has no vector store interface to implement — it has embedding models and tool — so the integration is a file of three functions to copy, integrations/ai-sdk/rag.js: index embeds with embedMany and writes the documents, their text under @text and their vectors under @hnsw; retrieve embeds the question with embed and answers with near, or with hybrid the words and the vector fused, kept to a source through its @hash index; searchTool is a tool a model calls with a query. It takes a Fenec, so the index lives in the page or a Worker, or a FenecHttp for the server's.

Over a replica or a database in the page the rows come from the page, so no render waits on the network: live runs the query again after every write it may read — a write of this tab's, or one the server streamed into a replica from another client — and the component renders what it answers. Over connect the query runs on the server, again after each write the server's subscriptions report to a collection it reads; a FenecQL text names those with { collections } there, since nothing in the page can know what a text reads. A FenecQL text works too, on the provider's database: useLiveQuery('get todos count', { collections: ['todos'] }). useLiveQuery is undefined until the first answer, and subscribes by the query's text and parameters, so the query built again on every render, which is the natural way to write one, does not subscribe again unless it asks something else; the rows of the query it asked before are not handed out as this one's. A query that fails throws while rendering, to the nearest error boundary. A query that asks for facets has them on its rows, rows.facets.brand, counted over every match: a results list and its filter sidebar from one hook, live alike. It lives in integrations/react, with React as its one peer dependency.

The server reads a number as a double and rounds it to a float, and one float, 7.038531e-26, has a shortest text whose double lands exactly between it and the float above: Go's encoding/json wrote it so, and the server stored the float above. Both SDKs write that one as its double's text, as the server itself writes it, and their tests try one float in 4 099 over every exponent and read a vector holding it back from a server.

A subscription takes the REST surface's filter (year=gte.2024, where=, select=), not a statement with parameters: the stream is GET /<collection>/changes. A request is bounded by the client's timeout through its context or token, never the HTTP client's own, which would cut a subscription short.

LangChain's suite writes the same documents twice under the same ids, and that is how it found a bug in the graph: a node whose every candidate neighbour had been deleted was linked to nothing, so a collection deleted and written again answered near with nothing. It is fixed in the engine, with the test that shows it.