A review from a starting developer

[Perusae]

I like to provide some feedback around CRDB as a developer that looks at easily scalable DBs for a future project.

Testing environment: 3x Hetzner 2 Core ARM + 4GB + 40GB SSD

1. Installation: Frustrating for actual secure production!

Installation of CRDB is one of the most painful DBs i have had the displeasure of dealing with, when its not the basic demo or insecure running. Multiple locations in the manuals simply lumps the secure credentials as single operations to get a demo or local test going but do not properly explain the difference between the credentials and how they actually need to be deployed to the nodes. The most useful information was ironically hidden under the systemd installation guide.

It felt like this entire process was easily replaceable by self generated credentials (by each node) themselves. Where you simply approved the nodes to join the cluster (via cli or UI), with then each node getting the proper generated credentials made automatically. Its feels unneeded convoluted and is one of those "So if i want to expand to 5 nodes (from 3), in a year or two, do i still remember the steps to do so".

2. Performance: Disappointing at best.

Idle usage... Basic starting the cluster resulted in all 3 nodes consuming 1GB of memory. As time progressed, this grew to 1.4GB where it for a while stabilized. We had constant 3~7% CPU usage on both cores, on each node, with no databases! What i considered extreme high just for idling.

Having them run idle at night, resulted in a increase of CPU usage from 3 ~ 7 > 25% on both cores (where the usage increased each hour by about 2% until hitting almost 25% and then dropping down to). It finally stopped after 11h of increases with the return to 37%.

The storage usage without ANY databases grew to 1.2GB simply from its own monitoring.

Removing a node, letting it die, and after 10 min letting it start again, resulted in node 1 having over 2.8GB of memory usage, node 2 being at 1.7GB and node 3 at 1.3GB. Again, this was just the basic self no database setup (only its own 54 ranges)

At this same time, we ran 3x postgresql databases, that used only 35~55MB of memory, and idled at 0% usage with replicate active.

When we started to actually fil the databases with tables and data, we noticed CRDB taking easily 400ms to create the tables, and up to 800ms for the indexes. Where as postgresql as doing only around 40ms for the tables and 80ms for the indexes.

Actual retrieval of data showed again easily 3x to 7x performance gaps. I have not even mentioned the amount of CPU usage what was easily double to triple (depending on the load).

While i understand that CRDB is supposed to become better to scale, its default performance issues, make it a horrible database to start with as it requires easily 3x to 7x more resources to scale to a default postgresql database setup with replicate. In fact this is even worse by the amount of processing power it needs, what feels like you need to deploy at minimum 9 CRDB nodes to just compensate a 2x postgresql node setup, with double the memory and CPU cores.

3. License and changes.... Seeing CRDB having a history of multiple license changes does not exactly give a fuzzy feeling.

4. Unlike stated, the Enterprise free version is not free, as your paying with telemetric data, and what data is actually retrieved from your systems is EXTREME unclear. Nor is their any guarantee how much this can change with future updates.

5. Then there is the whole Enterprise free != approval free. Starting a 3x cluster to only THEN see the warning that a free license is required, with only a 7 days timeframe to get a license APPROVED is beyond annoying. Especially when that information is not present in the single node development setups.

The fact that a free license needs to be approved is again a major issue. This translates into "ok, so if we use this database for the future, what is to say in 2026, they still approve a new license, as they are only for one year!!!". This means that as a company, you can be sucked into a situation where if something happens to CRDBLabs, you have no license, well, good luck changing your entire program architecture because 7 days later, you are down to a REDICULOUSE 5 q/s.

What if your db manager is in vacation, and can not be reached. What if somebody forgot to request a new license. Well, down to 5 q/s and your entire business going up in smokes.

The entire process is so anti company / developer in so many ways, despite it being the "free" version. Unlike the Core version, the new Enterprise Free version is extreme anti startups in my opinion as its fraud with potential issues. It feels like a afterthought because some million dollar+ companies heavily used the core, without needing to pay CRDBlabs, so a rather "we are getting your money" attitude is so present over the system.

6. Lacking features.

So many Regex commands are not compatible with postgresql as there are clear differences. Basic features like array [1;x] are again not supported. And a ton more postgresql features that needed to be adapted to CRDB.

The whole compatibility really only extends to the wire protocol and after that there are so things missing or do not work the same. In essence, CRDB is its own sql language, on the level that Mysql and Postgresql both are SQL but not 1:1 cross compatible and may require query rewrites.

6. Costs?

Great, so how much does a Enterprise license cost? "Well, you do not need to know. Please contact sales so we can see how much we can squeezer out of you, when your already dependent on our product".

As a dev, i absolute hate this type of unclear "what am i getting in bed with". While you may state a 10M revenue, what is there preventing CRDBlabs from going in 2026: "Now its 1M revenue". 2027: Well, if you make 100K, now you need to use our new Enterprise Lite (or whatever changes happen).

The fact that there is no clear cost, means ... well, we can charge you a la Oracle for every vCPU (hey, lets ignore if your in a VM and charge you the entire system. I mean, there is really nothing preventing this from happening). So what will the cost be? 150 / vCPU, 200, 500? This is again one of those anti adoption because you are tied into CRDB.

And that is the issue ... you need twice the amount of vCPU cores, with easily 3x more nodes then a basic postgresql cluster. So any bill in the form of, lets say 150/vcore, can see you spend 10.000 or 20.000/month like its water. Just for basic free posgresql performance levels.

7. Yes, i understand that CRDB Cloud exist but at that point, there is a multitude of competitor managed systems. CRDB its main benefit from a dev point of view, is that it can be self hosted, but its shooting itself in the foot.

So many more points but i already spend a hour writing this...

Conclusion:

Despite all my negativity, i like what CRDB as a actual product is (easily growth in nodes, robust, easy upgrade path). How it can make a developer more relaxed for self hosting their own DB setups.

But the whole corporation side shows a lack of actually growing bottom clients without risks. And this is really reflected in a lot of above mentioned points. Just throwing a "you do not pay below 10M" is not a fix for a lot of potential risks associated with CRDBlabs changing their minds or other issues.

I love to use CRDB for my projects but at this time, i can only conclude that CRDB is stepping back from the general market and is only interested in enterprise and cloud. With the self hosted version being more a legacy feature that may one day vanish or be even more restricted.

So this is my 2 cents dealing with CRDB the past week (and some experience 5+ years ago).