TimeScaleDB
由于TimescaleDB完全基于PostgreSQL构建而成，因此它具有若干与生俱来的优势 ：
- 100%继承PostgreSQL的生态。且由于完整支持SQL，对于未接触过时序数据的初学者反而更有吸引力
- 由于PostgreSQL的品质值得信赖，因此TimescaleDB在质量和稳定性上拥有品牌优势
- 强ACID支持
当然，它的 短板 也是显而易见的
- 由于只是PostgreSQL的一个Extension，因此它不能从内核/存储层面针对时序数据库的使用场景进行极致优化。
- 当前的产品架构来看仍然是一个单机库，不能发挥分布式技术的优势。而且数据虽然自动分区，但是由于时间戳决定分区，因此很容易形成I/O热点。
- 在功能层面，面向时序数据库场景的特性还比较有限。目前更像是一个 传统OLTP数据库 + 部分时序特性 。
不管怎样，TimescaleDB也算是面向时序数据库从另一个角度发起的尝试。在当前时序数据库仍然处于新兴事物的阶段，它未来的发展方向也是值得我们关注并借鉴的。+
总体而言，TimescaleDB非常适合那些寻求显著性能提升，而不想通过大量重构来迁移现有SQL数据库的团队。尽管TimescaleDB相对较新(于2017年首次被发布)，但是许多物联网初创公司已在使用它作为中间数据存储，以快速提取横跨数月的聚合参数指标，并将旧的数据移至长期存储处。如果您已经在Kubernetes集群上运行着 PostgreSQL，那么安装TimescaleDB和迁移数据的任务都会相对比较容易。
总的说来，TimescaleDB的优缺点可以被归结为：
- 优点：与PostgreSQL兼容性，可以很好地扩展数据基数，并提供各种部署模型。
- 缺点：结构模式固定，而且在摄取之前增加了复杂性和数据的转换工作。
Prometheus
Prometheus 有五大优势：
- 灵活的数据模型：在 Prometheus 里，监控数据是由值、时间戳和标签表组成的，其中监控数据的源信息是完全记录在标签表里的；同时 Prometheus 支持在监控数据采集阶段对监控数据的标签表进行修改，这使其具备强大的扩展能力；
- 强大的查询能力：Prometheus 提供有数据查询语言 PromQL。从表现上来看，PromQL 提供了大量的数据计算函数，大部分情况下用户都可以直接通过 PromQL 从 Prometheus 里查询到需要的聚合数据；
- 健全的生态：Prometheus 能够直接对常见操作系统、中间件、数据库、硬件及编程语言进行监控；同时社区提供有 Java/Golang/Ruby 语言客户端 SDK，用户能够快速实现自定义监控项及监控逻辑；
- 良好的性能：Prometheus 提供了 PromBench 基准测试，从最新测试结果来看，在硬件资源满足的情况下，Prometheus 单实例在每秒采集 10万条监控数据的情况下，在数据处理和查询方面依然有着不错的性能表现；
- 更契合的架构：采用推模型的监控系统，客户端需要负责在服务端上进行注册及监控数据推送；而在 Prometheus 采用的拉模型架构里，具体的数据拉取行为是完全由服务端来决定的。服务端是可以基于某种服务发现机制来自动发现监控对象，多个服务端之间能够通过集群机制来实现数据分片。推模型想要实现相同的功能，通常需要客户端进行配合，这在微服务架构里是比较困难的。
当然，Prometheus 也有一些不足，比如不能用于日志监控、分布式追踪等范围。
QuestDB
QuestDB的优缺点可以被归结为：
- 优点：快速摄取(特别是对于具有高基数的数据集)，支持InfluxDB内联协议和PostgreSQL wire，可以通过标准的SQL查询数据。
- 缺点：在用户社区、可用集成、以及对生产环境就绪等方面，都有待改进。