C0c0balt·Oct 7, 2022
Isn't TiDB built on top of TiKV?[0]
[0]: https://github.com/pingcap/tidb
In Apache Pegasus - A horizontally scalable, high-performance key-value storepingcap
tidb
Go2015–2026
pingcap / tidb
tidb
TiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.
Data & DatabasesSystems & InfrastructureAI & Machine LearningDevOps & CloudSearch & Information Retrieval
46Distinct people
69Mentions
0Explicit recommenders
40.7KGitHub stars
What to know before exploring
What it is
TiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- cockroachdb/cockroach · linked in 2 of the same discussions
- tikv/tikv · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:01:32 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year69 dated mentions
Observed mentions: 2015-09-07 08:03:50 UTC to 2026-10-21 12:59:49 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 12 | 2 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
9 sourcesOLTP usually comes with high throughput of transactions, which means usually write(e.g., IUD - insert, update, delete) to read (e.g., select) ratio is above 4 or 5 or even higher. There are some good benchmarks to test OLTP workload like TPC-C (https://www.tpc.org/tpcc/), and some benchmarks to test OLAP workload like TPC-H (https://www.tpc.org/tpch/). For mixed or hybrid OLTP and OLAP (it's called HTAP, see this blog for some background https://en.pingcap.com/blog/the-beauty-of-htap-tidb-and-allo...), TPC-H was originally designed for this, however, it actually doesn't reveal the real world workload with several drawbacks. A newer research work from UC Berkeley proposed a HTAP benchmark called TAOBench (https://www.vldb.org/pvldb/vol15/p1965-cheng.pdf) which is pretty interesting and worthy to check.
For the HTAP systems, as mentioned in
Read the rest
the above blog, there are quite a few industrial products, like Google just announced AlloyDB (https://cloud.google.com/alloydb), Snowflake's UniStore (https://www.snowflake.com/workloads/unistore/), and one of the most popular open source projects TiDB (https://github.com/pingcap/tidb) which have been deployed by many business applications.
Hopefully these may help a little bit :-)
I am very agree with some options of this blog. As the maintainer of the open source distributed database TiDB https://github.com/pingcap/tidb, we also face the same problem of choice. We have a community version, an enterprise version(of course, we must sell it to our customers to earn money) and also a cloud service named TiDB cloud.
Seven years before, we started to build TiDB to solve MySQL sharding problem, yes, "I Don’t Want to Shard (MySQL)" https://news.ycombinator.com/item?id=32041656 too. At that time, we only had a community version of TiDB.
After we had developed TiDB for more that one year, we needed to consider earning money because we (PingCAP) are a company. So we built an enterprise version to sell to our customers. Unlike other companies do mostly, they separate the community and enterprise version a lot, there are eve
Read the rest
n some killing features that only exist in the enterprise version. But we believe that all our customers, whether they pay for us or not, must get the benefits, nearly the same value from TiDB. So we decide to keep the same between the community and enterprise. The only difference for the enterprise version is that the version contains another two tiny features - audit log and IP white list. As far as I know, no community user asks us for these two feature util now.
Things were going well, and a few years later, we met the same dilemma for TiDB community version and TiDB cloud service https://tidb.cloud. Of course, at this time, we still insist on that the TiDB must be open source, any improvement for the cloud will be contributed to the community version at first, then we deploy to our own service later. This mean anyone can deploy TiDB easily on the cloud too.
This is our open source decision. Thanks to this decision, our products are now increasingly well known, you can check the insights from https://ossinsight.io/analyze/pingcap/tidb/.
Yes, hardware has limits and you just cannot have a single machine with unlimited number of cores and disks.
But as the article mentioned, NewSQL is already there. DBs in this category has actually been awhile. I think Spanner's paper was 10 years ago. And it is ubiquitous across Google. So let's just accept that we should think things differently in 2022. Distributed RDBMS is already a thing, used in production, in many companies. Like TiDB(https://github.com/pingcap/tidb) mentioned in the article, Square already uses it to replace some MySQL's use cases (https://www.youtube.com/watch?v=TjqL50qzy3A).
In I Don't Want to Shard (MySQL)Disclaimer: I now work at https://www.yugabyte.com/yugabytedb/, I joined because I liked their approach and think it has a lot of merit.
But there are also https://www.cockroachlabs.com/product/, https://github.com/pingcap/tidb and
https://ydb.tech/ which each has promise.
There is definitely lots of progress to make in this space. From what I have seen they are all significantly slower on a single node and are not as battle-hardened. But I think with time we will have a few really nice options to pick from.
In We are splitting our database into Main and CIGitea is very easy to use, but I find the Activity feature is a little slow.
I experienced the "Try Gitea" service and migrated our TiDB repo https://github.com/pingcap/tidb to it. When I clicked the Activity tab and selected "1 year" period, I found the page loading was so slow, nearly 90s. And I also found that this Activity doesn't have a Cache, I re-selected "1 year" again, and the page loading was nearly the same time.
I guess Gitea uses git command to traverse all the logs for the period every time. Maybe it can use a database to speed up, or like Github only provide at max "1 month" period.
In Gitea – a painless self-hosted Git serviceOne of the founder of TiDB/TiKV here from PingCAP (https://pingcap.com)
I have been thinking about this problem with my peers when I started to build TiDB (https://github.com/pingcap/tidb) seven years ago. At that time, nearly all of us were familiar with Go language, so we decided to use Go to build the SQL layer of TiDB. Thanks to Go, we could develop TiDB very quickly and released the first MVP in half a year. I remembered clearly the sense when we ran TPC-C successfully, although the TPMC was just 1 at that time, this was a good start for us.
But Go had some problems, e.g. the GC was not good before, the fair scheduling might cause some latency problem, or data racing may happen sometimes. So when we decided to build a distributed storage (aha, TiKV (https://githbu.com/tikv/tikv), we wanted use another language to guarantee safety. I
Read the rest
really admire our courage - we chose Rust which was just released 1.0 and missed lots of libraries at that time. Now it seems that this is an awesome choice, TiKV has been graduated from CNCF, and been used as building block not only for TiDB, but also for other distributed systems. Thanks Rust.
When TiDB started being used in many companies, we found that our customer not only ran lots of online transactions in TiDB, but also they wanted to ran some realtime analytic queries directly because the data has been in TiDB already. So we decided to build a HTAP database, to introduce a column storage beside TiKV, this is TiFlash (https://github.com/pingcap/tiflash). We build TiFlash based on Clickhouse, so of course, we use C++.
As you can see, to build only one integrated database - TiDB, we at least use three languages, every language has its own reason to be introduced. We can treat the distributed database as a service system, each service can be built with your favorite language and the services are linked by gRPC like TiDB does now. You may doubt that - “hey, guys, you are building a database, performance is very importance”. Yes, this is true, but we also build a complex distributed system, especially on the cloud. Scale-out, elastic, user experience must be important too. This is trade off for an engineer :-)
An open-source, MySQL compatible, NewSQL database that supports HTAP workloads
1 points · Open discussionFair enough. Indeed I didn't consider support costs. Thank you for your answer!
Actually let me ask another thing. Your FAQ mentions you're considering hosting CockroachDB as a drop-in distributed replacement for PostgreSQL [0], and also you currently offer a distributed, eventually consistent PostgreSQL replication solution [1].
Is either Tikv [2] (distributed key-value store) or Tidb [3] (distributed database with a mysql interface, built on top of Tikv) on your radar?
You already offer Redis as a key-value store, but Tikv has an amazing property: it ensures strong consistency globally (not eventual consistency). Tidb, being built on top of Tikv, also has strong consistency.
[0] https://fly.io/blog/fly-answers-questions/#q-what-is-fly-doi...
[1] https://fly.io/blog/globally-distributed-postgres/
[2] https://github.com/tikv/tikv
[3] http