cockroach VS yugabyte-db

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

In a previous post, I published an example with PostgREST on YugabyteDB. Here is another one: pREST opens a REST API to PostgreSQL. YugabyteDB is a PostgreSQL-compatible Open-Source Distributed SQL database. It adds horizontal scalability to applications built for PostgreSQL. Let's see how it integrates with pREST.

There is still work in progress in FerretDB, like Create primary key index for _id automatically #1384 . If a Primary Key is added with with the ID, it will become the sharding key in YugabyteDB. Another optimization will be to avoid reading information_schema.columns which is slow on YugabyteDB (the catalog must be shared by all nodes). This will be optimized on YugabyteDB (#7745). If it is still a scalability issue, there's also the possibility to fork the PostgreSQL handler to optimize it for YugabyteDB. All this is open source 🤩 YugabyteDB and FerretDB are Apache License 2.0

I was building a new version of YugabyteDB vagrant box with packer and virtual box. Because we (Yugabyte) have a new preview release out.

The sst_dump command in version 2.15.3.2 is not yet updated to handle packed rows. I created an issue for it: [DocDB] sst_dump does not recognise packed rows and displays 'Schema packing not found: 0: .'.

YugabyteDB

I created a pool called "yugabyte" (pools.yugabyte), with pool mode 'session', so that a session remains connected to a backend. I created a pool of servers in pools.yugabyte.shards.0 (yugabyte shards pool 0), with all three of the YSQL nodes in the YugabyteDB cluster, and gave one the role of "primary" and the two others the role of "replica". For YugabyteDB YSQL this does not make sense. Currently, pgcat allows to have the roles to be all "replica", but not have more than one "primary".

As an example, this is how I start a VM in the US West and connect it to my YugabyteDB cluster in the US East:

YugabyteDB might still be a dark horse for many. That’s the database I’m nerding on these days. It’s a distributed SQL database built on PostgreSQL. Basically, it’s a distributed PostgreSQL that can work across geographies. Exactly what I need for my geo-distributed app.

YugabyteDB is an ideal choice here as it is an open-source, PostgreSQL compatible distributed SQL database. (If you want to know more about how and why to use YugabyteDB, you can check out this amazing playlist on YouTube).