Created
July 1, 2026 13:11
-
-
Save denisgolius/29cfdf9d22287c8864daaec4dea52070 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Vertically on a single machine, the two are quite similar, both fan work out across all CPU cores. | |
| The different is on scaling out. | |
| ClickHouse scales by making you describe the cluster yourself. You decide how many shards to split the data into, how many copies (replicas) each shard keeps, which row goes to which shard. | |
| The copies are kept in sync by a consensus system ClickHouse Keeper. This is flexible but also more works on operators. | |
| VictoriaLogs takes the opposite bet. When logs come in, the inserter just spreads them across all storage nodes on its own, so there is no sharding key for you to design. | |
| When a query runs, the selector asks every storage node in parallel and merges the results. There is no consensus system at all. If you want high availability, you run 2 independent clusters and send your logs to both, rather than having the database copy data internally. | |
| So this is simpler and less learning curve. | |
| See more here https://victoriametrics.com/blog/victorialogs-architecture-basics/ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment