blob: dcef27c5673559d84ad5e2673c8d4ae14943dde0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
# ard-006: SQLite storage for the CRDT sync server
Satisfied by: task-021
## Problem
The CRDT sync server must persist domain entities.
## Options
- RDBMS
- SQLite
- Postgres
- MariaDB
- CockroachDB
- Document DBMS
- MongoDB
- FerretDB
- DocumentDB
- Vector DBMS
- Redis
- OpenSearch
- Chroma
- Milvius
- Qdrant
- Weaviate
- Postgres with the pgvector extension
- Apache Cassandra
- Valkey
- CockroachDB
## Decision
The CRDT server will persist entities to an SQLite file.
I'd like to use a vector database, in order for the port to IndexedDB to be as
smooth as possible. However, the key-based API for looking up documents is
inherently inconvenient, and many of the options target ML applications.
A well-supported RDBMS such as MariaDB or Postgres would be a good choice, if it
only adds friction to the development process, since you have to update database
schemas.
FerretDB and its dependency, DocumentDB, would be acceptable document databases,
except that DocumentDB is owned by Microsoft.
By process of elimination, I'll have to use an RDBMS.
> For device-local storage with low writer concurrency and less than a terabyte
> of content, SQLite is almost always a better solution \[than a client-server
> database].
>
> ([SQLite use case guide](https://www.sqlite.org/whentouse.html))
SQLite it is!
|
