cowsql (/ˈkaʊ,siːkwəl/ listen) is a C library that implements an embeddable and replicated SQL database engine with high availability and automatic failover.

cowsql extends SQLite with a network protocol that can connect together various instances of your application and have them act as a highly-available cluster, with no dependency on external databases.

The name "cowsql" loosely refers to the "pets vs. cattle" concept, since it's generaly fine to delete or rebuild a particular node of an application that uses cowsql for data storage.

Asami is both similar to and different from other graph databases. Some of the goals of the project are:

Schema-less data. Data can be loaded without prior knowledge of its structures.
Stable. Storage uses immutable structures to ensure that writes cannot lead to data corruption.
Multiplatform. Asami runs on the Java Virtual Machine and on JavaScript platforms (browsers, node.js, etc).
Ease of setup. Asami managed storage requires no provisioning, and can be created in a single statement.
Pluggable. Storage is a pluggable system that allows for multiple storage types, both local and remote.
Analytics. Graph analytics are provided by using internal mechanisms for efficiency.

Asami is a schemaless database, meaning that data may be inserted with no predefined schema. This flexibility has advantages and disadvantages. It is easier to load and evolve data over time without a schema. However, functionality like upsert and basic integrity checking is not available in the same way as with a graph with a predefined schema. Optional schemas are on the roadmap to help with this.

Asami also follows an Open World Assumption model, in the same way that RDF does. In practice, this has very little effect on the database, beyond what being schemaless provides.

If you are new to graph databases, then please read our Introduction page.

Asami has a query API that looks very similar to a simplified Datomic. More details are available in the Query documentation.

This document defines the grammar for schema data.

In this presentation, we explore the concept of knowledge databases, which represent entities and their relationships in a structured and semantic way. By combining this model with immutability—where data is never overwritten, only accumulated—it becomes possible to build systems with a complete, auditable history and native versioning. This approach is particularly powerful in complex ecosystems like Nubank’s, where thousands of microservices interact. We’ll show how modeling these interactions as a knowledge database allows us to uncover patterns, dependencies, and insights that are otherwise hidden, ultimately helping teams understand and evolve the system more safely and intelligently.

Biography

Darlei Soares and João Nascimento are software engineers and data enthusiasts with deep experience in building systems around immutable knowledge databases. Currently part of the engineering team at Nubank, Darlei and João both work on designing and maintaining highly distributed services that leverage Datomic at scale, powering financial operations for millions of customers.

Recorded Nov 13, 2025 at Clojure/Conj 2025 in Charlotte, NC.

This topic documents the data format for Datomic datalog queries and rules. If you want to follow along at a REPL, most of the examples on this page work use the mbrainz-subset database and are in the Day of Datomic Cloud repository.

This docs/ directory is the documentation “source of truth” that lives alongside the code and evolves with it.

• Start with SUMMARY.md as the navigation spine.
• Add pages incrementally; the structure is designed to work well with future tooling (mdBook, Zola, Docusaurus, etc.).

Fluree Server wraps the fluree/db library with an HTTP API server and consensus capabilities. While fluree/db can be used directly in applications for embedded database functionality, Fluree Server provides the infrastructure needed for multi-client environments requiring consistent transaction ordering, ledger state management, and distributed consensus.

The server can run as either a consensus-participating node for transaction processing or as a query-only node for horizontal scaling. Multiple servers can form a cluster for fault tolerance and performance.

Key Features:

• High Availability: Automatic failover and work redistribution when servers join or leave
• Guaranteed Ordering: Consistent transaction processing across all nodes
• Horizontal Scaling: Add query-only nodes for read performance
• Load Distribution: Automatic workload balancing across consensus nodes
• Duplicate Prevention: Built-in transaction deduplication

A graph database built for data that matters. Temporal, verifiable, standards-compliant.

Fluree stores data as RDF triples with complete history, integrated search, and fine-grained access control — in a single binary with no external dependencies.

Billions of triples on commodity hardware. Over 2M triples/second bulk import. Benchmark leader across 105 W3C SPARQL queries.

An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.

• Overview | Prometheus

cowsql (/ˈkaʊ,siːkwəl/ listen) is a C library that implements an embeddable and replicated SQL database engine with high availability and automatic failover.

cowsql extends SQLite with a network protocol that can connect together various instances of your application and have them act as a highly-available cluster, with no dependency on external databases.

The name "cowsql" loosely refers to the "pets vs. cattle" concept, since it's generaly fine to delete or rebuild a particular node of an application that uses cowsql for data storage.

Ecto is commonly used to interact with databases, such as PostgreSQL and MySQL via Ecto.Adapters.SQL (source code). Ecto is also commonly used to map data from any source into Elixir structs, whether they are backed by a database or not.

See the getting started guide and the online documentation for more information. Other resources available are:

• Programming Ecto, by Darin Wilson and Eric Meadows-Jönsson, which guides you from fundamentals up to advanced concepts

• The Little Ecto Cookbook, a free ebook by Dashbit, which is a curation of the existing Ecto guides with some extra contents

Columnar time-series database with high performance ingestion and SQL analytics you know and love from QuestDB open source, now on the cloud.

This text exists mainly so that I paste the URL into the #mysql channel in Libera IRC.

The mysqldump tools allows you to convert a MySQL database server or individual schemas back to SQL. You are left with a script that is supposed to be loadable into a target server and gives you back the full database, including all objects in it.

This API has been defined to encourage similarity between the Python modules that are used to access databases. By doing this, we hope to achieve a consistency leading to more easily understood modules, code that is generally more portable across databases, and a broader reach of database connectivity from Python.

Comments and questions about this specification may be directed to the SIG for Database Interfacing with Python.

For more information on database interfacing with Python and available packages see the Database Topic Guide.

This document describes the Python Database API Specification 2.0 and a set of common optional extensions. The previous version 1.0 version is still available as reference, in PEP 248. Package writers are encouraged to use this version of the specification as basis for new interfaces.

amnesia wraps everything exposed by mnesia, from fragments to fragment hash, access and backup behaviors.

It provides a simplified table and database definition with some macros and allows you to use the nice Enum functions on tables by implementing the Enum.Iterator protocol.

Everything is documented and specced, even the unspecced and undocumented parts of mnesia that have been wrapped.

The documentation often refers to mnesia functions, I strongly suggest you read mnesia's documentation too, since it has a lot of valuable information.

At a high level, Mnesia is a Database Management System (DBMS) that is baked into OTP. Thus, if you are using Elixir or Erlang, you have the ability to leverage Mnesia out-of-the-box. No additional dependencies need to be installed and no separate systems need to be running. Before considering migrating everything from your existing database to Mnesia, let's discuss what Mnesia was designed for and what problems it aims to solve.

Mnesia was largely designed to solve the problems that existed in the telecommunications problem space. Specifically, some of the following requirements needed to be fulfilled (check out this research paper for more details):

• Fast key/value lookup times where you need soft real-time latency guarantees. A soft real-time system is one where the system should be able to service the majority of its requests within a given time frame and a failure to do so generally means degradation of service (i.e the data is no longer useful after the time frame has passed). A hard real-time system, on the other hand, is a system that must respond within a given time frame or else it is considered a system failure.

• The ability to perform complex queries (like you would in SQL for example), but without soft real-time latency guarantees

• A high level of fault tolerance

• Github: amnesia - mnesia wrapper for Elixir

Back up your database when you open KeePass

There is a soft 2 TB boundary and a hard 10 TB boundary. They are defined by physics, so they are not negotiable and cannot be removed by throwing money at it.

When you reach these sizes, talk to your DBA about alternatives. Treat the 2TB boundary as a complexity inflection point, and use the remaining time as runway to branch out into alternative solutions.

When you insert data into a database and run COMMIT you expect things to be there: Atomically, Consistent, Isolated and Durable, like Codd commanded us 40 years ago, but also quickly. There is a surprising amount of sophistication being poured into this, but since I do not want to shame MongoDB and Redis developers in this post, I am not going to talk about that much in this place.

We are instead trying to understand what our databases are doing all day, from the point of view of the storage stack.