Bedrock VS SQLite

Also Expensify's Bedrock, which powers their famous "Scaling SQLite to 4M QPS" article:

https://bedrockdb.com/

https://use.expensify.com/blog/scaling-sqlite-to-4m-qps-on-a...

Lots of things don't need failover, but if you do, you can use Bedrock, which is built on sqlite.

Vapor[0] based on Swift. Advantage of this is that you don't have to evaluate multiple frameworks for Swift and suffer paralysis by analysis. All the Swift community is behind one framework.

The next is Actix[1] based on Rust. There are many frameworks in Rust and most of them have not reached 1.0 And which framework will survive becomes a question.

Other not so well-known is Wt[2] based on C++. This actually is created for programmers who are not web developers. The development experience is similar to desktop app development like Qt.

If that is not acceptable then Django[3], based on Python, is the one that will be good for you.

For the front-end I would recommend Flutter[4]. As much as I dislike getting tied to a single company for whom the framework is not their bread-and-butter, I don't see any other viable options to Flutter that will cover all web, mobile and desktop out of the box.

For databases, I would recommend BedrockDB[5], if you are not averse to SQLite. Or FoundationDB[6], if you want NoSQL. But if you are not concerned about horizontal scalability or okay with self-managing database availability, then PostgreSQL[7] is a very good option.

For push notifications, PushPin[8] is a good option.

[0] https://vapor.codes

[1] https://actix.rs

[2] https://webtoolkit.eu

[3] https://www.djangoproject.com

[4] https://flutter.dev

[5] https://bedrockdb.com

[6] https://www.foundationdb.org

[7] https://postgresql.org

[8] https://pushpin.org

Recently I stumbled upon BedrockDB[0] from Expensify. It is based on SQLite and has very interesting idea on HA and distributed DB.

[0] https://bedrockdb.com

This is not SQLite though, also the test is trivial compared to TPC: https://github.com/Expensify/Bedrock/blob/dbarrett_perftest/...

Don’t forget BedrockDB (built on SQLite) that’s used in production at Expensify.

How it scales as well.

https://bedrockdb.com/

https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-q...

Instead of just continuously firing off questions when you acknowledge you’re not even reading the articles linked too … nonetheless, bedrockdb has replication and failover.

https://bedrockdb.com/

Oh that's a huge dick move. And this behaviour you mention, "people seeking help from libcurl for xcurl" is an already documented and detrimental problem. You can see why Sqlite temp files has an extension of "etilqs". That's a grandiose example of this. That was not even a documentation link!

https://github.com/mackyle/sqlite/blob/3cf493d/src/os.h#L52-...

I could set up a redirect to the '/raw/' pages but then the syntax highlighting is gone.

The same page is perfectly viewable over plain html on gothub[2] though.

Github also seems to be hiding their "Assets" (binaries et al) on the "/releases" page for some projects behind javascript(especially older versions).[3] Something else that wasn't the case about ~1.5 years ago.

Would be great if gothub could unshackle the links to those as well[4], but that appears to not be working at the moment[5] .

This project appears to be a more performant(measurably so), more privacy friendly(as Microsoft won't have a record of your interest in certain projects) alternative front-end for "non logged in" github users.

I like it, but it still needs work.

[1] https://github.com/mackyle/sqlite/blob/18cf47156abe94255ae14...

[2] https://gh.bloatcat.tk/mackyle/sqlite/blob/18cf47156abe94255...

[3] https://github.com/mikf/gallery-dl/releases

[4] https://gh.bloatcat.tk/mikf/gallery-dl/releases

[5] https://codeberg.org/gothub/gothub/issues/74

Its a horrible link. It points to a specific commit...Okay, so it must have something to do with the commit? Nope, the commit is putting a limit on the number of symlinks to resolve for whatever reason. Then you also notice that the link is simply a link to the file, not a specific line (something like https://github.com/mackyle/sqlite/blob/18cf47156abe94255ae14...), so you are expected to read the whole C file to figure out why.

Looks like the line numbers were lost: https://github.com/mackyle/sqlite/blob/18cf47156abe94255ae14...

It's because McAfee started using SQLite, angry users would stumble upon the files, do a minimum of searching or thinking, and be furious at SQLite developers.

Daniel Stenberg, developer of very popular opensource library/utility curl, once received a threatening email:

https://daniel.haxx.se/blog/2021/02/19/i-will-slaughter-you/

SQLite developers were receiving phone calls in the middle of the night, so decided to change temporary files prefix:

https://github.com/mackyle/sqlite/blob/3cf493d/src/os.h#L52-...

In both cases, their libraries were used in some other software, which upset users.

>Sure, lets pipe user feedback directly into GitHub issues. Good luck with that if you have a hundred issues a day.

Average use less than poorly educated about technology. Their level of competence when raising a bug simply pathetic a lot of times. I manage an email server for a family, they write to me "email doesn't work", I check issue and respond "domain should be gmail.com not gmail,com" (notice the comma).

This reminded me how sqlite team was getting emails or calls at night, from some random people because another software was crashing. User went to "about/legal" and found license of SQLite, so obviously they decided to contact SQLite and complain on bad software. https://github.com/mackyle/sqlite/blob/3cf493d/src/os.h#L52-...

Now imagine facebook api breaks backwards compatibility, so you get 1000 of new issues in a day with title "broken", "doesn't work", "shit is crahing so gave 1* fix it now I might review it later".