EliasDB: a graph database in Go that you can embed or serve

One database, two deployment shapes

EliasDB describes itself as a graph-based database which aims to provide a lightweight solution for projects which want to store their data as a graph. The word lightweight is doing real work in that sentence, because the project has two sharply different ways to run.

It can be embedded. When used as an embedded database it supports transactions with rollbacks, iteration of data and rule based consistency management. That is the shape for a Go program that wants graph storage without running a server, and the library is imported into your binary, since the module path is github.com/krotik/eliasdb and the package lives under the repository.

Or it can be a standalone application, in which case it comes with an internal HTTPS webserver which provides user management, a REST API and a basic file server. The same executable is both the server and the client console, and the command line interface has two main tools, console and server.

That dual shape is unusual for a database and it is the main design decision. An embedded store disappears into your process, which means no network hop, no separate version to deploy and no connection pool to tune. A standalone server gives you a database other programs and other languages can talk to over REST and GraphQL. The same codebase offers both, and the cost is that some of the features, most obviously the web terminal and the scripting console, only exist in the server shape.

The project is written in Go from scratch and, the README notes, only uses gorilla/websocket to support websockets for GraphQL subscriptions. The go.mod declares go 1.12, and the three requirements are gorilla/websocket v1.5.3, krotik/common v1.5.1 and krotik/ecal v1.6.3.

Nodes, edges and a key-value store underneath

The feature list describes the storage model in enough detail to reason about.

The base is a custom key-value store which supports transactions and memory-only storage. Everything else in the database is built on that, which is the opposite of the usual arrangement where a graph engine sits on a relational database, and it has an obvious consequence: there is no SQL underneath, so the graph operations are the native operations rather than a translation of them.

On top of that, data is stored in nodes, which are key-value objects, and nodes are connected via edges. Stored graphs can be separated via partitions, so a single database can hold several independent graphs. Deletions cascade, which the README puts as delete one node and all its children, and that is a graph semantic rather than a relational one, where a delete is a row operation unless you have written the foreign keys and the triggers yourself.

Everything stored is indexed and can be quickly searched via a full text phrase search, and there is a find command in the console for exactly that.

So the model is: a transactional key-value substrate, a graph of nodes and edges on top of it, partitions to separate graphs, cascading deletion as a first class behaviour, and full text search over the whole store. If your data has naturally recursive relationships, that is a good fit, and if it is mostly rows that happen to have a foreign key, the graph layer is a cost rather than a benefit.

Three ways in: EQL, GraphQL and the REST terminal

EliasDB offers more than one way to ask questions of it, and the differences matter.

EQL is the project's own query language, with an SQL like syntax, and the README describes it as being there for more complex queries. The tutorial in the repository covers the basics of EQL and shows how data is organized, and the console can run EQL queries directly.

GraphQL is the second interface, and the README notes that EliasDB has a GraphQL interface which can be used to store and retrieve data. There is a separate tutorial for using EliasDB with GraphQL, and the websocket support exists for GraphQL subscriptions, which is the one dependency the whole project carries for that purpose.

The third is the REST API, which is what the terminal itself uses to talk to the backend. It can be browsed using a dynamically generated swagger.json definition, served at https://localhost:9090/db/swagger.json, and the README links a swagger petstore view of the same definition for the latest version.

That dynamism is the interesting engineering point. The API description is generated from the running server rather than maintained by hand, so the contract you browse is the contract the server implements, and there is a swagger.json at the repository root for the latest version to compare against.

The console, which is the same binary's second tool, has its own command set. The listed commands are export, which exports the last output, find for a full text search of the database, help to display descriptions for all available commands, info which returns general database information, part which displays or sets the current partition, and ver for server version information. You exit with q, and it is also possible to directly run EQL and GraphQL queries on the console, with the arrow keys cycling through the command history.

ECAL replaces database operations with your own code

The scripting layer is the most unusual thing in the project, and it is the feature that distinguishes EliasDB from a plain graph store.

EliasDB supports a scripting language called ECAL to define alternative actions for database operations such as store, update or delete. The README says the actions can be taken before, instead, or after the normal database operation, and the mechanism for taking over instead of running the built in behaviour is a call to db.raiseGraphEventHandled(). The language is powerful enough to write backend logic for applications.

That is a different shape from a stored procedure or a trigger. Instead of expressing a rule in a database language, you write code in a scripting language that the database engine interprets, and you can take over the whole operation rather than only observing it. The actions can run before, which lets you validate or rewrite the operation, instead, which lets you replace it, and after, which is the familiar hook point.

The interpreter lives in its own repository, krotik/ecal, and the project has a VSCode integration that supports syntax highlighting and debugging via a debug server, so the scripts are edited and stepped through with real tooling rather than in a text box.

The feature is also gated. The server only offers the -ecal-console option, an interactive interpreter console for ECAL, if the EnableECALScripts configuration option is set, and that console can be used to inspect and modify the runtime state of the interpreter.

Running the server and talking to it

The standalone path is the fastest way to see the thing work.

You download a pre-compiled package for Windows, win64, or Linux, amd64, extract it and execute the executable with:

eliasdb server

The executable should automatically create three subfolders and a configuration file, and it should start an HTTPS server on port 9090. To see a terminal you point your web browser at:

https://localhost:9090/db/term.html

After accepting the self-signed certificate from the server you should see a web terminal. Stopping it is either a CTRL+C or overwriting the content in eliasdb.lck with a single character, which is a lock file acting as a stop flag.

The Docker route is the same idea with the files kept on your disk:

docker pull krotik/eliasdb

docker run --user $(id -u):$(id -g) -v $PWD:/data -p 9090:9090 krotik/eliasdb server

That exposes port 9090 from the container on the local machine, and all runtime related files are written to the current directory as the current user and group. The console is a second container:

docker run --rm --network="host" -it -v $PWD:/data --user $(id -u):$(id -g) -v $PWD:/data krotik/eliasdb console

The console tool has its own options, including -host with a default of localhost and -port with a default of 9090, plus -exec to run a single line and -file to read commands from a file. The server tool has -export and -import for moving a database as a zip file and -no-serv to do the initialisation without starting the server.

Clustering means joining instances

EliasDB supports to be run in a cluster by joining multiple instances of EliasDB together, and the details live in a separate document, cluster.md, with the repository also carrying a cluster/ directory and images of a joined cluster, its terminal and its working state.

That is a very brief description, and the brevity is informative. EliasDB does not present cluster replication as a headline feature with a configuration matrix and a consistency story attached. What it offers is a way to join instances, and the cluster configuration is a named file in the configuration table, with ClusterConfigFile, ClusterLogHistory and ClusterStateInfoFile among the options in eliasdb.config.json, the single configuration file the database uses and which is created with defaults on first start.

For an evaluation, the honest reading is that clustering is a feature to study rather than one to bet on. A project that documents its clustering in a single markdown file, with the details in that file rather than in the README, is telling you where the complexity lives, and the console's part command, which displays or sets the current partition, is a hint about the model.

The rest of the operational surface is small and worth knowing. The server and console are the two tools. The configuration is one JSON file. The data can be exported to and imported from a zip file, which is also the obvious way to move a database between environments. And the Makefile builds for linux amd64, darwin amd64, windows amd64, arm and arm64, with a dist target that produces tarballs for each platform and ships the LICENSE and NOTICE files alongside the examples.

Where EliasDB is the wrong tool

The limits here are about fit and about the project's shape, and one of them is the release record.

The release history is the first thing to check. The published versions are v1.2.0 from 2021-05-09, v1.3.0 from 2022-03-19 and v1.4.0 from 2022-08-14, so the newest tagged release is more than four years old, while the last push to the repository was on 2026-08-25. The code is being touched and no release has been cut from it, which means the version you would depend on from a package registry is not the version in the repository, and the go.mod still declares go 1.12, a language version from before the generics era.

The second limit is the data model. EliasDB stores nodes and edges with cascading deletion, and a project whose data is naturally tabular, with fixed columns and reports over them, will be modelling its problem in a shape that fights it. The query languages are EQL and GraphQL, and while GraphQL is a good fit for a client that wants to pick its fields, neither is a report writer.

The third is the operational surface of the server shape. The standalone server is a single Go binary with an HTTPS webserver, a web terminal, a REST API and user management, and the repository carries a Jenkinsfile, a .goreleaser.yml and a Dockerfile, which is a small project infrastructure. It is a good fit for an embedded use in a Go service, and a less obvious choice as the shared database for a polyglot organisation.

The fourth is the alternative approach worth naming, since it is the honest comparison. Instead of adopting a graph database, you can model the same data in a relational store and write the traversals as recursive queries. The difference in approach is that EliasDB gives you the traversal, the indexing and the cascading semantics for free at the cost of a storage model that is not relational, while the relational route keeps your existing tooling, reporting and backup story at the cost of writing the graph logic yourself.

Editorial conclusion

Adopt EliasDB if your data is genuinely graph shaped and you want either an embedded store in a Go program or a small self contained server with a REST API, a GraphQL interface and a scripting layer, without assembling a database stack. Do not adopt it for a workload that is mostly relational, and do not adopt it expecting an active release cadence, because the newest tagged release is v1.4.0 from 2022-08-14 even though the last push was on 2026-08-25. Verify first that your data model fits nodes and edges rather than tables, that the transactions and rollback support in embedded mode meets your needs, and that the clustering model in cluster.md matches how you intend to shard.

Frequently asked questions

Official sources

1. Issues
2. krotik/eliasdb on GitHub
3. License: MPL-2.0
4. README
5. Releases