JamAI Base: a spreadsheet front end over SQLite, LanceDB and a RAG pipeline
The collaborative spreadsheet for AI. Chain cells into powerful pipelines, experiment with prompts and models, and evaluate LLM responses in real-time. Work together seamlessly to build and iterate on AI applications.
At a glance
- What is it?
- JamAI Base is an Apache-2.0 Python backend that turns a spreadsheet grid into a RAG application surface, with SQLite and LanceDB embedded rather than provisioned. The pitch is real, but the README is thinner than the feature list suggests.
- Who is it for?
- JamAI Base fits teams that want a RAG backend with a grid UI and are willing to run the self-hosted stack rather than wire up a vector store and an orchestration layer themselves. It does not fit anyone who needs a stable, versioned API surface: the repository ships a v1 to v2 migration guide, which tells you the interfaces have already broken once.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days 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 JamAI Base targets: RAG plumbing that nobody wants to write twice
Building a retrieval-augmented application usually means assembling four separate things: a relational store for application rows, a vector store for embeddings, an orchestration layer that calls an LLM and a reranker, and a UI so a non-engineer can see what the pipeline is doing. JamAI Base collapses all four into one Python service. The README describes it as an "open-source RAG backend platform that integrates an embedded database (SQLite) and an embedded vector database (LanceDB) with managed memory and RAG capabilities." The audience is therefore narrower than the word "spreadsheet" implies. This is not a tool for analysts who want to summarise a CSV. It is for backend and ML engineers who would otherwise spend a sprint gluing Postgres, pgvector or a hosted vector database, an LLM client library and a reranker into something that holds together. The spreadsheet is the configuration surface for that glue, not the product itself.
Four table types, and what each one actually does
The README splits the data model into four kinds of table, and the split is the most informative part of the documentation. Generative Tables take a static database table and populate columns with LLM output, exposed through a REST endpoint. Action Tables are the interactive path: the README says they provide "a responsive AI interaction layer for applications" and remove the need for manual backend management of user input and output. Knowledge Tables hold documents and structured data that supply context to other tables. Chat Tables wrap the whole thing in a chatbot interface and can pull from any Knowledge Table. Read together, the four types map onto a conventional RAG flow: ingest into Knowledge, generate or chat against it, and let Action Tables handle the request-and-response loop. The declarative framing in the README ("define the 'what' rather than the 'how'") is accurate in the narrow sense that a column holds a prompt rather than a function call. It is not accurate in the broader sense that you avoid thinking about retrieval. You still choose what goes into a Knowledge Table.
The retrieval stack: hybrid search, query rewriting and BGE M3
JamAI Base does not leave the retrieval strategy to you. The README lists query rewriting, hybrid search combining keyword, structured and vector search, reranking, structured RAG content management, and adaptive chunking, with BGE M3-Embedding described as multi-lingual, multi-functional and multi-granular, and available at no cost. LanceDB handles embedding storage and query across multi-modal data. This is a defensible default set. Query rewriting plus reranking is the combination that most often closes the gap between a naive vector search and something usable, and shipping it as a default saves the weeks that teams typically lose tuning a retriever. The trade-off is that the README does not document how to override any of it. There is no mention of a config key to swap the embedding model, disable rewriting or change the reranker. Adaptive chunking is described as automatic, which means you get whatever heuristic the project chose. For a team with a strong opinion about chunk boundaries, that is a constraint rather than a feature, and the README gives no indication of how to work around it.
Getting it running: two paths, one of which the README does not spell out
There are two documented routes. The first is the hosted service at cloud.jamaibase.com, which the README says offers a free account and free LLM tokens. The second is self-hosting, and this is where the documentation thins out. The README's entire instruction is "Follow our step-by-step guide" with a link to docs.jamaibase.com/sdk/python-sdk-documentation#oss. No Docker command, no Compose file, no environment variable list, no port number appears in the README itself. That is a real gap for anyone evaluating the project on the repository alone: you cannot judge the operational cost of self-hosting without leaving the README and reading the external docs. What the README does establish is the integration surface. There is a REST API, an API reference at jamaibase.readme.io, and a Python SDK. The example applications are a chatbot on NLUX with no backend, the same chatbot with Express.js, and a Streamlit chat app for Python developers. The frontend is built in Svelte according to the repository topics, though the README does not describe how to build or serve it.
Where the project is weakest: versioning and the v1 to v2 break
The README opens with a "Migration Guide from v1 to v2" pointing at MIGRATION_GUIDE.md. That single line is the most important signal in the document. A backend that has already required a migration guide between major versions is telling you its API surface is not settled. The release history supports the same reading: v0.3 in November 2024, v0.3.1 days later, v0.4 in February 2025. The cadence is reasonable for a young project, and the presence of a VERSIONING.md file suggests the maintainers are thinking about the problem. But a versioning policy document is not the same as a stable interface, and the README does not state what the policy guarantees. For a team embedding this in a product, the practical question is whether a v0.5 will require another migration. Nothing in the supplied material answers that. The second gap is deployment guidance. The README calls the design "serverless" and promises scalability, but with SQLite and LanceDB embedded, the scaling story is vertical and single-node unless the external docs describe something the README omits. Treat the scalability language as unverified.
How it compares to assembling LangChain or LlamaIndex yourself
The obvious alternative is a general orchestration library such as LangChain or LlamaIndex sitting on top of a vector database you choose. The difference in approach is structural, not cosmetic. With an orchestration library you write Python that describes the pipeline: you instantiate a retriever, a prompt template and a chain, and you own the database, the schema and the deployment. JamAI Base inverts that. You declare columns in a grid, and the service owns the retrieval configuration, the storage layer and the API. The library approach gives you control over every stage and no UI. JamAI Base gives you a UI and a REST endpoint and takes the stage-by-stage control away. Neither is better in the abstract. If your retrieval needs are unusual, or you need to run on a vector database your organisation already operates, the library route is the one that will not fight you. If your problem is a standard document-QA or chatbot flow and the bottleneck is engineering time, the declarative route removes work. The README's claim that you do not need to build the RAG pipeline yourself is the honest summary of the trade.
Licence, maintenance and what upgrading costs you
JamAI Base is released under Apache-2.0, which permits commercial use, modification and redistribution provided you retain the licence and notices and state significant changes. It also includes a patent grant, which matters if you are shipping this inside a product. This is not legal advice; check the LICENSE file and your own counsel. On maintenance, the material supports only limited conclusions. The last push recorded is 2026-09-03, so the repository is active, and the release history shows roughly quarterly tagged releases through v0.4 in February 2025. The upgrade cost is the part to weigh carefully. Because the project has already moved from v1 to v2 with a dedicated migration guide, an upgrade is not a dependency bump. It is a code change to your table definitions and API calls, plus a re-test of whatever your prompts depend on. Budget for that on every major version, and read VERSIONING.md before you assume otherwise. The README does not describe a deprecation window or a long-term support branch.
Editorial conclusion
JamAI Base fits teams that want a RAG backend with a grid UI and are willing to run the self-hosted stack rather than wire up a vector store and an orchestration layer themselves. It does not fit anyone who needs a stable, versioned API surface: the repository ships a v1 to v2 migration guide, which tells you the interfaces have already broken once. Before committing, read MIGRATION_GUIDE.md and VERSIONING.md, then confirm that the v0.4 release notes match the API your client code will call. If the migration cost is unacceptable, the honest answer is to wait for the versioning document to describe a policy you can plan around.
Community notes