No, and with timescaledb is a feature of their cloud platform. For on prem you can use something like Arc: https://github.com/Basekick-Labs/arc

Thank you.

I have decided to use clickhouse with that config because of missing S3 for logs and metrics for long term store.

  <clickhouse>
    <storage_configuration>
      <disks>
        <audit_s3>
          <type>s3</type>
          <endpoint>https://S3-EndPoint/{{ audit_bucket_name }}/clickhouse/</endpoint>
          <access_key_id>{{ clickhouse_audit_s3_access_key }}</access_key_id>
          <secret_access_key>{{ clickhouse_audit_s3_secret_key }}</secret_access_key>
        </audit_s3>
      </disks>
      <policies>
        <audit_tiered>
          <volumes>
            <default>
              <disk>default</disk>
            </default>
            <audit_s3>
              <disk>audit_s3</disk>
            </audit_s3>
          </volumes>
        </audit_tiered>
      </policies>
    </storage_configuration>
  </clickhouse>

I don't know, my gut says that this is going to end in a bad way. I signed up, I think but wasn't sure if I needed to buy Cursor, or Origin came with a subscription, so confused.

For now Arc is staying in Github: https://github.com/Basekick-Labs/arc

Arc does pruning, and make that scan faster. Check it out: https://github.com/Basekick-Labs/arc

Check it out Arc, I think that we can help there, plus, use DuckDB as a engine: https://github.com/Basekick-Labs/arc

Hey this is neat and I just found out you're from BA, Argentina. I would love you be part of dataengine.ar and maybe talk about arc?

Hey hey. I love to. I'm from Argentina, and I say that Arc is proudly make from Latam, but I live in Costa Rica.

Very cool!

We (Basekick Labs) we are the new maintainers of Liftbridge. It went dormant in 2022, and we're reviving it.

Liftbridge adds Kafka-style durability to NATS: commit log, partitions, ISR replication. Single Go binary, no JVM or ZooKeeper.

Architecture: Raft for metadata consensus, ISR (like Kafka) for data replication. Memory-mapped segment files with offset/timestamp indexes.

We're using it for Industrial IoT (streaming layer for Arc, our time-series database), but it works standalone.

Roadmap: Go 1.25+, dependency updates, security audit, CI/CD fixes (Done) and we fixed a few panic errors / race conditions bugs. First release mid January 2026.

Happy to answer questions.

Arc is OSS under AGPL-3.0: https://github.com/Basekick-Labs/arc

Two weeks ago, we open-sourced Arc Core: https://github.com/Basekick-Labs/arc

Today, the results are in, Arc is now the fastest time-series database on ClickBench, outperforming QuestDB and TimescaleDB across nearly every hardware configuration. It also ranks among the top 5 fastest systems overall, alongside DuckDB, ClickHouse, and Salesforce Hyper.

Arc ingests 2.42 million records per second, tops the Cold Run charts for all system sizes, and does it all in roughly 5,500 lines of code.

It’s built on DuckDB for SQL, MessagePack for ingestion, Parquet + Arrow for columnar storage, and a lock-free multi-threaded core for compaction and WAL.

Benchmarks aren’t everything—I agree—but performance matters. It’s what lets smaller infrastructure handle serious workloads without ballooning costs.

This enables massive IoT ingestion, real-time logistics tracking, aerospace telemetry, observability at scale, and market data analytics—all without a huge footprint.

13 days since launch: 252 GitHub stars, 100+ community conversations shaping the roadmap.

Full technical breakdown and benchmarks: https://basekick.net/blog/arc-fastest-timeseries-database-cl...

Happy to answer questions about the architecture, design decisions, or benchmarking methodology.

That’s fair, the number alone doesn’t mean much without context.

The benchmark measures fully written time-series records, not bytes. Each record typically includes 1–4 fields, tags, and timestamps, similar to InfluxDB’s Line Protocol structure.

For comparison, the same hardware (AWS c6a.4xlarge) handles around 240K RPS using Line Protocol, while Arc reaches 1.88M RPS with MessagePack, about 7.8× faster on ingestion throughput.

You can see the full ClickBench and ingestion benchmarks are in the repo.

TL;DR: Arc’s strength isn’t massive single records, it’s sustained high-throughput ingestion of structured time-series data while still staying analytical-query friendly.

Thanks! Let’s go by parts, as Jason would say

Schema inference: yes, Arc infers the schema automatically from incoming data (both for MessagePack and Line Protocol). Each measurement becomes a table, and fields/tags map to columns.

Schema evolution: supported. New fields can appear at any time, they’re added to the Parquet schema automatically without migration or downtime.

Custom partitions: currently partitioning is time-based (hour-level by default), but custom partitioning by tag or host or whatever is planned. The idea is to allow you to group by any tag (e.g. device, region) in the storage path for large-scale IoT data.

Roadmap: absolutely. Grafana data source, Prometheus remote write, retention policies, gRPC streaming, and distributed query execution are all in the works.

We are going to start to blogging about it, so, stay tune.

Would love any feedback on what you’d prioritize or what would make adoption easier for your use case.

My use case isn't IOT, but about once a month I get a massive data dump from a vendor. Think tens of millions of rows and 100+ columns. Cleaning, ingesting and querying this data via standard RDBMS is a slow and brittle process. There is a time series aspect, but partitioning across other keys/groups is critical.