Hacker News new | past | comments | ask | show | jobs | submit login
Sharing an SQLite database across containers is surprisingly brilliant (medium.com)
28 points by vinnyglennon 9 days ago | hide | past | web | favorite | 10 comments





Can someone explain the technical details around this? Specifically:

1) How are writes/updates propagated to all other containers/hosts? Is this based on the assumption that the containers will only read from the database, and not write to it? And that any writes being made externally, only need to be deployed to new containers, and it is fine for existing containers to read stale values?

2) Is there anything special about SQLite that enables this design? Or would someone else be able to do the same thing with a config.json file that is then read and parsed by each instance of the application?

3) I'm presuming that latency is vastly improved because real-time network requests are avoided. Can the exact same result be achieved by eagerly prefetching the config data at startup? Deploying a complete copy of the SQLite database to all containers, is in essence doing the same thing.

4) How does this solve the problem of "major incidents were happening all the time"? Is reading from a RDS (or similar) database really that fragile?


Late reply but you might find it useful to check out this post which is much more detailed https://segment.com/blog/separating-our-data-and-control-pla...

I'm also left with some questions however. If the issue is the high read latency with a centralised settings database, why not deploy read replicas?


I agree with the article, I have a multiprocess app that works great this way under Windows and Linux. It's nice having less moving parts for my application.

Just a wee grammatical nitpick about the article title if the original author is reading:

Sharing an SQLite database -> Sharing a SQLite database


Depends on whether you pronounce it see-kew-lite or ess-kew-lite :)

I was always under the impression that pronouncing “SQL” as “sequel” was a marketing meme started by Microsoft for their proprietary software.

When I was at college in the mid 80's and studied relational databases (and stuff like CODASYL :) ) we pronounced it "sequel". This was long before I was aware MS had their own SQL product (edit: which first shipped in 1989 on OS/2). As per our lectures, the "sequel" pronunciation dates back to when there was a database language named "SEQUEL"; and despite the name change, "sequel" stuck as the pronunciation.

In all my years in the industry working with SQL databases (since the early 90's), virtually no-one familiar with these products spelled out S-Q-L as the pronunciation.

https://en.wikipedia.org/wiki/SQL#History


I think when you write "SQL", regardless of pronunciation, it should be "a".

no, the person you're replying to is correct.

the rule is about the sound of what follows, not whether or not it's a consonant/vowel:

- an SSD if you pronounce it ess-ess-dee

- a universal constraint - vowel but a is correct here due to sound

- an SQL database - again, pronunciation dependent


“an” sounds more natural to my ears, right or wrong.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: