Open Source Graph Database License for Commercial SaaS

A founder ships a graph-backed agent memory feature, signs two design partners, and then someone in procurement asks one question: what licence is the database under? If the answer is "it depends what you do with it," you have a problem that no benchmark will fix.

This post compares licences for developers embedding or bundling a graph database in a commercial SaaS or shipped product. The six databases are HelixDB, LadybugDB, Neo4j, Memgraph, SurrealDB and FalkorDB. We build HelixDB, so we have an obvious interest. On this one criterion, permissive licences win, and two of the six have them.

Three caveats. This is not legal advice. Licences change, so read the LICENSE file in the repository you are actually using. And the GitHub API licence field is unreliable for several graph databases (it reads NOASSERTION for some), so do not trust the badge. Open the file, then ask counsel. If you are building agent memory, GraphRAG or a company brain, run this check before you write a line of integration code.

Who each licence is actually for

The short answer, before the detail.

Apache-2.0 (HelixDB open-source core) is for anyone who wants to embed, bundle, modify and resell with no copyleft and with an explicit patent grant. MIT (LadybugDB) is for the same crowd, if you want the shortest licence text possible and do not care about an express patent clause.

GPLv3 (Neo4j Community) is for teams that run the database as a separate server process they only talk to over the network, or that are happy to open-source their own code. It is a poor fit for bundling inside a closed-source product. Neo4j Enterprise is a commercial licence, which means a contract and a price.

BSL 1.1 (Memgraph, SurrealDB) is for teams whose use falls outside the licensor's stated additional-use restriction, or who are willing to wait for the licence to convert. Read the specific parameters. The licence text is a template, and each vendor fills in the blanks differently.

SSPL (FalkorDB) is for teams that are not offering the database itself as a service to others. If your SaaS is a product built on top of it, you need counsel to tell you where the line sits.

If you want the least friction when shipping, pick from the first two. Everything else is a conversation. Some of those conversations are fine, but they are still conversations.

Why embedding is the hard case: four different questions

"Can I use it commercially?" is not one question. It is at least four, and licences answer them differently.

In-process. The database library is linked into your application binary or loaded in your process. Your code and the database code ship as one thing. Copyleft licences bite hardest here, because the combined work is arguably a derivative.

Bundled. You ship the database as a separate binary or container alongside your product, to customers who run it themselves. You are distributing it, and distribution is the trigger for most copyleft obligations.

Hosted-as-a-service. You run the database and customers use your product over the network. The GPL does not trigger on network use alone. SSPL was written to close that gap, and BSL additional-use grants often target exactly this.

Internal use. You run it for your own team and never expose it. Almost every licence on this list permits this, and it is the least interesting case.

Most comparison posts collapse these into one verdict, and that is how teams end up surprised. A licence that is fine for internal use can be unworkable for in-process embedding. A licence that is fine for in-process embedding can restrict you from reselling a managed database.

Write down which of the four you are doing before you read any LICENSE file. If you ship a desktop or on-prem product, you are in "bundled" or "in-process." If you run a multi-tenant web app, you are mostly in "hosted." Many teams are in both, because they ship an agent SDK and also run a cloud.

The comparison table: licence and what it means for shipping

Licences as stated by each project at the time of writing. Verify against the current LICENSE file before you rely on any row.

Database	Licence	In-process embed in closed-source product	Bundle and redistribute	Hosted in your SaaS
HelixDB (open-source core)	Apache-2.0	Permitted	Permitted, keep notices	Permitted
LadybugDB	MIT	Permitted	Permitted, keep notice	Permitted
Neo4j Community	GPLv3	Copyleft risk, take advice	Copyleft obligations on distribution	Network use alone does not trigger GPLv3, but check your architecture
Neo4j Enterprise	Commercial	By contract	By contract	By contract
Memgraph	BSL 1.1	Depends on the additional use grant	Depends on the additional use grant	Depends on the additional use grant
SurrealDB	BSL 1.1	Depends on the additional use grant	Depends on the additional use grant	Depends on the additional use grant
FalkorDB	SSPL	Take advice	Take advice	Restricted if you offer it as a service

Two things stand out. Only two rows say "permitted" without a condition you need a lawyer to interpret. And the three "depends" rows are not a criticism of Memgraph or SurrealDB. BSL is a template with a blank where each vendor writes its own permitted use. That blank is the whole question.

The next two sections go through the licences one family at a time.

Permissive: Apache-2.0 and MIT

If your priority is shipping without a licence review, start here.

Apache-2.0 (HelixDB open-source core). The repository at github.com/HelixDB/helix-db carries an Apache-2.0 LICENSE file. We checked it directly rather than relying on the GitHub API field. Apache-2.0 lets you use, modify, embed and redistribute in a closed-source commercial product. You keep the licence and notice files, and you mark modified files. It also includes an explicit patent grant from contributors, which MIT does not spell out. For a company that will be audited by a customer's legal team, that clause is useful. It answers in writing the question "could a contributor sue us for patent infringement over code we shipped?"

Neo4j Community is a database server, not an embedded engine, and does not run against S3-compatible object storage. Because it is Apache-2.0, the in-process case is the easy one. The Neo4j JavaScript/TypeScript driver connects to a running Neo4j server; it does not open an embedded database directly in application code. Our embedded graph database walkthrough shows the setup.

MIT (LadybugDB). LadybugDB is the successor project in the same C++ lineage as Kuzu, which was archived in 2025. MIT is the shortest mainstream licence: do what you want, keep the copyright notice. For shipping a closed-source product, it is as embed-friendly as Apache-2.0. The difference is the missing express patent grant. For most startups that gap is theoretical. If you sell into regulated buyers, ask counsel whether it matters to you.

Our view: either is a safe base for a commercial SaaS. Pick on engineering fit, not on this axis. For the lineage and migration story, see our Kuzu alternatives comparison.

Copyleft and source-available: GPLv3, BSL 1.1 and SSPL

This is where the reading gets expensive.

GPLv3 (Neo4j Community). Neo4j Community is GPLv3, and Enterprise is a separate commercial licence. The GPL's core obligation triggers on distribution. If you bundle Community inside a product you ship to customers, or link it in-process, the combined work may have to be released under the GPL. If you run it on your own servers and your users only reach it through your hosted application, GPLv3 does not by itself reach your code, since network use is not distribution. Whether a given architecture counts as "separate programs" or "one combined work" is a legal judgement, not an engineering one. If you need clustering and other enterprise features, you are buying a commercial licence anyway.

BSL 1.1 (Memgraph, SurrealDB). The Business Source License is not open source by the OSI definition. It lets you read, modify and use the code, but an "Additional Use Grant" carves out what you may do in production, and a "Change Date" marks when the code converts to a more open licence. The licence text is a template. Memgraph and SurrealDB each fill in the grant differently, so you cannot reason about "BSL" in general. Read the parameters in the specific LICENSE file. A common pattern restricts offering the database itself as a competing managed service, which may or may not touch your product.

SSPL (FalkorDB). The Server Side Public License extends copyleft to network use: if you offer the software as a service, you must release the source of the entire service stack, not just your changes. The intent is to stop cloud providers reselling the database. What it does to a SaaS that merely uses the database internally is the part counsel needs to read. The SSPL is not OSI-approved, and some enterprise legal teams reject it on sight. If your customer's procurement has a blocklist, check it.

None of these are bad licences for their authors' goals. They are just bad fits for "embed it and forget about it."

What licence does not decide: open-source core versus HelixDB Cloud

A permissive licence tells you what you may do. It does not tell you what will work. Here is the engineering side, in HelixDB's case.

The Apache-2.0 open-source core is an embedded engine. You can run it inside your application in memory or on disk, as a self-hosted Docker server, or against S3-compatible object storage, selected by configuration. Run modes share the same engine, SDKs and endpoint. Embedding is the cheapest way to get a graph into an agent. There is no network hop and no separate process to babysit.

HelixDB Cloud is a separate managed service. It is object-storage-backed: a gateway routes traffic, a single writer serializes mutations, and reader nodes scale horizontally, with serializable snapshot-isolation ACID transactions. Using it is a commercial relationship with its own plans, not a licence question. You can embed the open-source core and still choose Cloud later, because the SDKs and query format stay the same.

This matters because the licence is only half of "can I commercialise this." The other half is whether the database fits your workload. Some tradeoffs worth weighing:

• Memory model. Neo4j vector indexes are stored in Lucene files on disk and cached by the operating system; they are not entirely in memory. HelixDB's vector implementation runs across memory, disk and object storage. If agent memory grows, that is a cost and capacity difference. See our Neo4j vector index memory sizing guide and the Memgraph alternatives post.

• Single-node ceiling. The open-source embedded core is bounded by single-node capacity. If you expect to outgrow one machine, plan for Cloud or object storage.

• Multi-tenancy. HelixDB supports tenant partitioning on shared infrastructure. That is isolation by partition, not per-user permissions or row-level access control, so your application still owns authorisation.

• Benchmarks. In HelixDB's own benchmarks, graph traversals run up to 1000x faster than Neo4j, and vector performance is on par with Pinecone and Qdrant. These are vendor numbers. Run your own, and our benchmarking guide shows how.

Verdict and a pre-commit checklist

Choose HelixDB open-source core (Apache-2.0) if you want to embed or bundle a graph-vector engine in a closed-source product, want an explicit patent grant, and need graph traversal, vector search and BM25 full-text in one query for agent memory, GraphRAG or a company brain.

Choose LadybugDB (MIT) if you want the simplest licence text and an embedded engine in the Kuzu C++ lineage, and you are comfortable without an express patent grant.

Choose Neo4j if you already run it, you keep it as a separate server process behind your own API, and you either accept GPLv3 for Community or will pay for Enterprise. Do not bundle Community into a shipped closed-source product without advice.

Choose Memgraph or SurrealDB if their BSL 1.1 Additional Use Grant explicitly covers what you do, and you have read the Change Date. Both can work. Neither is a default.

Choose FalkorDB if your counsel and your buyers' legal teams have cleared SSPL. Expect that to take time.

Before you commit, run this checklist:

1. Open the LICENSE file in the exact repository and version you will ship. Do not trust the badge.

2. Write down which of the four cases you are in: in-process, bundled, hosted, internal.

3. For BSL, read the Additional Use Grant and Change Date word for word.

4. Check your dependencies' licences too, not just the database's.

5. Check customer procurement blocklists for SSPL and BSL.

6. Ask counsel. This post is not legal advice.

Questions to put to your own lawyer

Reading a LICENSE file gets you most of the way. Counsel closes the gap. Bring specific questions, not "is this okay?"

First: describe your architecture in one paragraph and ask whether it counts as distribution, network use, or a combined work under the licence in question. A diagram of which processes talk to which helps more than prose.

Second: ask what happens if you change the deployment. Many teams start hosted and later ship an on-prem or desktop build for a large customer. A licence that was fine on day one can stop being fine on day 400. Under permissive licences, that change is a non-event. Under copyleft or BSL, it can be a renegotiation.

Third: ask about contributions. If you patch the database and keep the patch private, which licences allow it? Apache-2.0 and MIT do. GPLv3 may not, once you distribute. SSPL may not, once you offer a service.

Fourth: ask about your own customers. Enterprise buyers send security and legal questionnaires, and some ask for a list of open-source licences in your stack. Permissive licences go through those questionnaires quickly. Source-available licences get follow-up questions, and sometimes a rejection.

None of this makes the non-permissive databases unusable. It makes them slower to adopt, and that cost belongs in your estimate next to the engineering work. For a small team trying to ship an agent memory feature in a quarter, a week of legal back-and-forth is a real line item.

Conclusion

If your commercial SaaS needs an embedded graph engine and you would rather not spend a week with counsel on copyleft edge cases, start with the Apache-2.0 core. Install HelixDB, open an embedded database from your TypeScript, Python, Go or Rust code, and prototype your agent memory or GraphRAG flow against graph, vector and full-text queries in one engine. If it fits, star the repo on GitHub, and join the Discord to show us what you are building. When one node stops being enough, point the same SDKs at HelixDB Cloud. Then, whatever you pick, read the LICENSE file yourself and get a lawyer to sign off.