cockroach VS rqlite

You absolutely can write very high performance software in Go, that's kind of the point. You can efficiently interface with C libraries. You can create the sort of software everyone says should be done in Rust, like databases and web servers and system orchestration and games and every other goddamn thing that people will say isn't the right choice for Go.

PostgreSQL Parser separated from CockroachDB, a distributed DB.

Spencer Kimball (now CEO at CockroachDB) wrote an interesting article on this topic in 2021 where they created spencerkimball/stargazers based on a Python script. So I started thinking: could I create a data pipeline using Nifi and Kafka (two OSS tools often used with Druid) to get the API data into Druid - and then use SQL to do the analytics? The answer was yes! And I have documented the outcome below. Here’s my analytical pipeline for Github stars data using Nifi, Kafka and Druid.

One of the most popular distributed DB is built in Go: https://www.cockroachlabs.com/

Recently, I worked on such an integration with Splunk. The Splunk dashboard files that emulate the DB Console are now available in our repo for everyone's benefit.

Technically not postgres, but could be worth checking out cockroach db, it can use any postgres driver from programming languages and is build for distribution. I recently moved from postgres to cockroach (with golang postgres driver) and didnt need to change a single query

Is this somehow related to rqlite? https://rqlite.io/

The architecture is very similar.

rqlite[1] creator here. This offering is completely new to me. Welcome to the party, that's what I say. I started doing what they are doing about 10 years ago. :-)

https://www.philipotoole.com/9-years-of-open-source-database...

The post makes a fairly big point of the shortcomings of statement-based replication (like rqlite does).

What they state is correct -- non-deterministic SQL will be a problem, but it's not a difficult problem to solve. Just parse and rewrite the statement before sending it to Raft. It's exactly what rqlite does[2] (though there is more to do). However they claim that there are two concerns with this approach.

>This solution introduces a runtime delay because each SQL statement must be parsed and analyzed.

The delay is insignificant compared with the delay introduced by Raft consensus. This is not a valid concern. I'm surprised they even mentioned it.

>More importantly, it increases the difficulty of staying up-to-date with the new versions of the underline SQL engine (SQLite in this specific case) because the custom parser must be updated each time a new SQL function/feature is introduced.

Theoretically true, not true in practice. Any competent programmer can update any parsing code in a matter of hours.

[1] https://rqlite.io

[2] https://rqlite.io/docs/api/non-deterministic/

rqlite creator here. It's not related to my work, best of luck to them.

[1] https://rqlite.io

Anyone knows how the DB this is about, https://rqlite.io/, compares with https://dqlite.io/ by Canonical (both seem to be distributed versions of sqlite)?

This project comes to mind https://github.com/rqlite/rqlite but I've never used it, and I'm not sure if it would count as "pure sqlite" like the op advocated anymore.

Meaning something like rqlite[1]? The age of fat desktop clients all connecting back to the central SQL server is long behind us, so yeah there is probably little reason beyond fun for something like that, but where there is fun!

[1] https://github.com/rqlite/rqlite

rqlite author here -- happy to answer any questions. While rqlite[1] does replicate a SQLite database, it's not simply a replication system (just to be clear). It's a distributed database that uses SQLite as its database engine, and replicates for fault tolerance. That said, it mostly exposes SQLite via its HTTP API, so can work for many SQLite applications[2].

[1] https://rqlite.io

[2] https://rqlite.io/docs/faq/#is-it-a-drop-in-replacement-for-...