HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
share
sharedb
JavaScript2016–2021
share / sharedb

sharedb

Realtime database backend based on Operational Transformation (OT)

Data & Databases
Explore on GitHubRead Hacker News discussions
15Distinct people
24Mentions
0Explicit recommenders
6.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Realtime database backend based on Operational Transformation (OT)

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year24 dated mentions

Observed mentions: 2016-08-02 23:41:16 UTC to 2021-09-23 17:21:44 UTC.

02462016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC606
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC716
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC505
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101

What Hacker News says

6 sources
Leftium·Dec 31, 2016
Wow! Front-end only is actually a great advantage for me. I actually tried to modify [ShareDB] to be front-end only[1]. (ShareDB uses WebSockets or any other full duplex stream; it's a great reference if you want to implement true client/server.) I guess my use case is quite unique: [Todo.taskpaper] needs to sync multiple "views" of a single document in the same web app. Right now it uses very naive syncing; I'm going to try to upgrade it to blue-ot.js. [ShareDB]: https://github.com/share/sharedb [1]: http://stackoverflow.com/q/40616650/117030 [Todo.taskpaper]: https://todo-taskpaper.leftium.com
In Show HN: Operational transform for realtime collaborative editing in JS/Flow
oakesm9·Sep 21, 2016
How does this compare to something like ShareDB (https://github.com/share/sharedb)? It seems on the face of it that the data part of it is pretty similar (albeit Deepstream is more fully featured with auth etc.), however, there is no mention of how Deepstream handles conflict resolution if two clients are modifying the state. Internally ShareDB uses Operational Transformation with special operations which are designed for use in JSON documents. Does anyone know how this works in Deepstream?
In Deepstream.io – Open Realtime Server
nateps·Aug 17, 2016
We've been developing ShareDB (https://github.com/share/sharedb), a JSON OT system, and using it in production at Lever for 3 years now. CRDT has some strong advantages in decentralized applications with a need to avoid a central server. But in practice, web apps today do generally have a central server. I think the core advantages of OT over CRDTs are actually these practical concerns: being able to design transformations that are more intuitive to application developers, easily cleaning up old operation history, and real world production use and examples of the technology already. One thing OT has enabled us to do that you cannot do as easily in a CRDT is to support turning off publishing of operations when we do large migrations and create huge numbers of ops at once. Because ops have a strict ordering and versioning, clients can lazy
Read the rest
get the ops that they have missed if needed later because they submitted a modification on a document or see an even newer op and need the intermediate ops. In a CRDT, you have to make sure that all the clients get all the ops in order to converge. It sounds simple but can be complex in practice. Another practical issue I'd add is that these algorithms sometimes place the burden of resolving the outcome of concurrent edits at read time vs. write time. With OT, you generally do a lot of complex work to figure out how to transform ops at write time, but when you read, you just read the already fully updated document in its native format. CRDT systems often store the document in a format that can be written to very cheaply as it is commutative, but the work gets pushed to read time when you have to collapse a tree full of all its history into a different data structure, such as a string for text editing. One is not strictly better than the other, but many production systems are vastly more read heavy than write heavy, so less obvious tradeoffs like this can become extremely important in production use.
In A Conflict-Free Replicated JSON Datatype
nateps·Aug 17, 2016
Author of ShareDB (https://github.com/share/sharedb) here. ShareDB is a stable production JSON OT system that powers the entire backend for Lever (https://www.lever.co/). All of Lever's apps, backend services, migration scripts, etc. go through ShareDB. It scales horizontally; over 1000 companies use Lever, including companies with 1000s of employees, like Netflix and Yelp. There are some simple examples in the repo to get you started. Please let us know if you have any questions getting going!
In A Conflict-Free Replicated JSON Datatype
josephg·Aug 2, 2016
I've played with this problem on and off over the last few years. ShareDB[1] is powered by JSON OT[2], in which each change describes the meaning behind what you're trying to do. (For example, 'increment counter' is different from 'change counter from 2 to 3'. They look the same, but behave differently in the case of conflicts). Just knowing what changed often isn't enough to do proper resolution. I've spent years on and off playing with a better, faster, stronger version of the JSON OT code[1] which also supports arbitrary object reparenting. You run into problems where you really want conflicts as well. For example, given {x:{}, y:{}} user A moves x into y, and user B moves y into x. There's no good solution to resolving this without more information or conflict markers & humans. Doing this in a P2P setting is hard & interesting. Very c
Read the rest
ool stuff though! [1] https://github.com/share/sharedb [2] https://github.com/ottypes/json0 [3] https://github.com/josephg/json1
In Show HN: Noms – A new decentralized database based on ideas from Git

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.