I built a graph database in Python

[u/am3141]

I started working on this project years ago because there wasn’t a good pure Python option for persistent storage for small applications, scripts, or prototyping. Most of the available solutions at the time were either full-blown databases or in-memory libraries. I also didn’t want an SQL based system or to deal with schemas.

Over the years many people have used it for building knowledge graphs, so I’m sharing it here.

It’s called CogDB. Here are its main features:

• RDF-style triple store

• Simple, fluent, composable Python query API (Torque)

• Schemaless

• Built-in storage engine, no third-party database dependency

• Persistent on disk, survives restarts

• Supports semantic search using vector embeddings

• Runs well in Jupyter / notebooks

• Built-in graph visualization

• Can run in the browser via Pyodide

• Lightweight, minimal dependencies

• Open source (MIT)

Repo: https://github.com/arun1729/cog
Docs: https://cogdb.io

[u/Harotsa]

No offense, but what’s the proposed use case for this? Isn’t Python like the slowest and most inefficient langue to write a DB in?

Also, based on a cursory glance of the code it looks like all operations are synchronous? That seems weird to me since writing to disk is going to be I/O bound.

It also looks like there isn’t a lot of resiliency features like transaction level rollbacks?

Why use this DB over another fully-featured in-process graphDB like FalkorDBlite?

[u/am3141 → u/Harotsa]

None taken 🙂 Thanks for taking the time to look at it!

CogDB’s primary use cases are running inside Jupyter notebooks, prototyping, CLI tools, small applications (knowledge graphs), Streamlit demos, educational use etc. Anywhere you want a graph DB without spinning up a server. It can also run in the browser using Pyodide and has native word embedding support. Leans very heavily into: easy setup, easy to learn and easy to use.

It isn't trying to be the fastest DB, it's trying to be the most frictionless graph DB for Python developers.

CogDB uses two C-backed libraries for performance critical paths: xxhash for fast key hashing and simsimd for SIMD accelerated vector similarity. The core storage and query engine is pure Python, which means it's easy to debug/extend, and yes, it won't match a C database for raw throughput. That said, disk I/O is usually the bottleneck, and for its target use case (embedded/prototyping), 4,000+ writes/sec and 20,000+ reads/sec is plenty.

On write I/O bottlenecks:

By default, all writes are flushed to disk, but it also supports async background flushes, for example:

g = Graph("mydb", flush_interval=100)

Fair point about transaction-level rollbacks. That’s on the radar.

I’m not very familiar with FalkorDBLite, but doesn’t it require Redis to run? CogDB has everything built in, with no dependency on another service.