NucliaDB: a hybrid search database that expects an enrichment pipeline
NucliaDB, The AI Search database for RAG
At a glance
- What is it?
- NucliaDB stores text, files, vectors, labels and annotations and queries them through vector, full text and graph indexes. The catch is that its most interesting behaviour depends on the Nuclia Understanding API, a separate commercial service.
- Who is it for?
- Adopt NucliaDB if you already ingest unstructured data through the Nuclia Understanding API and want vector, keyword and graph retrieval behind one HTTP API without assembling three separate stores. Do not adopt it if you need a self-contained search engine with no external enrichment dependency, or if AGPLv3 obligations on modifications are unacceptable to your legal team.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem NucliaDB addresses: unstructured data that needs three retrieval modes at once
Most search stacks force a choice. A keyword engine such as Elasticsearch or Solr handles exact terms well and semantic similarity badly. A vector store such as Qdrant, Weaviate or pgvector handles embeddings well and gives you little for exact phrases, filters or relationships between entities. Teams that need both end up running two systems, keeping them in sync, and merging result sets in application code. NucliaDB's pitch is that it is an out of the box hybrid search database, utilizing vector, full text and graph indexes, so the merge happens inside the database rather than in your service layer.
The target user is not a general web search team. It is a team building retrieval augmented generation over documents, conversations, links and files, where a query might be a natural language sentence, a product code, or a filter on labels. The README lists field types of text, file, link and conversation, which is a strong hint about the intended corpus: support tickets, call transcripts, crawled pages, PDFs. If your data is already tabular and structured, this is more machinery than the problem requires.
What actually sits inside the box: Rust and Python, PostgreSQL and an index layer
The repository describes NucliaDB as written in Rust and Python. The split is visible in the repository layout and in the two code style documents the README links, CODE_STYLE_RUST.md and CODE_STYLE_PYTHON.md. Based on the architecture overview image and the feature list, the storage layer is PostgreSQL, blob content goes to an S3-compatible API, GCS or Azure Blob Storage, and the search indexes are separate and replicated. Index fields, paragraphs, and semantic sentences on index storage is the phrasing the README uses, which implies three granularities of indexing rather than one document-level vector.
That granularity matters. Paragraph-level indexing means a long PDF does not collapse into a single embedding that averages out its sections. Sentence-level semantic indexing means a query about one clause can match that clause. The cost is index size and ingestion time, and the README does not publish figures for either. The README also states that NucliaDB is designed to index large datasets and provide multi-tenant support, and lists role based security with upstream proxy authentication validation. That combination points at a deployment where one instance serves several customers, with an external proxy responsible for identity. If you expected built-in user management, there is none described here.
Where the AI in the name comes from, and why it is a dependency
The README is explicit that enrichment is a cloud service. Cloud data and insight extraction with the Nuclia Understanding API, and cloud connection to train ML models with Nuclia Learning API, are listed as features. Nuclia's stated business model relies on those two APIs, which transform unstructured data into NucliaDB-compatible data. In other words, the database stores and retrieves; the Understanding API produces the vectors, labels and extracted text that make semantic search work.
This is the single most important thing to understand before evaluating the project. Running the open source database gives you the storage and index layers. It does not give you the model that turns a PDF into embeddings and annotations. You can supply your own vectors and annotations through the API, and the README does list storing vectors and labels as a feature, so a self-hosted pipeline is technically possible. But the out of the box semantic experience the marketing describes assumes the paid API. Any evaluation that skips this distinction will produce a misleading result, in either direction.
Getting it running: what the material does and does not give you
The README does not contain a docker run command, a compose file, or a configuration reference. It points to the Quickstart at docs.nuclia.dev/docs/management/nucliadb/intro and to the API reference at docs.nuclia.dev/docs/api. Those are the two pages you need before writing any deployment script. What the README does establish is the set of external dependencies you will have to provision first: a PostgreSQL instance for the storage layer, and an S3-compatible, GCS or Azure Blob Storage bucket for blobs. There is no mention of an embedded database fallback or a single-binary mode.
On the client side, the README references a Knowledge box concept, explained in the basics section of the docs, and an ingestion guide. A knowledge box appears to be the unit of isolation, which lines up with the multi-tenant claim. For programmatic use, the project is Python and exposes an HTTP API; the README does not document a Python client library, so treat the HTTP API as the contract. If you need to know the exact endpoint shapes, the API reference is the only source listed. Anyone planning a proof of concept should budget time for reading those docs rather than expecting a copy-paste compose file.
The AGPLv3 boundary and what it means for a hosted product
The README's own FAQ states that NucliaDB is open source under the GNU Affero General Public License Version 3, and that you are free to use it for your project as long as you do not modify it, and that if you do modify it you have to make the modifications public. That is the project's summary, not legal advice, and the licence file itself is the authoritative text. Note also that the repository metadata reports the licence as NOASSERTION while the README badge and FAQ say AGPLv3; that discrepancy is worth resolving with your own reading of LICENCE.md before you rely on either.
The practical shape of AGPLv3 is that running a modified version as a network service triggers source disclosure obligations. For an internal search tool this is usually a non-issue. For a company that intends to fork NucliaDB, add proprietary ranking logic, and sell access to it, the licence is a design constraint, not a detail. Nuclia's stated business model is the normalization API and the hosted service at nuclia.cloud, which is consistent with an AGPL database: the database is the on-ramp, the enrichment API is the product. That is a legitimate model, and it also tells you where the company's engineering attention is likely to be concentrated.
Limitations the README does not resolve
Several things a reader would want to know are simply absent. There are no latency figures, no index size guidance, no limits on document size or field count, and no description of how replication of index storage behaves under failure. Distributed search is listed as a feature with no explanation of the sharding model or how results from shards are combined and ranked. For a database, those are the questions that decide whether it fits.
The fuzzy search claim in the FAQ is also unquantified. The FAQ contrasts NucliaDB with Elasticsearch and Solr by arguing that its architecture was built from the ground up for unstructured data, which is a positioning statement rather than a technical comparison. A team choosing between the two should test their own corpus. There is one more limitation worth naming plainly: the version numbering. Releases v6.15.1, v7.0.0 and v7.1.0 land within roughly five weeks of each other in the supplied metadata. Rapid major version increments are normal for young infrastructure, but they mean upgrade notes matter more than usual, and the README does not link a migration guide.
How it differs from Elasticsearch and from a dedicated vector store
Elasticsearch and OpenSearch can do hybrid retrieval today through dense vector fields plus BM25, and they bring a mature ecosystem of clients, dashboards and operational knowledge. The difference in approach is that Elasticsearch treats vectors as one more field type on a general purpose document store, while NucliaDB treats paragraphs and semantic sentences as first class indexed units and adds a graph index alongside. If your queries are mostly filters and exact terms with an occasional vector lookup, Elasticsearch is the lower risk choice and you already know how to run it.
A dedicated vector store such as Qdrant or pgvector takes the opposite position: it does embeddings well and expects you to handle keyword search, entity relationships and document parsing elsewhere. NucliaDB's argument is that the parsing, the labels, the graph and the vectors belong in one place because they are produced by the same enrichment step. That argument only holds if you actually use the enrichment step. If you are generating embeddings yourself with a local model and only need nearest neighbour lookup, a vector store is simpler, cheaper to operate, and has no AGPL question attached. The honest boundary is this: NucliaDB is worth its extra moving parts when you want the graph and the annotation model, not when you want vectors alone.
Upgrade and operating cost
The operational surface is PostgreSQL plus object storage plus the NucliaDB services themselves, with an upstream proxy handling authentication. That is a real stack to run, and the README does not describe a managed upgrade path for self-hosted deployments or a compatibility matrix between database versions and index formats. The release cadence in the supplied metadata is fast enough that pinning a version and reading release notes before each jump is the reasonable posture.
On the enrichment side, the cost model is a commercial API rather than a self-hosted component, and the README gives no pricing or quota information. Teams should treat the Understanding API as a line item to be negotiated, not a free dependency. The export feature, which the README describes as producing data compatible with most NLP pipelines including HuggingFace datasets and PyTorch, is the mitigation: it means your stored data is not locked inside the index format, and you can move a corpus out if the retrieval layer stops fitting. That export path is worth testing early, before you have terabytes indexed.
Editorial conclusion
Adopt NucliaDB if you already ingest unstructured data through the Nuclia Understanding API and want vector, keyword and graph retrieval behind one HTTP API without assembling three separate stores. Do not adopt it if you need a self-contained search engine with no external enrichment dependency, or if AGPLv3 obligations on modifications are unacceptable to your legal team. Before committing, verify two things in your own environment: whether the open source distribution returns useful semantic results on raw text without an Understanding API key, and whether the PostgreSQL plus object storage layout fits your existing backup and tenancy model.
Community notes